[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: devel files and libraries in /lib

* Bernhard R. Link <brlink@debian.org> schrieb:

> They do not only include the library in question, but they include many
> other libraries. As paths supplied by the user are searched in before
> anything in the system path, this changes the order the system paths are
> searched in.
> This can both hide a user suplied search path (as it is searched now
> after /usr/lib, so replacing something there does no longer work).

Relying on the search *order* is a really bad idea IMHO. To make it
work, you'll also have to *ensure* the right order on runtime linking.

Why do you want to do that at all ?
Why not simply set up an proper sysroot which just contains exactly
the required libraries ? (and of course, take care that there're no
conflicting library names in the runtime system later).

> And it can change the order in the standard search path
> (so if your linker knows or is told that for the current format it
> needs to look first into some other directory to get the proper libc
> or things like that, the linker will see them too late).

Same as above: solve this issue by using a proper sysroot where
the libc (and other libs) you want to get used are installed, 
and nothing else.

> For example, on a amd64 lenny system run
> gcc -m32 -L/usr/lib hello.c
> and you get:
> /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
> /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc

Multiarch is another bad idea. Use _separate_ toolchains.

 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme

Reply to: