202186 - some parts of build use "gcc" instead of $CC

Status: RESOLVED DUPLICATE of bug 93206

(SeaMonkey :: Build Config, defect)

Description

[Calum Mackay]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030415 Phoenix/0.5+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030415 Phoenix/0.5+

Having several versions of gcc on my system, I use:

export CC=gcc-2.95
export CXX=g++-2.95

to force the use of 2.95 before running configure [this is to enable working
with the Sun Java plugin].

configure sees these settings:

checking for gcc... (cached) gcc-2.95
checking whether the C compiler (gcc-2.95  ) works... yes
checking whether the C compiler (gcc-2.95  ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc-2.95 accepts -g... (cached) yes
checking for c++... (cached) g++-2.95
checking whether the C++ compiler (g++-2.95  ) works... yes
checking whether the C++ compiler (g++-2.95  ) is a cross-compiler... no
checking whether we are using GNU C++... (cached) yes
checking whether g++-2.95 accepts -g... (cached) yes

and most of the build seems to use them:

gcc-2.95 -DOSTYPE=\"Linux2.4\" -DOSARCH=\"Linux\" -D_BSD_SOURCE   -I../dist/incl
ude -I../dist/include -I/usr/local/src/mozilla/cvs/mozilla/dist/include/nspr    
  -I/usr/X11R6/include   -fPIC -I/usr/X11R6/include -Wall -W -Wno-unused -Wpoint
er-arith -Wcast-align -pedantic -Wno-long-long -pthread -pipe  -DNDEBUG -DTRIMME
D -O2 -march=i686  -I/usr/X11R6/include -include ../mozilla-config.h -DMOZILLA_C
LIENT  -I/usr/include/glib-1.2 -I/usr/lib/glib/include -o elf-dynstr-gc elf-dyns
tr-gc.c    -L/usr/lib -lglib 

g++-2.95 -o nsASingleFragmentString.o -c -DOSTYPE=\"Linux2.4\" -DOSARCH=\"Linux\
" -D_IMPL_NS_COM  -I../../dist/include/xpcom -I../../dist/include/string -I../..
/dist/include -I/usr/local/src/mozilla/cvs/mozilla/dist/include/nspr      -I/usr
/X11R6/include   -fPIC  -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wc
onversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dt
or-privacy -pedantic -Wno-long-long -pthread -pipe  -DNDEBUG -DTRIMMED -O2 -marc
h=i686  -I/usr/X11R6/include -DMOZILLA_CLIENT -include ../../mozilla-config.h -W
p,-MD,.deps/nsASingleFragmentString.pp nsASingleFragmentString.cpp

However, parts of the build do not:

gcc -o Linux2.4_x86_glibc_PTH_OPT.OBJ/nsinstall.o -c -O2 -fPIC -DLINUX1_2 -Di386
 -D_XOPEN_SOURCE -DLINUX2_1 -ansi -Wall -pipe -DLINUX -Dlinux -D_POSIX_SOURCE -D
_BSD_SOURCE -DHAVE_STRERROR -DXP_UNIX -UDEBUG -DNDEBUG -D_REENTRANT -I/usr/local
/src/mozilla/cvs/mozilla/dist/include  -I../../../dist/public/coreconf -I../../.
./dist/private/coreconf -I../../../dist/include -I/usr/local/src/mozilla/cvs/moz
illa/dist/include/nspr -I/usr/local/src/mozilla/cvs/mozilla/dist/include/dbm  ns
install.c
gcc -o Linux2.4_x86_glibc_PTH_OPT.OBJ/pathsub.o -c -O2 -fPIC -DLINUX1_2 -Di386 -
D_XOPEN_SOURCE -DLINUX2_1 -ansi -Wall -pipe -DLINUX -Dlinux -D_POSIX_SOURCE -D_B
SD_SOURCE -DHAVE_STRERROR -DXP_UNIX -UDEBUG -DNDEBUG -D_REENTRANT -I/usr/local/s
rc/mozilla/cvs/mozilla/dist/include  -I../../../dist/public/coreconf -I../../../
dist/private/coreconf -I../../../dist/include -I/usr/local/src/mozilla/cvs/mozil
la/dist/include/nspr -I/usr/local/src/mozilla/cvs/mozilla/dist/include/dbm  path
sub.c

on my system, plain gcc is:

gcc version 3.2.3 20030407 (Debian prerelease)

which I don't want to use during the build.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Calum Mackay]

I count almost half of the compilations using gcc instead of gcc-2.95. I'm
clearly doing something wrong, but what?

$ grep '^gcc ' /usr/local/src/mozilla/build.log | wc -l
    274

$ grep '^gcc-2.95 ' /usr/local/src/mozilla/build.log | wc -l
    335

Ironically, all 1800 commands involving g++ use g++-2.95

The first occurnce of plain gcc is in:

make[4]: Entering directory `/usr/local/src/mozilla/cvs/mozilla/security/corecon
f/nsinstall'
gcc -o Linux2.4_x86_glibc_PTH_OPT.OBJ/nsinstall.o -c -O2 -fPIC -DLINUX1_2 -Di386
 -D_XOPEN_SOURCE -DLINUX2_1 -ansi -Wall -pipe -DLINUX -Dlinux -D_POSIX_SOURCE -D
_BSD_SOURCE -DHAVE_STRERROR -DXP_UNIX -UDEBUG -DNDEBUG -D_REENTRANT -I/usr/local
/src/mozilla/cvs/mozilla/dist/include  -I../../../dist/public/coreconf -I../../.
./dist/private/coreconf -I../../../dist/include -I/usr/local/src/mozilla/cvs/moz
illa/dist/include/nspr -I/usr/local/src/mozilla/cvs/mozilla/dist/include/dbm  ns
install.c

Comment 2

[Calum Mackay]

Oops. This isn't firebird specific; exactly same behaviour when building
mozilla, I'd just never spotted it before.

Moving to browser/build-config.

Comment 3

[Mitch]

Can;t confirm reporter's behavior. I have done a full build explicitly
specifying a compiler not in my patch (although there are alternate
compilers in my path) and after trawling the typescript file (from the
unix script command) i can see no references of it executing any other
available gcc compilers than the one i specify.

Comment 4

[Mitch]

Note, my reported unconfirming behavior is on Solaris, though i don't
see how this could make a difference since the Makefiles are essentially
the same - i use gcc and gmake on Solaris which is the equivalent on Linux. 

Comment 5

[Roland Mainz]

Dave Baker wrote:
> Can;t confirm reporter's behavior. I have done a full build explicitly
> specifying a compiler not in my patch

If I remember it correctly the build system has a extra flag to remember whether
gcc or another compiler is being used. I guess this explains the expected
behaviour: non-gcc compilers us explcitly the compiler set via ${CC}/${CXX},
others use "gcc", sometimes ignoring what is used in ${CC}/${CXX} ...

CC:'ing cls to take a look at this issue...

Comment 6

[hacker formerly known as [e-mail]]

*** This bug has been marked as a duplicate of 93206 ***

Comment 7

[Mitch]

 
I have tracked this problem down. It  happens on Linux because
the security/coreconf/Linux.mk explicitly specify CC and CCC.
This happens for the security libs libssl.so, libsoftokn3.so,
libnss3.so etc..

I guess the same thing must be happening on Solaris too though
since i use a hybrid build environment (gcc + sun linker) i'm not
sure Solaris is affected.

I think this is a relic of when the security layer was outside the
mozilla tree.

Reporter should submit fixes if required. The file security/coreconf/README
should be perused before making changes however.