pmdata's blog

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.