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/[email protected]> 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. _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
