GCC specs file: how to get the installation path

Question

Instead of giving -Wl,-rpath=$HOME/local/gcc52/lib64 to each invocation of GCC 5.2 which I built from the source, I modified its spec file in this way:

*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:    %(linker) -rpath=%:getenv(HOME /local/gcc52/lib64) ...

But this depends on my specific installation under $HOME/local/gcc52. Are there better way to refer to the installation path of the invoked GCC itself?

This manual page did not help me much:

• https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html

Answer 1

When you’re compiling GCC, you need to pass the prefix you want to configure anyway. At that time, you can also give it the --with-specs option. Based on my experiments, the option --with-specs='%{!static:%x{-rpath='$prefix'/lib64} %x{-enable-new-dtags}}' (where $prefix should be replaced by the same path you pass to--prefix`) works (you need something more complicated for multilib support, of course).

Things to note:

• This isn’t properly documented anywhere, but it appears that, unlike with regular spec files, the --with-specs configure option applies to the command-line arguments passed to GCC itself. Thus, you can’t just try to modify the *link spec string.
• The %x sequence doesn’t change the GCC command line, but accumulates arguments to pass to the linker. That’s why I pass -rpath and -enable-new-dtags directly instead of via -Wl.
• There are a bunch of suggestions online for what specs to pass. I didn’t see this one anywhere, so it take it with a grain of salt. The reason I used my own is that all the others either modify a spec string like *link, which you cannot do with --with-specs, or they add options to the GCC command line using -Wl, which I’m fairly sure somebody said they had trouble with because in some cases it confused GCC when they weren’t linking. YMMV.
• If you use bootstrapping (which you usually are unless building a cross-compiler, in which case I could be wrong but I don’t think this particular rpath trick is useful anyway), this will add a RUNPATH to the GCC programs and shared libraries as well. This seems to be the correct option, because they were compiled against the libraries that are now in $prefix/lib64, but it’s worth noting.

• I added -enable-new-dtags, which puts this in DT_RUNPATH instead of DT_RPATH. This is the newer attribute which all the documentation says should be preferred, <sarcasm>which is why it requires an extra flag which isn’t clearly cross-referenced in the docs</sarcasm>. Among the differences between RPATH and RUNPATH are:

  • If RUNPATH is present, RPATH will be completely ignored.
  • The RPATH overrides LD_LIBRARY_PATH; the RUNPATH does not.
  • They work somewhat differently for dependencies of dependencies (RUNPATH is only searched for direct dependencies; RPATH is searched for indirect dependencies as long as nothing in the dependency chain has a RUNPATH). More details are available here.
  • I think that’s everything, but I wouldn’t be surprised if I’m missing something.

  As the article I linked above indicates, not everybody prefers RUNPATH to RPATH, but here it shouldn’t be an issue unless you mix code from different compilers requiring different compiler support libraries in a complicated way, and if you do that I don’t think there’s any one-size-fits-all solution.

Answer 2

As far as I can tell, GCC is very much dependent on the installation folder it was compiled for. I build RTEMS cross-compilation toolchains very frequently, and one of the first things I learned was that there are many places in the generated cross-compiler where the installation prefix (i.e. whatever was passed to --exec-prefix) is "burned" in.

"Learned" - as in, I tried to move the compiler's folder to a different path, and all hell broke loose :-)

My point: modifying specs files to make them point to paths in your install seems absolutely normal, as far as GCC is concerned.