Reputation: 2398
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
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