326007 - Xulrunner fails to build using VS.NET 2003 (VC7.1), chokes at linking xul.dll due to conflicting LIBC and MSVCRT libs

Status: RESOLVED FIXED

(Toolkit Graveyard :: Build Config, defect, P3)

Description

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Using VC 7.1 (and perhaps 7.0?) Xulrunner 1.8 fails to link properly. Below is the output:

----------
LIBC.lib(crt0dat.obj) : error LNK2005: __exit already defined in MSVCRT.lib(MSVCR71.dll)
LIBC.lib(crt0init.obj) : error LNK2005: ___xc_z already defined in MSVCRT.lib(cinitexe.obj)
LIBC.lib(crt0init.obj) : error LNK2005: ___xc_a already defined in MSVCRT.lib(cinitexe.obj)
LIBC.lib(crt0init.obj) : error LNK2005: ___xi_z already defined in MSVCRT.lib(cinitexe.obj)
LIBC.lib(crt0init.obj) : error LNK2005: ___xi_a already defined in MSVCRT.lib(cinitexe.obj)
MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBC.lib(typinfo.obj)
MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscalltype_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBC.lib(typinfo.obj)
LIBC.lib(crt0dat.obj) : warning LNK4006: __exit already defined in MSVCRT.lib(MSVCR71.dll); second definition ignored
LIBC.lib(crt0init.obj) : warning LNK4006: ___xc_z already defined in MSVCRT.lib(cinitexe.obj); second definition ignored
LIBC.lib(crt0init.obj) : warning LNK4006: ___xc_a already defined in MSVCRT.lib(cinitexe.obj); second definition ignored
LIBC.lib(crt0init.obj) : warning LNK4006: ___xi_z already defined in MSVCRT.lib(cinitexe.obj); second definition ignored
LIBC.lib(crt0init.obj) : warning LNK4006: ___xi_a already defined in MSVCRT.lib(cinitexe.obj); second definition ignored
MSVCRT.lib(ti_inst.obj) : warning LNK4006: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBC.lib(typinfo.obj); second definition ignored
MSVCRT.lib(ti_inst.obj) : warning LNK4006: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBC.lib(typinfo.obj); second definition ignored
   Creating library xul.lib and object xul.exp
LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib 'LIBC' conflicts with use of other libs; use/NODEFAULTLIB:library

... (more misc warnings here) ...

xul.dll : fatal error LNK1169: one or more multiply defined symbols found
make[3]: *** [xul.dll] Error 145
make[3]: Leaving directory `/cygdrive/d/projects/mozilla_1_8_branch/mozilla/compiled/toolkit/library'
make[2]: *** [tier_50] Error 2
make[2]: Leaving directory `/cygdrive/d/projects/mozilla_1_8_branch/mozilla/compiled'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/cygdrive/d/projects/mozilla_1_8_branch/mozilla/compiled'
make: *** [build] Error 2
----------

I've been using the following .mozconfig file, although I should mention that I have experimented with lots of different options and the build fails at the same step every time:

----------
mk_add_options MOZ_MAKE_FLAGS=-j4
mk_add_options MOZ_CO_PROJECT=xulrunner
mk_add_options mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/compiled
ac_add_options --enable-application=xulrunner
ac_add_options --disable-tests
ac_add_options --enable-extensions=default,inspector,venkman
ac_add_options --enable-svg
ac_add_options --enable-canvas
ac_add_options --disable-javaxpcom
----------

This configuration works perfectly when building on the trunk, so this is a 1.8 branch problem. Looking at the tinderboxes set up for Xulrunner it appears that those machines are using VC6. Those logs also show a linking issue, although the build continues and is ultimately successful:

----------
   Creating library xul.lib and object xul.exp
LINK : warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use /NODEFAULTLIB:library
----------

For completeness I should mention that bug 321650 comment 3 runs into a similar issue necessitating a choice between libcmt and msvcrt. It appears that this issue only rears its head when using VC7.

