Problem with multilib feature of gcc
By Patrice Mandin on Thursday, December 11 2008, 20:37 - Docs - Permalink
I am using gcc 3.3 and binutils 2.13.2.1 (cross-compiler versions).
I create a dummy library, with a single function, and tried linking a
dummy program with different parameters:
gcc myprog.c -t -lmylib : default linking directory .
gcc myprog.c -t -m68020 -lmylib : default linking directory ./m68020
gcc myprog.c -t -m68020-60 -lmylib : default linking
directory ./m68020-60
So everything is ok, now if I move mylib to a different directory, and
use -L to link against it:
gcc myprog.c -t -Lmylib -lmylib : default linking directory . and mylib
directory added for linking my library.
gcc myprog.c -t -m68020 -Lmylib -lmylib : default linking
directory ./m68020 and mylib added to link my library.
gcc myprog.c -t -m68020-60 -Lmylib -lmylib : default linking
directory ./m68020-60 and mylib directory added to link my library.
So everything is also ok in this case. The problem arises when the
directory given as -L parameter is one of the default path used to
search for libraries (/usr/lib, usr/local/lib):
If I install mylib in /usr/lib:
gcc monprog.c -t -L/usr/lib -lmylib : only /usr/lib used
gcc monprog.c -t -m68020 -L/usr/lib -lmylib : only /usr/lib used
gcc monprog.c -t -m68020-60 -L/usr/lib -lmylib : only /usr/lib used
So it appears -L disable multilib path generation, for the given
directory. I suppose gcc also removes paths that appear several times.
The problem in this case, is that paths for multilib are not used at
all.
For example, the file libgcc.a which resides in a specific directory of
gcc installation is not impacted by this (the libgcc.a is still the one
from ., m68020 or m68020-60), but I think it could also happens if
you add -L/path/to/libgcca
I did not try for gcc 4.3 and binutils 2.18.
This is a huge problem, because when you use extra libraries for your
application, and linking parameters are given through the result of a
mylib-config script output, or even pkg-config.
On my cross-compiler setup, all libraries are stored in the same
directory, the ones that come from sparemint (with . m68020 and
m68020-60) and the ones I compile, for example SDL, that have a
pkg-config, and also a sdl-config that gives the path to libSDL.a using
the -L parameter.
In my case, it means all applications I compiled for 68020 or 68020-60 and that use SDL, are linked against the 68000 version of the libraries. I suppose it is the same for people that use config script for libraries.