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)

x86
Windows 7
defect
Not set
normal

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.
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
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.
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.
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).
Is that possible to compiling xul_s.lib static library, and linked by
mail's components.
Flags: needinfo?(Pidgeot18)
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)
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?
"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.
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).
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.