Michael Jennings Reporter
	Description • 12 years ago

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

	Andrey Gursky
	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.

	girish
	Comment 3 • 12 years ago

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

	Karl Tomlinson (:karlt)
	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.

	Andrey Gursky
	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.

	Michael Jennings Reporter
	Comment 6 • 12 years ago

Same exact problem still exists in 16.0.1.

	Michael Jennings 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

	bitmancer.bassplayer
	Comment 8 • 12 years ago

Same exact build  problem in 17esr for linux

	Kevin Brosnan [Ex-Mozilla]
	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

	Elio Maldonado
	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.

	Michael Jennings 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.  :-)

	Elio Maldonado
	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.

	Elio Maldonado
	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.

	Elio Maldonado
	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.

	Wan-Teh Chang
	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.

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
	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.

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
	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).

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
	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.

	Michael Jennings 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.  ;-)

	Mike Hommey [:glandium]
	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

	Michael Jennings 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.

	Mike Hommey [:glandium]
	Comment 24 • 12 years ago

Ah, you're building in the source directory...

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
	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.

	Michael Jennings 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.

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
	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.

	Mike Hommey [:glandium]
	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.

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
	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.

	Michael Jennings 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!

	Benjamin Smedberg
	Comment 31 • 12 years ago

That would be bug 241047.

	dettox
	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)

	se.raschka
	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)
~

	Skippy le Grand Gourou
	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.