Closed
Bug 1156050
Opened 9 years ago
Closed 8 years ago
--enable-incomplete-external-linkage not works under Win32, linkage error.
Categories
(MailNews Core :: Build Config, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: luoyonggang, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36 Steps to reproduce: I've building thunderbird with ac_add_options --enable-application=mail # Build mail into separate dynamic library ac_add_options --enable-incomplete-external-linkage And on win32, because of some functions are not export, and because the XPCOM StringAPI problems, we can not building thunderbird with `--enable-incomplete-external-linkage` on win32. Actual results: linkage fail, compiling errros. Expected results: compiling and testing pass.
Comment 1•9 years ago
|
||
Neil might know if it works at all anymore. I haven't tried it after the breakage caused by bug 937056...
Product: Thunderbird → MailNews Core
Comment 2•9 years ago
|
||
There's been other stuff since such as bug 1027241 and bug 791645, but I haven't been tracking them since I upgraded to VS2013.
Comment 3•9 years ago
|
||
SkinkGlue/ExQuilla still compiles core Thunderbird code under external linkage, and I recently got a small change fixed in core that caused issues. But still works in at least TB 39. Bug 1114686 prevents Compose from working, but I have a patch there proposing to eliminate what is IMHO unneeded code. My extensions uses that patch, we could probably also add an #ifdef if needed. But Ehsan made it clear that external linkage is not a priority, and could break at any time due to changes in core. For me, the writing is on the wall, and the way forward will be incorporating SkinkGlue in core and in libxul, and using its override capability to extend key Mailnews objects rather than external linkage.
Comment 4•9 years ago
|
||
My gut reaction is to rip out MOZ_INCOMPLETE_EXTERNAL_LINKAGE entirely. The mozilla-central folks have made it clear that supporting features from external API is certainly not a priority, and (for some features, such as JSAPI access) actively harmful. The benefits from supporting this feature are far outweighed by the investments it would take to make it work, especially since it's not hard to presume that, 6 months down the line, something changes that makes supporting it completely untenable (just as killing external access to JSAPI screwed over Lightning).
Reporter | ||
Comment 5•9 years ago
|
||
Is that possible to compiling xul_s.lib static library, and linked by mail's components.
Flags: needinfo?(Pidgeot18)
Comment 6•9 years ago
|
||
I'm not entirely sure what you're asking, but the answer is probably no in any case: libmail as a separate library from libxul isn't feasible, and attempting to duplicate things in libxul as a static library is a recipe for painful linking issues. And if your primary concern is compile speed, what I think you're asking for is going to make it take much more time instead of much less.
Flags: needinfo?(Pidgeot18)
Reporter | ||
Comment 7•9 years ago
|
||
I means link libmail and libxul_s.lib as xul.dll, and libxul_s is distributed with LIBXUL_SDK, so we do not need to building LIBXUL_SDK all the time. About the linkage time of 'link libmail and libxul_s.lib as xul.dll', the only way is enable `MOZ_INCOMPLETE_EXTERNAL_LINKAGE`, but you said that's not acceptable.
I don't know why all the static library should link to libxul.so (xul.dll in windows). If i find some bug code which in mailnews dirctory, after change it i still need to cost almost 5 minutes to link libxul.so, OMG! Did all thunberbird developers fix bug in such an slow way? Or just becauce my PC is too slow? Anyway, I think in an software project, we should only pay times in compile code which we had changed but not all the code. I still want to ask, how much time you spent in link libxul.so?
Comment 9•9 years ago
|
||
"after change it i still need to cost almost 5 minutes to link libxul.so" I develop on Windows, which in general is slower than Linux. A clobber build takes about 30 minutes. A rebuild after minor change is about 3 minutes. I have a very high-end laptop which is really needed for Thunderbird development. Fast is relative, builds are now about 5x faster than they were several years ago due to a massive effort by the build team to improve things.
Comment 10•9 years ago
|
||
A rebuild is about 50 sec on my linux machine. Clobber is usually around 20 min, but it varies (haven't figured out exactly why).
Updated•8 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•