CC and LDFLAGS in early final-system packages

[chris@…]

Several packages in the final-system have lines similar to this:

CC="gcc -isystem /usr/include" \
CXX="g++ -isystem /usr/include" \
LDFLAGS="-Wl,-rpath-link,/usr/lib:/lib" \
  ./configure [...]

This is found in most packages between Glibc and GCC in the final-system. There's no explanation given for these variables. I guess they're supposed to be to ensure that those packages look for headers and libs in the right place, though in my experience they build just fine without those. Also, even if the -isystem is needed, I believe that could just be added to GCC's specsfile during the toolchain adjustment, as LFS does.

And of course, if this stuff is needed/useful, it should also be on the rest of the packages between Glibc and GCC, even if only for consistency. Looking for thoughts from anyone who knows more than I do about how the toolchain all works together...

[Martin Ward]

The GCC -isystem option specifically says look in this directory before anything else for header files, however not before any specified -I directive, so effectively what happens is the program get local header files first from any -I directive, then /usr/include, rather than /tools/include.

The LDFLAGS option says GCC will pass the following option to the linking stage by using the -Wl flag, -rpath-link the says put these paths into the executables header, so that the directories are searched first at link time , so we link against the right library when building gmp, mpfr,mpc,isl, cloog etc,as we want them to link against those libraries just built rather than those in /tools as both binutils and gcc still refer to that for linking.

[William Harrington]

We can remove the variable as they are not needed. The linker should search by default in /lib and /usr/lib to begin with. No need to set rpath. For CC and CXX if we check the search paths from temp system gcc and it isn't searching in /usr/include then we will need to still use system so that the proper headers are searched until final system GCC is built.

[Martin Ward]

Please note its -rpath-link not rpath there is a difference in that the directories are not embedded into the executable, and the directories are used at link time not run time, which I believe is what we want.

[William Harrington]

I'm suspecting we don't need -rpath-link, only isystem /usr/include.

The toolchain adjustment already fixes the linking so that we are using ld from /lib.

echo "main(){}" | gcc -isystem /usr/include -x c -v -

Snipped some output and put important text in bold:

Reading specs from /tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/specs

gcc version 4.8.3 (GCC) COLLECT_GCC_OPTIONS='-isystem' '/usr/include' '-v' '-mtune=generic' '-march=x86-64'

/tools/libexec/gcc/x86_64-unknown-linux-gnu/4.8.3/cc1 -quiet -v -isystem /usr/include - -quiet -dumpbase - -mtune=generic -march=x86-64 -auxbase - -version -o /tmp/ccNAap0J.s

GNU C (GCC) version 4.8.3 (x86_64-unknown-linux-gnu)

compiled by GNU C version 4.8.3, GMP version 6.0.0, MPFR version 3.1.2-p10, MPC version 1.0.2

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/../../../../x86_64-unknown-linux-gnu/include" ignoring duplicate directory "/tools/include" #include "..." search starts here: #include <...> search starts here: /usr/include

/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/include /tools/include /tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/include-fixed

End of search list. GNU C (GCC) version 4.8.3 (x86_64-unknown-linux-gnu)

compiled by GNU C version 4.8.3, GMP version 6.0.0, MPFR version 3.1.2-p10, MPC version 1.0.2

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: ddaa4004ac5ad75f9131c672bab868c9 COLLECT_GCC_OPTIONS='-isystem' '/usr/include' '-v' '-mtune=generic' '-march=x86-64'

/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/../../../../x86_64-unknown-linux-gnu/bin/as -v --64 -o /tmp/cc2RXRSo.o /tmp/ccNAap0J.s

GNU assembler version 2.24 (x86_64-unknown-linux-gnu) using BFD version (GNU Binutils) 2.24 COMPILER_PATH=/tools/libexec/gcc/x86_64-unknown-linux-gnu/4.8.3/:/tools/libexec/gcc/x86_64-unknown-linux-gnu/4.8.3/:/tools/libexec/gcc/x86_64-unknown-linux-gnu/:/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/:/tools/lib/gcc/x86_64-unknown-linux-gnu/:/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/../../../../x86_64-unknown-linux-gnu/bin/ LIBRARY_PATH=/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/:/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/../../../../x86_64-unknown-linux-gnu/lib/../lib/:/usr/lib/../lib/:/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/../../../../x86_64-unknown-linux-gnu/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-isystem' '/usr/include' '-v' '-mtune=generic' '-march=x86-64'

/tools/libexec/gcc/x86_64-unknown-linux-gnu/4.8.3/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib/ld-linux-x86-64.so.2 /usr/lib/../lib/crt1.o /usr/lib/../lib/crti.o /tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/crtbegin.o -L/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.3 -L/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/../../../../x86_64-unknown-linux-gnu/lib/../lib -L/usr/lib/../lib -L/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/../../../../x86_64-unknown-linux-gnu/lib /tmp/cc2RXRSo.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/crtend.o /usr/lib/../lib/crtn.o

As you can tell, the linker path is already proper. No /tools/lib at all.

We can remove -rpath-linker and only use -isystem with CC and CXX

[William Harrington]

Since binutils and gcc are more mature than when these options were introduced, and the build system has been checked with 32bit, multi lib, and pure 64 bit, I'm suggesting we can remove LDFLAGS. We do need to keep isystem with CFLAGS and CXXFLAGS.