How to reconfigure GCC 4.8.5 to use an extra hardcoded library path by default when linking?

How to reconfigure GCC 4.8.5 to use an extra hardcoded library path by default when linking?

[Jens With]

I need to build and install a rather complex database application (made up of some C-programs and web apps), w/o any resort to root access, out of the sources including supporting OSS packages on a diversity of operating systems. 
If the preinstalled compilers don't fulfill the requirements of the code to be compiled (C99, C++11, etc.), I install a private GCC 4.8.5 including all required tools necessary to do that before building the rest of system, because upgrading the preinstalled compilers and tools is not an option. 
This works quite well except the tests for gfortran which come with libtool run into a dilemma that however environment variables I supply for "make check" some disjoint set of tests fail. A very simple solution is to add a runtime path for the private libdir in lib/libgfortran.spec after installation of GCC. Because since ever (20+ years) I use my own simple configuration tools, which implement how to build shared libraries and to link to on the supported platforms, I could even automate the manipulation of this file. I also know about "CC=$(which gcc) LD=$(which ld) GCC=yes with_gnu_ld=yes LDFLAGS= sh ./config.rpath $(sh ./config.guess)“ to make gcc tell me what I need to know to manipulate the spec file. But the best solution would be to modify and autoreconf GCC in a way that whatever the path of the private libdir is, this path would be hardcoded in the custom built GCC. 
I have seen some variable names with a prefix of hardcode_ in the configure scripts, but don’t know how make use of these to have at least generated a tailored fit gfortran.spec.

I hope I have given given enough details to explain my problem.

My dream would be a hint for simple modifications at the *.in/ac level.
An idea to modify the configure script would also be very helpful.

Thanks for any response!

Jens

Re: How to reconfigure GCC 4.8.5 to use an extra hardcoded library path by default when linking?

[Jonathan Wakely]

On Tue, 11 Aug 2020 at 12:21, Jens With <jens.with@t-online.de> wrote:
>
> I need to build and install a rather complex database application (made up of some C-programs and web apps), w/o any resort to root access, out of the sources including supporting OSS packages on a diversity of operating systems.
> If the preinstalled compilers don't fulfill the requirements of the code to be compiled (C99, C++11, etc.), I install a private GCC 4.8.5 including all required tools necessary to do that before building the rest of system, because upgrading the preinstalled compilers and tools is not an option.
> This works quite well except the tests for gfortran which come with libtool run into a dilemma that however environment variables I supply for "make check" some disjoint set of tests fail. A very simple solution is to add a runtime path for the private libdir in lib/libgfortran.spec after installation of GCC. Because since ever (20+ years) I use my own simple configuration tools, which implement how to build shared libraries and to link to on the supported platforms, I could even automate the manipulation of this file. I also know about "CC=$(which gcc) LD=$(which ld) GCC=yes with_gnu_ld=yes LDFLAGS= sh ./config.rpath $(sh ./config.guess)“ to make gcc tell me what I need to know to manipulate the spec file. But the best solution would be to modify and autoreconf GCC in a way that whatever the path of the private libdir is, this path would be hardcoded in the custom built GCC.
> I have seen some variable names with a prefix of hardcode_ in the configure scripts, but don’t know how make use of these to have at least generated a tailored fit gfortran.spec.
>
> I hope I have given given enough details to explain my problem.
>
> My dream would be a hint for simple modifications at the *.in/ac level.
> An idea to modify the configure script would also be very helpful.

Have a look at the --with-specs configure option. You can do things like:

--with-specs="%{!m32:-L$prefix/lib64}%{m32:-L$prefix/lib}"