398279 - Build not using build tools defined in .mozconfig

Status: RESOLVED INVALID

(NSPR :: NSPR, defect)

Description

[Simon Strandman]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; sv-SE; rv:1.9a9pre) Gecko/2007092704 Minefield/3.0a9pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; sv-SE; rv:1.9a9pre) Gecko/2007092704 Minefield/3.0a9pre

Hello

There is a problem with the mozilla build scripts when defining your own values for LD, AS etc. I have put this in my .mozconfig:

CC="llvm-gcc"
CXX="llvm-g++"
AS="llvm-as"
AR="llvm-ar"
LD="llvm-ld"
RANLIB="llvm-ranlib"

The first configure-script that runs when running make -f client.mk build picks those up:

hecking whether the C++ compiler (llvm-g++ -O3 -pipe -march=nocona ) works... yes
checking whether the C++ compiler (llvm-g++ -O3 -pipe -march=nocona ) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether llvm-g++ accepts -g... yes
checking for ranlib... llvm-ranlib
checking for llvm-as... /usr/local/bin/llvm-as
checking for ar... llvm-ar
checking for ld... llvm-ld

But the second script from the nsprpub dir detects it's own values for ar and ld:

checking whether the C compiler (llvm-gcc  ) works... yes
checking whether the C compiler (llvm-gcc  ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether llvm-gcc accepts -g... (cached) yes
checking how to run the C preprocessor... (cached) llvm-gcc -E
checking for ranlib... (cached) llvm-ranlib
checking for as... (cached) /usr/local/bin/llvm-as
checking for ar... /usr/bin/ar
checking for ld... /usr/bin/ld

The build then eventually fails with an error because it tries to use the wrong ld (/usr/bin/ld instead of the one I have defined in .mozconfig). If I use ac_add_options --cache-file=/dev/null all the values from the second script is wrong.

I know that building with llvm is probably not supported but this is a problem with the build scripts, it should use the values I have defined in .mozconfig and not trying to autodetect them.

Reproducible: Always

Steps to Reproduce:
1. Define LD and AR in .mozconfig
2. Start the build with make -f client.mk build
Actual Results:  
The build is still using the system's default ld and ar instead of those I have defined.

Expected Results:  
The build should have used my values from .mozconfig.

This is my .mozconfig:

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-bygge
. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_CO_LOCALES="sv-SE"

CFLAGS="-O3 -pipe -march=nocona"
CXXFLAGS="-O3 -pipe -march=nocona"
MAKEOPTS="-j3"

CC="llvm-gcc"
CXX="llvm-g++"
AS="llvm-as"
AR="llvm-ar"
LD="llvm-ld"
RANLIB="llvm-ranlib"

ac_add_options --enable-ui-locale=sv-SE

ac_add_options --enable-optimize="$CFLAGS"
ac_add_options --disable-debug

ac_add_options --disable-shared

ac_add_options --enable-official-branding
ac_add_options --disable-tests
ac_add_options --disable-installer
ac_add_options --disable-libxul
ac_add_options --disable-codesighs
mk_add_options MOZ_MAKE_FLAGS=-j3

ac_add_options --enable-default-toolkit=cairo-cocoa

#ac_add_options --enable-strip

ac_add_options --enable-static

ac_add_options --enable-static-libs
#ac_add_options --enable-pthreads
ac_add_options --enable-svg
ac_add_options --enable-canvas
ac_add_options --enable-extensions="default"

Comment 1

[(not currently active) Ted Mielczarek]

-> NSPR

Comment 2

[cls]

mozconfig is only read by the toplevel configure file so NSPR's configure doesn't know those values are set.  If you want to pass the values down to the sub-configures, you need to make sure that they are set in the environment by adding:
    export CC CXX AS AR LD RANLIB
to your mozconfig file.

Comment 3

[(not currently active) Ted Mielczarek]

cls: from his build output, it looks like NSPR picks up his CC/CXX/AS, but not AR/LD.  I would say that sounds like a problem with NSPR's configure.

Comment 4

[cls]

Re-read his comment.  NSPR is picking up those values from the toplevel configure's config.cache.  Since NSPR uses a different check for some of the tools (AC_CHECK_PROGS vs AC_PATH_PROGS), it uses a different cache variable.  Given that NSPR is a standalone project, it's not required to use the same cache variables and tool checks.  It Would Be Nice(tm) but not it's not required.  Using  --cache-file=/dev/null (a valid config) clearly shows that the variables aren't being set in the environment that's being exported to the NSPR configure process.