uClibc, libstdc++, and readdir()

Peter S. Mazinger ps.m at gmx.net
Wed May 31 08:43:12 UTC 2006


On Wed, 31 May 2006, Mike Frysinger wrote:

> On Wednesday 31 May 2006 02:03, Peter S. Mazinger wrote:
> > On Wed, 31 May 2006, Mike Frysinger wrote:
> > > On Tuesday 30 May 2006 16:20, Peter S. Mazinger wrote:
> > > > That happens for ex. if you have libc.so /lib and libc.a in /usr/lib,
> > > > libc.so is not found "early enough" unless you create a link
> > > > /usr/lib/libc.so
> > > >
> > > > If that is a feature or bug in compiler I have never asked ;)
> > >
> > > feature i would say
> > >
> > > if you have your own lib, say libfoo.a, and you do `gcc -L. -lfoo`, you
> > > would want the local libfoo.a to be found, not skipped, if there were a
> > > libfoo.so in the linker search path
> >
> > If I invert the conditions and I have a local libfoo.so (-L.) and a
> > /usr/lib/libfoo.a, then libfoo.a is found?
> 
> no
> 
> the "problem" is that the first lib found in the search path is used ... so if 
> you're making a dynamic object, ld will select either libfoo.a or 
> libfoo.so ... but if you're making a static object, ld will only select 
> libfoo.a
> -mike

curious, I have thought that /lib:/usr/lib is the default search order and 
then from /lib/libfoo.so and /usr/lib/libfoo.a the shared one should be 
found first, but that is not the case

Peter 

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




More information about the uClibc mailing list