From mint-bounce@lists.fishpool.fi Thu Dec 11 23:32:16 2008 Message-ID: <4941E7F7.4000102@atari-source.org> Date: Thu, 11 Dec 2008 23:26:31 -0500 From: Mark Duckworth User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Patrice Mandin CC: Mint list Subject: Re: [MiNT] Linking with multilib feature References: <20081211202925.d963d4e4.mandin.patrice@orange.fr> In-Reply-To: <20081211202925.d963d4e4.mandin.patrice@orange.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: mduckworth@atari-source.org Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Patrice Mandin wrote: > Hello, > > Here is more information about the problem that originally was the > cause of mixing FPU and non FPU code. > > 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. > > Yeah, I think most probably multilib was never designed to be used for static compiling... :-/ I've often wondered if it would behave this way.. it's nice to know for sure. Thanks, Mark