Closed Bug 302879 Opened 15 years ago Closed 8 years ago

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

Categories

(Firefox Build System :: General, defect, blocker)

Other
Linux
defect
Not set
blocker

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: vincent-moz, Unassigned)

Details

Attachments

(1 file, 2 obsolete files)

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.
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?
Assignee: mostafah → nobody
Component: General → Build Config
Product: Calendar → Core
QA Contact: general → build-config
Version: unspecified → Trunk
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
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.
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.
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...
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 » 
[...]
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.
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.
Attached file config.log (obsolete) —
Here's the config.log. Where does the Mozilla makefile store the configure output?
It doesn't.  You'll need to redirect the configure output to a file by hand.
Attached file Output of "make -f client.mk build" (obsolete) —
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? 
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
Yes, parallel builds are not supposed at the client.mk level.  Try adding '.NOTPARALLEL:' to the bottom of client.mk and try building again.
Attachment #201386 - Attachment is obsolete: true
Attachment #201392 - Attachment is obsolete: true
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
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.
(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 .
Th patch doesn't solve the problem.
That's was too long ago...
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.