On Tue, 11 Aug 2020 at 12:21, Jens With <jens.with@xxxxxxxxxxx> 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}"
