Open
Bug 797508
Opened 12 years ago
Updated 2 years ago
Firefox fails to build when objdir == srcdir: /usr/bin/ld:security/nss/lib/util/nssutil.def:1: syntax error in VERSION script
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
NEW
People
(Reporter: mej, Unassigned)
References
Details
(Keywords: regression)
Attachments
(3 files, 1 obsolete file)
8.31 KB,
text/plain
|
Details | |
144.85 KB,
patch
|
elio.maldonado.batiz
:
review-
|
Details | Diff | Splinter Review |
898 bytes,
patch
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 Build ID: 20120322142600 Steps to reproduce: Attempted to build Firefox 15.0.1 from source on Scientific Linux 6.3. Actual results: I received the following error: ... ranlib /home/mej/.../mozilla-release/security/nss/lib/util/libnssutil.a rm -f /home/mej/.../mozilla-release/security/nss/lib/util/libnssutil3.so gcc -shared -Wl,-z,defs -Wl,-soname -Wl,libnssutil3.so -Wl,--version-script,/home/mej/.../mozilla-release/security/nss/lib/util/nssutil.def -o /home/mej/.../mozilla-release/security/nss/lib/util/libnssutil3.so /home/mej/.../mozilla-release/security/nss/lib/util/quickder.o /home/mej/.../mozilla-release/security/nss/lib/util/secdig.o /home/mej/.../mozilla-release/security/nss/lib/util/derdec.o /home/mej/.../mozilla-release/security/nss/lib/util/derenc.o /home/mej/.../mozilla-release/security/nss/lib/util/dersubr.o /home/mej/.../mozilla-release/security/nss/lib/util/dertime.o /home/mej/.../mozilla-release/security/nss/lib/util/errstrs.o /home/mej/.../mozilla-release/security/nss/lib/util/nssb64d.o /home/mej/.../mozilla-release/security/nss/lib/util/nssb64e.o /home/mej/.../mozilla-release/security/nss/lib/util/nssrwlk.o /home/mej/.../mozilla-release/security/nss/lib/util/nssilock.o /home/mej/.../mozilla-release/security/nss/lib/util/oidstring.o /home/mej/.../mozilla-release/security/nss/lib/util/portreg.o /home/mej/.../mozilla-release/security/nss/lib/util/secalgid.o /home/mej/.../mozilla-release/security/nss/lib/util/secasn1d.o /home/mej/.../mozilla-release/security/nss/lib/util/secasn1e.o /home/mej/.../mozilla-release/security/nss/lib/util/secasn1u.o /home/mej/.../mozilla-release/security/nss/lib/util/secitem.o /home/mej/.../mozilla-release/security/nss/lib/util/secload.o /home/mej/.../mozilla-release/security/nss/lib/util/secoid.o /home/mej/.../mozilla-release/security/nss/lib/util/sectime.o /home/mej/.../mozilla-release/security/nss/lib/util/secport.o /home/mej/.../mozilla-release/security/nss/lib/util/templates.o /home/mej/.../mozilla-release/security/nss/lib/util/utf8.o -L/home/mej/.../mozilla-release/security/manager/../../dist/lib -L/home/mej/.../mozilla-release/dist/lib -lplc4 -lplds4 -lnspr4 -lpthread -ldl -lc /usr/bin/ld:/home/mej/.../mozilla-release/security/nss/lib/util/nssutil.def:1: syntax error in VERSION script collect2: ld returned 1 exit status make[5]: *** [/home/mej/.../mozilla-release/security/nss/lib/util/libnssutil3.so] Error 1 make[5]: Leaving directory `/home/mej/.../mozilla-release/security/nss/lib/util' make[4]: *** [libs] Error 2 make[4]: Leaving directory `/home/mej/.../mozilla-release/security/nss/lib' make[3]: *** [libs] Error 2 make[3]: Leaving directory `/home/mej/.../mozilla-release/security/manager' make[2]: *** [libs_tier_platform] Error 2 make[2]: Leaving directory `/home/mej/.../mozilla-release' make[1]: *** [tier_platform] Error 2 make[1]: Leaving directory `/home/mej/.../mozilla-release' make: *** [default] Error 2 Expected results: Successful build
Comment 1•12 years ago
|
||
I'm experiencing the same, building thunderbird 15.0.1 from source: ./configure \ --prefix=/opt/thunderbird-dbg \ --with-pthreads \ --with-system-jpeg \ --with-system-zlib \ --with-system-bz2 \ --enable-system-hunspell \ --enable-application=mail \ --enable-default-toolkit=cairo-gtk2 \ --enable-official-branding \ --enable-gio \ --disable-updater \ --enable-system-sqlite \ --enable-debug \ --disable-optimize \ --enable-debug-symbols \ --enable-logrefcnt \ --enable-trace-malloc \ --disable-necko-wifi $ time make ... rm -f /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/libnssutil3.so gcc -shared -Wl,-z,defs -Wl,-soname -Wl,libnssutil3.so -Wl,--version-script,/home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/nssutil.def -o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/libnssutil3.so /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/quickder.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/secdig.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/derdec.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/derenc.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/dersubr.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/dertime.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/errstrs.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/nssb64d.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/nssb64e.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/nssrwlk.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/nssilock.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/oidstring.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/portreg.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/secalgid.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/secasn1d.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/secasn1e.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/secasn1u.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/secitem.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/secload.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/secoid.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/sectime.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/secport.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/templates.o /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/utf8.o -L/home/andrey/Downloads/thunderbird/comm-release/mozilla/security/manager/../../dist/lib -L/home/andrey/Downloads/thunderbird/comm-release/mozilla/dist/lib -lplc4 -lplds4 -lnspr4 -lpthread -ldl -lc /usr/bin/ld:/home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/nssutil.def:1: syntax error in VERSION script collect2: error: ld returned 1 exit status make[6]: *** [/home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/libnssutil3.so] Error 1 make[6]: Leaving directory `/home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util' make[5]: *** [libs] Error 2 make[5]: Leaving directory `/home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib' make[4]: *** [libs] Error 2 make[4]: Leaving directory `/home/andrey/Downloads/thunderbird/comm-release/mozilla/security/manager' make[3]: *** [libs_tier_platform] Error 2 make[3]: Leaving directory `/home/andrey/Downloads/thunderbird/comm-release/mozilla' make[2]: *** [tier_platform] Error 2 make[2]: Leaving directory `/home/andrey/Downloads/thunderbird/comm-release/mozilla' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/andrey/Downloads/thunderbird/comm-release/mozilla' make: *** [default] Error 2 real 145m56.979s user 126m22.806s sys 10m54.197s $ I've attached /home/andrey/Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/nssutil.def.
Comment 2•12 years ago
|
||
Updated•12 years ago
|
Component: Untriaged → XULRunner
Product: Firefox → Toolkit
I am also facing the same issue . Kindly let me know is any soultion . build/TCNG_TOOLCHAIN/i686-lds4ltsn-linux-gnu/bin/../lib/gcc/i686-lds4ltsn-linux-gnu/4.4.5/../../../../i686-lds4ltsn-linux-gnu/bin/ld:/build/tcng_buildroot/buildroot/output/build/tcng_firefox-15.0.1/security/nss/lib/util/nssutil.def:1: syntax error in VERSION script collect2: ld returned 1 exit status make[6]: *** [/build/tcng_buildroot/buildroot/output/build/tcng_firefox-15.0.1/security/nss/lib/util/libnssutil3.so] Error 1 make[6]: Leaving directory `/build/tcng_buildroot/buildroot-2011.02/output/build/tcng_firefox-15.0.1/security/nss/lib/util' make[5]: *** [libs] Error 2 make[5]: Leaving directory `/build/tcng_buildroot/buildroot-2011.02/output/build/tcng_firefox-15.0.1/security/nss/lib' make[4]: *** [libs] Error 2 make[4]: Leaving directory `/build/tcng_buildroot/buildroot-2011.02/output/build/tcng_firefox-15.0.1/security/manager' make[3]: *** [libs_tier_platform] Error 2 make[3]: Leaving directory `/build/tcng_buildroot/buildroot-2011.02/output/build/tcng_firefox-15.0.1' make[2]: *** [tier_platform] Error 2 make[2]: Leaving directory `/build/tcng_buildroot/buildroot-2011.02/output/build/tcng_firefox-15.0.1' make[1]: *** [default] Error 2 make[1]: Leaving directory `/build/tcng_buildroot/buildroot-2011.02/output/build/tcng_firefox-15.0.1' make: *** [/build/tcng_buildroot/buildroot/output/build/tcng_firefox-15.0.1/.stamp_built] Error
Comment 4•12 years ago
|
||
Looks like the source nssutil.def is being used instead of the preprocessed file, which is usually in a separate object directory. The source file should be called nssutil.def.in or similar, but you may have more success with a separate object directory. Don't know whether make -f client.mk build creates a separate object directory by default or whether "mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj" in .mozconfig is necessary.
Component: XULRunner → Security: PSM
Flags: needinfo+
Product: Toolkit → Core
Comment 5•12 years ago
|
||
Karl, thank you for the tip! Now, knowing what I should look for, I've figured out some details for this fault: comm-release/mozilla/security/coreconf/rules.mk contains: $(MAPFILE): $(MAPFILE_SOURCE) @$(MAKE_OBJDIR) $(PROCESS_MAP_FILE) comm-release/mozilla/security/nss/lib/util/manifest.mn contains: # don't duplicate module name in REQUIRES MAPFILE = $(OBJDIR)/nssutil.def but unfortunately the source file is called also nssutil.def instead of obviously nssutil.def.in! That's why make does nothing (no preprocessing) with it, assuming all is already done. I'd propose to rename all such files from .def to .def.in. As Karl pointed it out, it is what one expects. And the out-of-the-box building of thunderbird/firefox/... would be possible. Defining an object directory for out-of-tree build is an option, but nice to have, building thunderbird from source. Compiling the libnss separately the proper object directory (in my case, Linux3.5_x86_glibc_PTH_OPT.OBJ) is somehow set and used in each source folder (not clean out-of-tree build). And there is no MOZ_OBJDIR.
Reporter | ||
Comment 6•12 years ago
|
||
Same exact problem still exists in 16.0.1.
Version: 15 Branch → 16 Branch
Reporter | ||
Comment 7•12 years ago
|
||
I was able to fix the problem via the attached patch and running the following shell command prior to building: find security \( -name '*.def' -a '!' -name '*_hash.def' \) -print | while read MAPFILE ; do mv $MAPFILE $MAPFILE.in ; done
Comment 8•12 years ago
|
||
Same exact build problem in 17esr for linux
Comment 9•12 years ago
|
||
The patch attached in comment 6 needs a review request https://developer.mozilla.org/en-US/docs/Developer_Guide/How_to_Submit_a_Patch#Getting_the_patch_reviewed
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•12 years ago
|
Assignee: nobody → nobody
Component: Security: PSM → Build
Product: Core → NSS
Version: 16 Branch → trunk
Updated•12 years ago
|
Attachment #670939 -
Flags: review?(emaldona)
Comment 10•12 years ago
|
||
Comment on attachment 670939 [details] [diff] [review] Changes source for mapfiles to use .in suffix First let me point out that my knowledge if of coreconf may not be up to par with what's needed for this review. I seldom build mozilla Firefox. The patch has the mozilla format so I applied it manually to my CVS checkout of NSS. The build failed. .... ar cr Linux3.7_x86_glibc_PTH_DBG.OBJ/libnssutil.a Linux3.7_x86_glibc_PTH_DBG.OBJ/quickder.o Linux3.7_x86_glibc_PTH_DBG.OBJ/secdig.o Linux3.7_x86_glibc_PTH_DBG.OBJ/derdec.o Linux3.7_x86_glibc_PTH_DBG.OBJ/derenc.o Linux3.7_x86_glibc_PTH_DBG.OBJ/dersubr.o Linux3.7_x86_glibc_PTH_DBG.OBJ/dertime.o Linux3.7_x86_glibc_PTH_DBG.OBJ/errstrs.o Linux3.7_x86_glibc_PTH_DBG.OBJ/nssb64d.o Linux3.7_x86_glibc_PTH_DBG.OBJ/nssb64e.o Linux3.7_x86_glibc_PTH_DBG.OBJ/nssrwlk.o Linux3.7_x86_glibc_PTH_DBG.OBJ/nssilock.o Linux3.7_x86_glibc_PTH_DBG.OBJ/oidstring.o Linux3.7_x86_glibc_PTH_DBG.OBJ/portreg.o Linux3.7_x86_glibc_PTH_DBG.OBJ/secalgid.o Linux3.7_x86_glibc_PTH_DBG.OBJ/secasn1d.o Linux3.7_x86_glibc_PTH_DBG.OBJ/secasn1e.o Linux3.7_x86_glibc_PTH_DBG.OBJ/secasn1u.o Linux3.7_x86_glibc_PTH_DBG.OBJ/secitem.o Linux3.7_x86_glibc_PTH_DBG.OBJ/secload.o Linux3.7_x86_glibc_PTH_DBG.OBJ/secoid.o Linux3.7_x86_glibc_PTH_DBG.OBJ/sectime.o Linux3.7_x86_glibc_PTH_DBG.OBJ/secport.o Linux3.7_x86_glibc_PTH_DBG.OBJ/templates.o Linux3.7_x86_glibc_PTH_DBG.OBJ/utf8.o Linux3.7_x86_glibc_PTH_DBG.OBJ/utilmod.o Linux3.7_x86_glibc_PTH_DBG.OBJ/utilpars.o ranlib Linux3.7_x86_glibc_PTH_DBG.OBJ/libnssutil.a make: *** No rule to make target nssutil.def.in. Stop.
Attachment #670939 -
Flags: review?(wtc)
Updated•12 years ago
|
Attachment #670939 -
Flags: review?(emaldona) → review-
Reporter | ||
Comment 11•12 years ago
|
||
(In reply to Elio Maldonado from comment #10) > Comment on attachment 670939 [details] [diff] [review] > Changes source for mapfiles to use .in suffix > > First let me point out that my knowledge if of coreconf may not be up to par > with what's needed for this review. I seldom build mozilla Firefox. The > patch has the mozilla format so I applied it manually to my CVS checkout of > NSS. The build failed. > .... > make: *** No rule to make target nssutil.def.in. Stop. Looks like you missed this part of comment #7: find security \( -name '*.def' -a '!' -name '*_hash.def' \) -print | while read MAPFILE ; do mv $MAPFILE $MAPFILE.in ; done The patch must be applied AND this command must be executed for it to work. I've used this to build every version of Firefox since 15, so I'm quite sure it works. :-)
Comment 12•12 years ago
|
||
(In reply to Michael Jennings from comment #11) > Looks like you missed this part of comment #7: Indeed, I missed it. > > find security \( -name '*.def' -a '!' -name '*_hash.def' \) -print | while > read MAPFILE ; do mv $MAPFILE $MAPFILE.in ; done > > The patch must be applied AND this command must be executed for it to work. Miahael, Afer applyimg my CVS version of you patch I ran this script inspired on yours. -------------------------------------------------------------------------------------- #!/usr/bin/bash cd mozilla/security MAPFILES=`find . -name '*.def' -a '!' -name '*_hash.def'` for f in $MAPFILES; do mv $f $f.in cvs rm $f cvs add $f.in done cd - --------------------------------------------------------------------------------------- It also also cvs removes the old nes and cvs add's the renamed ones which gave me a fuller patch ready for review and commit once r+'ed. I'll this revised one next. Thank you for the patch.
Comment 13•12 years ago
|
||
Attachment #670939 -
Attachment is obsolete: true
Attachment #670939 -
Flags: review?(wtc)
Attachment #690236 -
Flags: review?(wtc)
Updated•12 years ago
|
Attachment #690236 -
Flags: review?(emaldona)
Comment 14•12 years ago
|
||
Comment on attachment 690236 [details] [diff] [review] V2: Changess source for mapfiles to use .in suffix - for CVS Not ready, it failed to build on my Windows VM.
Attachment #690236 -
Flags: review?(wtc)
Attachment #690236 -
Flags: review?(emaldona)
Attachment #690236 -
Flags: review-
Comment 15•12 years ago
|
||
This is the error I get on Windows: make[3]: Entering directory `/c/Users/emaldona/mozilla/NSS/mozilla/security/nss/lib/freebl' nsinstall -m 664 WINNT6.1_OPT.OBJ/freebl.lib ../../../../dist/WINNT6.1_OPT.OBJ/lib make FREEBL_CHILD_BUILD=1 \ OBJDIR=WINNT6.1_OPT.OBJ/WINNT_SINGLE_SHLIB libs make[4]: Entering directory `/c/Users/emaldona/mozilla/NSS/mozilla/security/nss/lib/freebl' make[4]: *** No rule to make target `freebl.def', needed by `WINNT6.1_OPT.OBJ/WINNT_SINGLE_SHLIB/freebl.def'. Stop.
Comment 16•12 years ago
|
||
(In reply to Andrey Gursky from comment #5) > Karl, thank you for the tip! > Now, knowing what I should look for, I've figured out some details for this > fault: > comm-release/mozilla/security/coreconf/rules.mk contains: > $(MAPFILE): $(MAPFILE_SOURCE) > @$(MAKE_OBJDIR) > $(PROCESS_MAP_FILE) > > comm-release/mozilla/security/nss/lib/util/manifest.mn contains: > # don't duplicate module name in REQUIRES > MAPFILE = $(OBJDIR)/nssutil.def > > but unfortunately the source file is called also nssutil.def instead of > obviously nssutil.def.in! That's why make does nothing (no preprocessing) > with it, assuming all is already done. Something in your environment or build script causes $(OBJDIR) to be wrong. In a correct build setup, $(MAPFILE) and $(MAPFILE_SOURCE) should be in different directories. This is what allows them to have the same file name. I think this build error may have been introduced by a recent change to Mozilla's build system. When building NSS directory in the source tree, the build output (the .o, .a, and .so files) should be placed in subdirectories that look like Linux3.7_x86_glibc_PTH_DBG.OBJ. But your build output shows they are directly generated in the same directory as the .c/.h source files, for example, /home/mej/.../mozilla-release/security/nss/lib/util/quickder.o /Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/quickder.o We should find out why Linux3.7_x86_glibc_PTH_DBG.OBJ does not show up in the pathnames of these .o, .a, and .so files.
Comment 17•12 years ago
|
||
(In reply to Wan-Teh Chang from comment #16) > I think this build error may have been introduced by a recent change to > Mozilla's build system. When building NSS directory in the source tree, > the build output (the .o, .a, and .so files) should be placed in > subdirectories > that look like Linux3.7_x86_glibc_PTH_DBG.OBJ. But your build output shows > they are directly generated in the same directory as the .c/.h source files, > for example, > /home/mej/.../mozilla-release/security/nss/lib/util/quickder.o > /Downloads/thunderbird/comm-release/mozilla/security/nss/lib/util/quickder.o > > We should find out why Linux3.7_x86_glibc_PTH_DBG.OBJ does not show up in > the pathnames of these .o, .a, and .so files. See: http://hg.mozilla.org/mozilla-central/annotate/3905010a2346/security/build/Makefile.in#l151 When we build Gecko, MOZ_OBJDIR points to the root of a tree that will receive the generated files. Our makefile wrapper around NSS's makefile wrapper overrides NSS's OBJDIR so that NSS's build system will generate files in a directory structure rooted in $MOZ_OBJDIR/security/nss congruent to the source files' directory structure (which is rooted at $SRCDIR/security/nss). $OBJDIR_NAME is never added as a component of the paths of the generated files. I think this is a regression caused by recent changes to PSM's wrapper makefile around NSS's makefile, or to Mozilla's recent contributions to NSS's build system.
Assignee: nobody → nobody
Component: Build → Build Config
Keywords: regression
Product: NSS → Core
Version: trunk → Trunk
Comment 18•12 years ago
|
||
(In reply to Michael Jennings from comment #0) > Attempted to build Firefox 15.0.1 from source on Scientific Linux 6.3. Please let us know if you are having similar problems for newer Firefox versions too, so we can see if we need to backport a fix (if any).
Comment 19•12 years ago
|
||
(In reply to Brian Smith (:bsmith) from comment #18) > (In reply to Michael Jennings from comment #0) > > Attempted to build Firefox 15.0.1 from source on Scientific Linux 6.3. > > Please let us know if you are having similar problems for newer Firefox > versions too, so we can see if we need to backport a fix (if any). In particular, AFAICT only Firefox 17+ are being supported now. I am not sure why you're trying to build 15.0.1, but I'm not sure what the "support" status is for it. You may be more likely to get help if you can reproduce it building Firefox 18 or later.
Reporter | ||
Comment 20•12 years ago
|
||
(In reply to Brian Smith (:bsmith) from comment #19) > In particular, AFAICT only Firefox 17+ are being supported now. I am not > sure why you're trying to build 15.0.1, but I'm not sure what the "support" > status is for it. You may be more likely to get help if you can reproduce it > building Firefox 18 or later. Thanks for your comments, Brian. :-) As you can see from the timestamp on the bug (2012-10-03), version 15.0.1 was current when I filed it. I have been applying the same fix to every released version since then to get them to build. I noted in comment #6 that version 16.x still had the same issue. I apologize for not confirming that 17 has it too and updating the branch accordingly. I can confirm that 17.0.1 has the exact same build failure without the above fix: /usr/bin/ld:/home/mej/cvs/mej/pkgs/firefox/build.mezz/BUILD/mozilla-release/security/nss/lib/util/nssutil.def:1: syntax error in VERSION script I'm rebuilding now with my fix applied. I suspect it will work, but I'll let you know if it doesn't. ;-)
Comment 21•12 years ago
|
||
(In reply to Michael Jennings from comment #20) > I'm rebuilding now with my fix applied. I suspect it will work, but I'll > let you know if it doesn't. ;-) Are you running configure with a relative directory? (like ../configure, as opposed to /full/path/to/configure). If yes, can you test this patch? http://hg.mozilla.org/integration/mozilla-inbound/rev/ba511a01e9c7
Reporter | ||
Comment 22•12 years ago
|
||
Reporter | ||
Comment 23•12 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #21) > Are you running configure with a relative directory? (like ../configure, as > opposed to /full/path/to/configure). Yes, I am. ./configure <options> > If yes, can you test this patch? > http://hg.mozilla.org/integration/mozilla-inbound/rev/ba511a01e9c7 That looked very promising, but unfortunately I still get the same error. I noticed this in the Makefile.in a few lines down: # Hack to force NSS build system to use "normal" object directories DEFAULT_GMAKE_FLAGS += BUILD='$(MOZ_BUILD_ROOT)/security/$$(subst $(shell cd $(topsrcdir); pwd)/security/,,$$(CURDIR))' The new patch I just submitted disables the substitution and allows 17.0.1 to successfully build.
Comment 24•12 years ago
|
||
Ah, you're building in the source directory...
Summary: Firefox 15.0.1 will not build: /usr/bin/ld:/home/mej/.../mozilla-release/security/nss/lib/util/nssutil.def:1: syntax error in VERSION script → Firefox fails to build when objdir == srcdir: /usr/bin/ld:security/nss/lib/util/nssutil.def:1: syntax error in VERSION script
Comment 25•12 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #24) > Ah, you're building in the source directory... I suggest that we change the build system to prohibit this, rather than jump through hoops to support it.
Reporter | ||
Comment 26•12 years ago
|
||
I'm sorry, but either you're mistaken, or this has become the default. I am not altering the default build directories in any way. After untarring the tarball, the commands I use are: ./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-application=browser --enable-official-branding --disable-crashreporter make That's it. I'm not messing with any build directories or paths.
Comment 27•12 years ago
|
||
(In reply to Michael Jennings from comment #26) > ./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu > --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr > --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc > --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 > --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib > --mandir=/usr/share/man --infodir=/usr/share/info > --enable-application=browser --enable-official-branding > --disable-crashreporter > make > > That's it. I'm not messing with any build directories or paths. That's pretty much the problem. Everybody else is using the MOZCONFIG option to set the path to a mozconfig file that contains a MOZ_OBJDIR option. For example, here's mine: . $topsrcdir/browser/config/mozconfig mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../ff-dbg mk_add_options MOZ_MAKE_FLAGS="-j10 -s" ac_add_options --enable-debug ac_add_options --disable-crashreporter ac_add_options --enable-chrome-format=symlink ac_add_options --enable-logging ac_add_options --enable-tests ac_add_options --disable-optimize I build with: MOZCONFIG=<path-to-that-file> make -j10 -f client.mk If you keep building without a MOZ_OBJDIR set, even if we fix *this* bug, you're pretty much guaranteed to run into similar bugs in the future. It is very unlikely you'll run into similar bugs in the future if you do things the way I suggest, because (almost) every full-time Firefox developer is doing things the suggested way, and also our automated build machines (see tbpl.mozilla.org) do things that way; if we break this kind of configuration, the breakage will immediately be detected and backed out.
Comment 28•12 years ago
|
||
Note you don't need to set a MOZ_OBJDIR at all, using client.mk will set one if it isn't set.
Comment 29•12 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #28) > Note you don't need to set a MOZ_OBJDIR at all, using client.mk will set one > if it isn't set. Also, when you build the way I suggest, you do not need (and shouldn't) run configure yourself.
Reporter | ||
Comment 30•12 years ago
|
||
For the record, I'm an end user, not a developer (of Firefox, at least). :-) So it sounds like the traditional build method (./configure ; make ; make install) was broken a few versions back, and the reason nobody caught it is because that's no longer the "correct" way to build. So I apologize for the red herring, but I want to mention two things in my defense! ;-) I've been building RPMs for Mozilla/Firefox this same way for many years (close to 10, I'd say), so the breakage was unexpected. Plus I found references to the same error from quite a few other users with no fixes offered. Now hopefully people will be able to find the solution here in this bug! Thanks to Brian and Mike for pointing me in the right direction! :-) For the benefit of any who might be building RPMs (like me), here's what I'm using: %prep %setup -q -n mozilla-release %build CFLAGS="%{?cflags:%{cflags}}%{!?cflags:$RPM_OPT_FLAGS}" CXXFLAGS="%{?cxxflags:%{cxxflags}}%{!?cflags:$RPM_OPT_FLAGS}" export CFLAGS CXXFLAGS cat <<EOF > rpm.mozconfig mk_add_options MOZ_MAKE_FLAGS="-j32" ac_add_options --prefix=%{_prefix} --libdir=%{_libdir} ac_add_options --enable-application=browser ac_add_options --enable-official-branding ac_add_options --disable-crashreporter EOF MOZCONFIG=$PWD/rpm.mozconfig %{__make} -j32 -f client.mk %install MOZCONFIG=$PWD/rpm.mozconfig %{__make} -j32 -f client.mk install DESTDIR=$RPM_BUILD_ROOT %{?mflags_install} (Substitute %{?_smp_mflags} for "-j32" if you use that macro.) Based on comment #25, you might want to close this bug (for Google-ability) and open a new one for altering the build system to prohibit objdir == srcdir builds. Anyway, thanks again!
Comment 31•12 years ago
|
||
That would be bug 241047.
Comment 32•12 years ago
|
||
here my changed /mozilla/security/build/Makefile after the ABS_topsrcdir 17.0 was able to build. ABS_topsrcdir := $(call core_abspath,$(topsrcdir)) #ABS_topsrcdir := $(shell cd $(topsrcdir); pwd) # Hack to force NSS build system to use "normal" object directories DEFAULT_GMAKE_FLAGS += BUILD='$(MOZ_BUILD_ROOT)/security/$$(subst $(ABS_topsrcdir)/security/,,$$(CURDIR))' DEFAULT_GMAKE_FLAGS += BUILD_TREE='$$(BUILD)' OBJDIR='$$(BUILD)' DEPENDENCIES='$$(BUILD)/.deps' SINGLE_SHLIB_DIR='$$(BUILD)' DEFAULT_GMAKE_FLAGS += SOURCE_XP_DIR=$(ABS_DIST)
Comment 33•11 years ago
|
||
I had the same problem with thunderbird 17.04 But a quick python script to rename the .def files into .def.in files was sufficient to get it work! import subprocess lList = subprocess.check_output("find ./ -name '*def' -print", shell=True).split() for i in lList: new = i + ".in" subprocess.call("mv %s %s" %(i, new), shell=True) ~
Comment 34•11 years ago
|
||
(In reply to Brian Smith (:briansmith, was :bsmith@mozilla.com) from comment #27) > That's pretty much the problem. Everybody else is using the MOZCONFIG option > to set the path to a mozconfig file that contains a MOZ_OBJDIR option. This "everybody else" seems to be much more knowledgeable than the standard user. > I build with: > > MOZCONFIG=<path-to-that-file> make -j10 -f client.mk > > If you keep building without a MOZ_OBJDIR set, even if we fix *this* bug, > you're pretty much guaranteed to run into similar bugs in the future. It is > very unlikely you'll run into similar bugs in the future if you do things > the way I suggest, because (almost) every full-time Firefox developer is > doing things the suggested way, and also our automated build machines (see > tbpl.mozilla.org) do things that way; Here is an easy and elegant way to fix this bug definitely : write an INSTALL file with build instructions in the main directory, telling people used to "the traditional build method (./configure ; make ; make install)", as said by Michael, and still used by probably more than 90 % of other software, is to be replaced by the clear, obvious and self-explanatory (I guess) "make -j10 -f client.mk". Also, make https://developer.mozilla.org/en-US/docs/Build_and_Install more visible. A link to this page (and by the way to the source packages) would be more than welcome on the thunderbird download webpage — unless it is deliberate to make people losing their time digging the web, of course.
Updated•7 years ago
|
Product: Core → Firefox Build System
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•