Re: -L not working properly?
"Daniel Jacobowitz" <[EMAIL PROTECTED]> writes: > > > So am I delusional, and -L never worked in 'last seen, first used' > > > order? I thought the whole point was to be able to do things like: > > > > > > -L/priv/lib1 -llib1 -L/priv/lib2 -lib2 -L/priv/lib2 -lib3 ... > > > > > > and ensure you were getting the correct libraries? > > > > Please RTFM. :) One of the next sentences I omitted is: 'All -L > > options apply to all -l options, regardless of the order in which > > the options appear.' I understand that they all apply, that isn't the issue. The issue is what is the search order of the -L directories: 1) first in first out (queue) 2) last in first out (stack) My understanding (which seems to be flawed) was that it was 2) and not 1). The way makefiles are constructed, you have little control about what comes first on the link line, but you can easily add: -L/my/private/lib -lmylib to ensure that the private lib gets searched first. What is happening to me is that the search order seems to be happening the opposite of the way I believed it to have always been working. > > > I'm downloading code off standard repositories that is suddenly not > > > linking because of this - did it change recently?? > > > > No idea, I wouldn't expect it it did though. > > No, this has not changed in some time. So has the search order been 'first in first out' all along? I can't find this documented anywhere, it seems like an important thing to know. Thanks, jas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -L not working properly?
On Sun, Jun 16, 2002 at 11:23:37PM +0200, Michel Dänzer wrote: > On Sun, 2002-06-16 at 02:00, Jason E. Stewart wrote: > > "Michel Dänzer" <[EMAIL PROTECTED]> writes: > > > > > > I thought the order of -L flags was 'last seen, first used'? What > > > > would make the linker not use that order? > > > > > >The directories are searched in the order in which they > > >are specified on the command line. > > > > > > So it seems -L/usr/lib is not only redundant but harmful here. > > > > Hey Michel, > > > > So am I delusional, and -L never worked in 'last seen, first used' > > order? I thought the whole point was to be able to do things like: > > > > -L/priv/lib1 -llib1 -L/priv/lib2 -lib2 -L/priv/lib2 -lib3 ... > > > > and ensure you were getting the correct libraries? > > Please RTFM. :) One of the next sentences I omitted is: 'All -L options apply > to all -l options, regardless of the order in which the options appear.' > > > I'm downloading code off standard repositories that is suddenly not > > linking because of this - did it change recently?? > > No idea, I wouldn't expect it it did though. No, this has not changed in some time. -- Daniel Jacobowitz Debian GNU/Linux Developer MontaVista Software Carnegie Mellon University -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -L not working properly?
On Sun, 2002-06-16 at 02:00, Jason E. Stewart wrote: > "Michel Dänzer" <[EMAIL PROTECTED]> writes: > > > > I thought the order of -L flags was 'last seen, first used'? What > > > would make the linker not use that order? > > > >The directories are searched in the order in which they > >are specified on the command line. > > > > So it seems -L/usr/lib is not only redundant but harmful here. > > Hey Michel, > > So am I delusional, and -L never worked in 'last seen, first used' > order? I thought the whole point was to be able to do things like: > > -L/priv/lib1 -llib1 -L/priv/lib2 -lib2 -L/priv/lib2 -lib3 ... > > and ensure you were getting the correct libraries? Please RTFM. :) One of the next sentences I omitted is: 'All -L options apply to all -l options, regardless of the order in which the options appear.' > I'm downloading code off standard repositories that is suddenly not > linking because of this - did it change recently?? No idea, I wouldn't expect it it did though. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[OT] New upstream dev version of mol with improved linux-on-linux support...
The developers have notified the general list that they have some major changes in their bitkeeper sources that they would like tested. I thought that people on debian-powerpc might be interested even if it is slightly off-topic. Full message with bk/rsync details..: http://lists.maconlinux.org/pipermail/mol-general/2002-June/000338.html From: Samuel Rydh <[EMAIL PROTECTED]> Subject:Testing needed, Linux support Date: 16 Jun 2002 16:07:05 +0200 > > I have recently pushed a major change to the MMU subsystem of MOL. > I would appreciate it if as many as possible could test the latest > BK/rsync version of MOL. > > The change was primarily targeted to speed up the performance of MOL > when unix-like operating systems is run within MOL (Linux, OS X). > However, there is some performance gain with MacOS classic too > (I quick MacBench run indicated about 5% gain). signature.asc Description: This is a digitally signed message part
