Compiling GCC, not baking rpath correctly

[OstermanA]

I am attempting to compile my own copy of gcc 9.2.0 on CentOS 8 in a non-standard path, ~/tools/system. I have local copies of automake, autoconf, libtool, gmc, mpc and mpfr in there and they all work fine. However, when I compile gcc the build artifacts are not baking in the rpath, and will fail entirely as soon as it tries to switch to it's bootstrap executables. I've included -Wl,-rpath,/home/aosterman/tools/system/lib -Wl,-rpath,/home/aosterman/tools/system/lib64 in LDFLAGS, CFLAGS and CPPFLAGS and exported all of them. I can force the build to succeed by setting LD_LIBRARY_PATH, but the final result only works if I set it again at run time, which I absolutely do not want to do.

For my own sanity, I've actually written up my build process in a makefile to build everything, which can be found on github. The complete build log can be found here.

Does anyone know what I'm missing here? Everything else is working fine, and I've used a similar process to compile several other software sets in the past. How do I force gcc to compile while actually honoring LDFLAGS?

 

[dos2unix]

I usually do something like...

Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --libdir=/usr/lib64 --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux

Installing GCC: Configuration - GNU Project

Installing GCC: Configuration

gcc.gnu.org

in particular --libdir and --libexec, I rarely use rpath.

 

[OstermanA]

By default both --libdir and --libexec build themselves relative to --prefix, so I doubt that's it. The ./configure example above would be fine if I was installing a system copy, as libtool will take care of all that automagically by itself. My issue is that I'm trying to compile it in a non-standard location without root access.

More testing is needed, but it looks like setting LD_RUN_PATH while compiling causes it to bake rpath into the binaries correctly. Once I've tested some more, I'll confirm here and mark the topic resolved.

 

[OstermanA]

AHA! I think I found the root of my problems! Digging through the documentation for gcc, I find these:

--with-stage1-ldflags=flags

This option may be used to set linker flags to be used when linking stage 1 of GCC. These are also used when linking GCC if configured with --disable-bootstrap. If --with-stage1-libs is not set to a value, then the default is ‘-static-libstdc++ -static-libgcc’, if supported.
​

--with-stage1-libs=libs

This option may be used to set libraries to be used when linking stage 1 of GCC. These are also used when linking GCC if configured with --disable-bootstrap.
​

--with-boot-ldflags=flags

This option may be used to set linker flags to be used when linking stage 2 and later when bootstrapping GCC. If –with-boot-libs is not is set to a value, then the default is ‘-static-libstdc++ -static-libgcc’.
​

--with-boot-libs=libs

This option may be used to set libraries to be used when linking stage 2 and later when bootstrapping GCC.​

It doesn't say anything anywhere about it, but I can deduce from the existence of these flags that it ignores normal linker flags in environment variables during the build, on the basis that it doesn't have a way to know which stage(s) of the build they're for.