302879 - Sunbird compilation fails (ld: unrecognized option '-Wl,--version-script')

Status: RESOLVED INCOMPLETE

(Firefox Build System :: General, defect)

Description

[Vincent Lefevre]

User-Agent:       Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.10) Gecko/20050730 Firefox/1.0.6 (Debian package 1.0.6-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.10) Gecko/20050730 Firefox/1.0.6 (Debian package 1.0.6-2)

The Sunbird compilation fails with the following error:

ld -shared -h libxpcom_compat_c.so -o libxpcom_compat_c.so  nsXPCOMObsolete.o
nsRegistry.o       -L../../../dist/bin -lxpcom -lxpcom_core  -L../../../dist/bin
-L../../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -L../../../dist/lib
-lxpcom_compat  -Wl,--version-script
-Wl,/home/lefevre/software/moz-source/mozilla/build/unix/gnu-ld-scripts/components-version-script
-Wl,-Bsymbolic -ldl -lm    
ld: unrecognized option '-Wl,--version-script'
ld: use the --help option for usage information
make[4]: *** [libxpcom_compat_c.so] Error 1
make[4]: Leaving directory
`/home/lefevre/software/moz-source/mozilla/obj-sunbird/xpcom/obsolete/component'
make[3]: *** [libs] Error 2
make[3]: Leaving directory
`/home/lefevre/software/moz-source/mozilla/obj-sunbird/xpcom/obsolete'
make[2]: *** [tier_2] Error 2
make[2]: Leaving directory `/home/lefevre/software/moz-source/mozilla/obj-sunbird'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/home/lefevre/software/moz-source/mozilla/obj-sunbird'
make: *** [build] Error 2

This is the CVS trunk.

Reproducible: Always

Steps to Reproduce:
1.

Comment 1

[Michiel van Leeuwen (email: mvl+moz@)]

version-script is not sunbird specific. over to buildconfig. (But i guess it is
some cygwin setup thing)
I do note that afaik -Wl,foo means that foo is passed to the linker. The -Wl,
part should have been stripped off. Weird $LD?

Comment 2

[Vincent Lefevre]

The Makefile doesn't contain references to any LD. The config.cache contains:

ac_cv_path_LD=${ac_cv_path_LD=/usr/bin/ld}
ac_cv_prog_LD=${ac_cv_prog_LD=ld}

ld is: GNU ld version 2.16.1 Debian GNU/Linux

Comment 3

[Vincent Lefevre]

Hmm... I've seen the config/autoconf.mk file. It has:

MOZ_COMPONENTS_VERSION_SCRIPT_LDFLAGS = -Wl,--version-script
-Wl,$(BUILD_TOOLS)/gnu-ld-scripts/components-version-script

and

LD              = ld

in particular.

Comment 4

[cls]

Can you provide the configure output & config.log ?  It looks like you're not using gcc so it's not using '$(CXX)' when creating shared libs.  This setting conflicts with the version-script flags which assume that you're always using '$(CXX)' when creating shared libs on linux.

Comment 5

[Vincent Lefevre]

I use gcc (this is the only compiler I have). I no longer have the configure output & config.log, but I'm going to try again...

Comment 6

[Vincent Lefevre]

It's worse: make -f client.mk build calls itself recursively:

[...]
make[435]: entrant dans le répertoire « /home/lefevre/software/moz-source/mozilla »
Adding client.mk options from /home/lefevre/.mozconfig-sunbird:
    MOZ_SUNBIRD=1
    MOZ_OBJDIR=$(TOPSRCDIR)/obj-sunbird
make -f /home/lefevre/software/moz-source/mozilla/client.mk build
make[436]: entrant dans le répertoire « /home/lefevre/software/moz-source/mozilla »
Adding client.mk options from /home/lefevre/.mozconfig-sunbird:
    MOZ_SUNBIRD=1
    MOZ_OBJDIR=$(TOPSRCDIR)/obj-sunbird
make -f /home/lefevre/software/moz-source/mozilla/client.mk build
make[437]: entrant dans le répertoire « /home/lefevre/software/moz-source/mozilla »
Adding client.mk options from /home/lefevre/.mozconfig-sunbird:
    MOZ_SUNBIRD=1
    MOZ_OBJDIR=$(TOPSRCDIR)/obj-sunbird
make -f /home/lefevre/software/moz-source/mozilla/client.mk build
make[438]: entrant dans le répertoire « /home/lefevre/software/moz-source/mozilla »
Adding client.mk options from /home/lefevre/.mozconfig-sunbird:
    MOZ_SUNBIRD=1
    MOZ_OBJDIR=$(TOPSRCDIR)/obj-sunbird
make -f /home/lefevre/software/moz-source/mozilla/client.mk build
make[439]: entrant dans le répertoire « /home/lefevre/software/moz-source/mozilla » 
[...]

Comment 7

[Vincent Lefevre]

This was with the 0.2 branch. With the trunk, I get:

$ make -f client.mk build
[...]
creating pkg/Makefile
creating pkg/linux/Makefile
creating pkg/solaris/Makefile
creating pkg/solaris/SUNWpr/Makefile
creating pkg/solaris/SUNWprd/Makefile
creating pr/Makefile
creating pr/include/Makefile
creating pr/include/md/Makefile
creating pr/include/obsolete/Makefile
creating pr/include/private/Makefile
creating pr/src/Makefile
creating pr/src/io/Makefile
creating pr/src/linking/Makefile
creating pr/src/malloc/Makefile
creating pr/src/md/Makefile
creating pr/src/md/unix/Makefile
creating pr/src/memory/Makefile
creating pr/src/misc/Makefile
creating pr/src/threads/Makefile
creating pr/tests/Makefile
creating pr/tests/dll/Makefile
creating pr/src/pthreads/Makefile
configure: warning: Recreating autoconf.mk with updated nspr-config output
make[1]: quittant le répertoire « /home/lefevre/software/moz-source/mozilla »

and that's all.

Comment 8

[cls]

Strange.  We shouldn't be using LD directly to link shared libs if you're using gcc.  That's why I want to see the full configure output & config.log.  The end of the output is fine but doesn't tell us anything.

Comment 9

[Vincent Lefevre]

Attachment: config.log

Here's the config.log. Where does the Mozilla makefile store the configure output?

Comment 10

[cls]

It doesn't.  You'll need to redirect the configure output to a file by hand.

Comment 11

[Vincent Lefevre]

Attachment: Output of "make -f client.mk build"

Comment 12

[cls]

That build log output is confusing.  It looks like configure is being run twice simultaneously which is very bad.  What version of make are you using? And what does your mozconfig file look like? 

Comment 13

[Vincent Lefevre]

GNU Make 3.80

Here make is a shell function that uses -j2 and output filtering (to add colors). I supppose that the fact that configure is run twice is due to the -j2 and incorrect dependencies in client.mk.

My .mozconfig:

. $topsrcdir/calendar/sunbird/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-sunbird
ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --enable-reorder
ac_add_options --enable-strip
ac_add_options --enable-default-toolkit=gtk2
ac_add_options --enable-xft
ac_add_options --disable-freetype2
ac_add_options --disable-tests
ac_add_options --enable-xterm-updates
ac_add_options --disable-pedantic
ac_add_options --prefix=$HOME/sunbird

Comment 14

[cls]

Yes, parallel builds are not supposed at the client.mk level.  Try adding '.NOTPARALLEL:' to the bottom of client.mk and try building again.

Comment 15

[Vincent Lefevre]

Attachment: configure part of "make -f client.mk build"

Comment 16

[Vincent Lefevre]

I now get the following error:

[...]
c++ -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -ffunction-sections -O -fPIC -shared -Wl,-h -Wl,libmozz.so -o libmozz.so  adler32.o compress.o crc32.o deflate.o gzio.o infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o zutil.o        -ldl -lm    
deflate.o: In function `MOZ_Z_deflateSetDictionary':
deflate.c:(.text.MOZ_Z_deflateSetDictionary+0xb8): undefined reference to `memcpy@@GLIBC_2.0'
deflate.o: In function `flush_pending':
deflate.c:(.text.flush_pending+0x48): undefined reference to `memcpy@@GLIBC_2.0'
deflate.o: In function `MOZ_Z_deflate':
deflate.c:(.text.MOZ_Z_deflate+0x99c): undefined reference to `memset@@GLIBC_2.0'
deflate.o: In function `MOZ_Z_deflateCopy':
deflate.c:(.text.MOZ_Z_deflateCopy+0x44): undefined reference to `memcpy@@GLIBC_2.0'
deflate.c:(.text.MOZ_Z_deflateCopy+0x7c): undefined reference to `memcpy@@GLIBC_2.0'
deflate.c:(.text.MOZ_Z_deflateCopy+0x140): undefined reference to `memcpy@@GLIBC_2.0'
deflate.c:(.text.MOZ_Z_deflateCopy+0x154): undefined reference to `memcpy@@GLIBC_2.0'
deflate.c:(.text.MOZ_Z_deflateCopy+0x168): undefined reference to `memcpy@@GLIBC_2.0'
deflate.o:deflate.c:(.text.MOZ_Z_deflateCopy+0x178): more undefined references to `memcpy@@GLIBC_2.0' follow
deflate.o: In function `lm_init':
deflate.c:(.text.lm_init+0x64): undefined reference to `memset@@GLIBC_2.0'
deflate.o: In function `fill_window':
deflate.c:(.text.fill_window+0x64): undefined reference to `memcpy@@GLIBC_2.0'
gzio.o: In function `MOZ_Z_gzread':
gzio.c:(.text.MOZ_Z_gzread+0x10c): undefined reference to `memcpy@@GLIBC_2.0'
gzio.o: In function `MOZ_Z_gzseek':
gzio.c:(.text.MOZ_Z_gzseek+0x94): undefined reference to `memset@@GLIBC_2.0'
infback.o: In function `MOZ_Z_inflateBack':
infback.c:(.text.MOZ_Z_inflateBack+0x2f8): undefined reference to `memcpy@@GLIBC_2.0'
inflate.o: In function `updatewindow':
inflate.c:(.text.updatewindow+0xac): undefined reference to `memcpy@@GLIBC_2.0'
inflate.c:(.text.updatewindow+0xf0): undefined reference to `memcpy@@GLIBC_2.0'
inflate.c:(.text.updatewindow+0x10c): undefined reference to `memcpy@@GLIBC_2.0'
inflate.o: In function `MOZ_Z_inflate':
inflate.c:(.text.MOZ_Z_inflate+0x5b8): undefined reference to `memcpy@@GLIBC_2.0'
inflate.o:inflate.c:(.text.MOZ_Z_inflate+0xa78): more undefined references to `memcpy@@GLIBC_2.0' follow
collect2: ld returned 1 exit status
make[4]: *** [libmozz.so] Error 1
make[4]: Leaving directory `/home/lefevre/software/moz-source/mozilla/obj-sunbird/modules/zlib/src'
make[3]: *** [libs] Error 2
make[3]: Leaving directory `/home/lefevre/software/moz-source/mozilla/obj-sunbird/modules/zlib'
make[2]: *** [tier_1] Error 2
make[2]: Leaving directory `/home/lefevre/software/moz-source/mozilla/obj-sunbird'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/home/lefevre/software/moz-source/mozilla/obj-sunbird'
make: *** [build] Error 2

Comment 17

[cls]

The memcpy errors are due to a gcc bug.  Try applying the patch from bug 302879.  

Something changed in either the build configuration or the configure script since the bug report was originally filed.  The configure output shows that it is properly detecting that the compiler is gcc and it's using c++ to create shared libs.  This can probably be marked WORKSFORME once the memcpy issue is resolved.

Comment 18

[cls]

(In reply to comment #17)
> The memcpy errors are due to a gcc bug.  Try applying the patch from bug
> 302879.  

*sigh* I meant bug 307168 .

Comment 19

[Vincent Lefevre]

Th patch doesn't solve the problem.

Comment 20

[Phoenix]

That's was too long ago...