[OE-core] [CONSOLIDATED PULL 04/28] ncurses: move libraries to base_libdir

Phil Blundell philb at gnu.org
Fri Jan 6 12:07:50 UTC 2012


On Fri, 2012-01-06 at 12:06 +0000, Richard Purdie wrote:
> On Fri, 2012-01-06 at 11:33 +0000, Phil Blundell wrote:
> > On Fri, 2012-01-06 at 11:07 +0000, Richard Purdie wrote:
> > > On Fri, 2012-01-06 at 11:29 +0100, Enrico Scholz wrote:
> > > > Saul Wold <sgw-VuQAYsv1563Yd54FQh9/CA at public.gmane.org> writes:
> > > > 
> > > > > -		f=${D}${libdir}/$i.so
> > > > > +                f=${D}${base_libdir}/$i.so
> > > > 
> > > > this breaks builds because 'ld' does not search ${base_libdir}:
> > > > 
> > > > | gcc -shared ... -ltermcap
> > > > | /usr/bin/ld: cannot find -ltermcap
> > > > | ERROR: Task 216 (virtual:native:.../readline/readline_6.2.bb, do_install) failed with exit code '1'
> > > > | ERROR: 'virtual:native:.../readline/readline_6.2.bb' failed
> > > 
> > > Note this is a -native problem, not a target library one.
> > 
> > It looks to me like the same would probably occur on the target.
> > The .so devel symlinks should be in ${libdir} not ${base_libdir} since
> > the latter is indeed not in the linker's standard search path.
> 
> Are you 100% sure about that? I was pretty sure that /lib is in the
> default linker's search path as well as /usr/lib?

Not 100%, admittedly, but I can't think of any other instances of these
things being installed in /lib.  I know that glibc, for example, puts
libc.so in /usr/lib even though the corresponding libraries are in /lib.
Admittedly that one isn't a symlink though.

> I can't find a commandline option to make ld dump its search path but
> looking at the linker scripts for various architectures, it does appear
> that /lib is listed as a search directory...

I think "ld -verbose" should do that.  Look for SEARCH_DIR or some such.

p.






More information about the Openembedded-core mailing list