On 08/24/2012 09:19 AM, Richard Purdie wrote:
I'd love to have a better fix for this. I suspect its taking the path
from some "gcc -print-xxxx" call which returns/usr/lib/../lib on x86_64
so we could try and normalise it at source...
Yeah, but that sounds like whack-a-mole to me. It's just too tempting
for upstream software to glue up a path name with .., it's very sane
for a human being.
One of the (comparatively few) spots where I actually isolated the
source of one of these is in gettext, where the configure script needs
a --with-ncurses-prefix to be "/usr". So the bitbake recipe sets it
to ${STAGING_LIBDIR}/.., which seems clearly correct to me. And then
somewhere in the configure script that turns into a libtool library
path of <ncurses_prefix>/lib (again completely correct), thus
"/usr/lib/../lib". And even then it's correct and if used for a -L
argument would never cause a problem.
It's libtool which has special requirements here, becuase it's trying
to set rpaths based on those funny strings and has to have them
normalized. So I'd argue that it's in libtool where this magic has to
happen.
Before I realized you already fixed the gcc-runtime issue, I was
looking at finding a place farther up the stack where this could be
done. That is, sanitize all inbound paths at the spot where they're
parsed at the command line. The current cases we know we need to hit
are -lib and -rpath, though I'm no libtool expert and am surely
missing some...
Andy
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
