M.K. aka Grisu
M.K. aka Grisu

Reputation: 2398

Build gcc from scratch without lib64 directory

I am trying to setup a gcc compiler from scratch on a x86_64 machine. I configured it using

./configure --enable-shared --enable-languages=c,c++,fortran --disable-multilib --libdir=/cluster/apps/lib --with-gmp=/cluster/apps/ --with-mpfr=/cluster/apps --with-mpc=/cluster/apps --prefix=/cluster/apps

After building and running make install the libraries are installed in

/cluster/apps/lib64

instead of the desired

/cluster/apps/lib

How can I advise the configure script to use /cluster/apps/lib as library destination?

Upvotes: 3

Views: 1788

Answers (1)

Iguananaut
Iguananaut

Reputation: 23366

This turns out to be slightly non-trivial depending on how you want to go about it. When building GCC you can configure it to support a wide number of target platforms and architectures, and each of those targets may require their own versions of various support libraries. These libraries (e.g. libatomic.a) have the same name on every target, but of course have to live in separate directories depending on the target. The MultiArch convention from Debian is a more formalized generalization of this which IIUC the multilib support in GCC predates.

Where GCC installs libraries is thus highly dependent on what targets it's being built to support; this in turn has some defaults depending on the host system you're building on (if you didn't otherwise specify some targets at configure time). For x86_64 Linux targets there are by default two multilib options, one for building with -m32 (compiling 32-bit binaries) and one for -m64, and for the -m64 case it requires libraries found in ${libdir}/../lib64, whereas for -m32 it requires libraries in (generally) ${libdir}/../lib. This information is found in the gcc/config/i386/t-linux64 makefile snippet.

The meanings of these MULTILIB_ variables are explained (somewhat) in the genmultilib script to which they are passed by the Makefile.

"But wait a sec", you might interrupt, "I passed --disable-multilib to ./configure so it should just forget all this multilib stuff and install stuff in ${prefix}/lib like I asked. It's not that simple though. As you can see in the Makefile template linked in the previous paragraph, --disable-multilib is quietly ignored if your target happens to specify a non-empty $(MULTILIB_OSDIRNAMES). After all, the target in this case supports two target architecture options (-m64 and -m32) that have to support multiple libraries, so it still generates settings for multilib support.

So if you want a different directory layout, what do? Ideally, since we just want to override the defaults for the $(MULTILIB_OSDIRNAMES) variable in this case, it would be nice if we could provide an override either at configure-time, or when running make (e.g. make MULTILIB_OSDIRNAMES="m32=../lib32 m64=../lib"). I believe this should work as a convenience, but unfortunately it does not: The top-level Makefile supports GCC's slightly complex multi-stage build process and which involves several recursive make invocations, and I can't get it to reliably pass variable overrides down to the relevant sub-makes without some patching. I think that's unfortunate.

I found that currently the easiest approach is to do what Debian does and just patch gcc/config/i386/t-linux64 (among other, similar files for other architectures) to reflect the directory layout that they prefer.

Another possibility is to patch the gcc/config.gcc script. This is the script that looks at what target you're building GCC for, and determines a number of makefile variables and snippets depending on the target. See for example this section for some of the settings it applies for x86_64 Linux targets. The tmake_file variable is actually a list of usually multiple files from under gcc/config which begin with t- meaning that they contain Makefile snippets to be included by the main gcc Makefile. This is where the gcc/config/i386/t-linux64 file, among others, gets selected. You could theoretically add your own custom target to this file (some x86_64-mycustom-linux) and have it load its own additional Makefile snippets to override the default multilib options for Linux. However, I think at that point you might as well just patch t-linux64 and leave it at that.

Upvotes: 7

Related Questions