Comment 1

[Benjamin Smedberg]

MSVC7.1 is my standard compiling environment, so I strongly suspect that this (and bug 321650) are system-specific somehow. libc should never be listed in directives, as it's not threadsafe.

Comment 2

[Ben Turner (not reading bugmail, use the needinfo flag!)]

FWIW I'm using an AMD Athalon 64x2 system with WinXP Pro 64. And I'm using Cygwin.

Comment 3

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I was able to get ahold of another machine today... XULRunner built just fine with the .mozconfig info from comment 0 on a Pentium WinXP Pro system. It looks like this is indeed system-specific.

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Actually, I spoke too soon. I was able to build on the pentium machine using --disable-optimize --enable-debug, but the build failed as reported above with --enable-optimize --disable-debug. Neither configuration builds on the AMD machine.

Comment 5

[Ben Turner (not reading bugmail, use the needinfo flag!)]

With some additional tweaking (read: deleting the objdir like I should have done the first time) I was able to get the debug configuration to work. The optimized config fails as before. I'm betting that --enable-optimize is the culprit. Benjamin, are you able to get optimized builds rolling?

Comment 6

[Benjamin Smedberg]

Something is having you link against LIBC, which is very very wrong. You need to poke through your directives using dumpbin /directives until you find the library/object that is using that directive, and figure out why.

Comment 7

[Ben Turner (not reading bugmail, use the needinfo flag!)]

So after checking through all of the libs produced in my build I found that several libs were using LIBC:

mozz_s.lib
mozregsa_s.lib
jar50_s.lib
mozlibpixman.lib
xpnet_s.lib

bsmedberg suggested applying the changes made to config.mk from attachment 209448 [details] [diff] [review] (from bug 242870). This patch had previously been landed on the trunk but not on the 1.8 branch. bsmedberg will be landing it on the branch shortly.

After applying those changes mozlibpixman.lib was the only lib still importing LIBC. It turns out that the makefile for libpixman has some old MSVC6 hack left in it. Removing that fixed the build.

Patch for the libpixman makefile to follow shortly.

Comment 8

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: libpixman makefile fix

This patch fixes libpixman to link against msvcrt instead of libc when compiling optimized builds for vc7.

Comment 9

[Benjamin Smedberg]

Attachment: Use the static lib for VC6 only, rev. 1

Comment 10

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Comment on attachment 210917 [details] [diff] [review]
Use the static lib for VC6 only, rev. 1

Confirming that this patch fixes the build problems for vc71

Comment 11

[Mike Connor [:mconnor]]

Not a blocker for Firefox 2, but we should get this!

Comment 12

[Benjamin Smedberg]

*** Bug 329472 has been marked as a duplicate of this bug. ***

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 210917 [details] [diff] [review]
Use the static lib for VC6 only, rev. 1

I could've sworn we talked about this on irc; r=me

Comment 14

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 210917 [details] [diff] [review]
Use the static lib for VC6 only, rev. 1

a=me for 1.8.1

Comment 15

[Ben Turner (not reading bugmail, use the needinfo flag!)]

fixed on branch

(btw, i removed a whitespace artifact on checkin)

Comment 16

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Comment on attachment 210917 [details] [diff] [review]
Use the static lib for VC6 only, rev. 1

Can we get this on the 1.8. 0 branch?

Comment 17

[Daniel Veditz [:dveditz]]

Silly question from drivers, why does the vc71 version of pixman make sense for vc6, and *not* for vc71? Is it just misnamed?

Comment 18

[Benjamin Smedberg]

This has to do with how it is linked (using the static or non-static CRT), in this case it is using the wrong setting.

Comment 19

[Daniel Veditz [:dveditz]]

Comment on attachment 210917 [details] [diff] [review]
Use the static lib for VC6 only, rev. 1

approved for 1.8.0 branch, a=dveditz for drivers

Comment 20

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Fixed 1.8.0