From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Mark Hatle <mark.hatle@windriver.com>,
openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] uninative: Fix conflicts with normal sysroot
Date: Fri, 22 Jan 2016 23:18:14 +0000 [thread overview]
Message-ID: <1453504694.6378.28.camel@linuxfoundation.org> (raw)
In-Reply-To: <56A27C8C.8000403@windriver.com>
On Fri, 2016-01-22 at 13:01 -0600, Mark Hatle wrote:
> On 1/22/16 11:17 AM, Richard Purdie wrote:
> > Currently this code installs into the standard sysroot, however
> > this causes
> > some conflicts when linking since the linker can look specifically
> > for
> > versioned .so files (e.g. like libpthreads.so.0). This breaks
> > builds
> > of util-linux-native for example.
> >
> > The easiest solution is to install uninative into its own separate
> > sysroot.
> >
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >
> > diff --git a/meta/classes/uninative.bbclass
> > b/meta/classes/uninative.bbclass
> > index fe1e89b..8686159 100644
> > --- a/meta/classes/uninative.bbclass
> > +++ b/meta/classes/uninative.bbclass
> > @@ -1,6 +1,6 @@
> > NATIVELSBSTRING = "universal"
> >
> > -UNINATIVE_LOADER ?= "${@bb.utils.contains('BUILD_ARCH', 'x86_64',
> > '${STAGING_DIR_NATIVE}/lib/ld-linux-x86-64.so.2',
> > '${STAGING_DIR_NATIVE}/lib/ld-linux.so.2', d)}"
> > +UNINATIVE_LOADER ?= "${STAGING_DIR}-uninative/${BUILD_ARCH}-linux/
> > lib/${@bb.utils.contains('BUILD_ARCH', 'x86_64', 'ld-linux-x86
> > -64.so.2', 'ld-linux.so.2', d)}"
>
> Have you considered changing the name of the ld.so for the uninative
> so that
> there is no way it can conflict with the host system.
>
> This would require a minor patch to the uninative linker/compiler to
> use the new
> name -- and of course above to know it as well.
>
> This might be a useful safety to prevent the system from every
> falling back to
> the /lib/... version.
The problem wasn't/isn't ld.so. Its that ${STAGING_DIR_NATIVE}/lib/ is
in the linker paths for -native utils and it was picking up random
pieces of the libc from there like libpthread, even though there was
only versioned .so files there, no .so links. It was those that
conflicted with the host system.
The ld.so references are in the interpreter sections of the binaries so
very hard to get confused and I'm not aware of any issue there, nor can
I really envisage one.
So whilst I appreciate the idea, I'm not sure it solves any issue we
have...
Cheers,
Richard
prev parent reply other threads:[~2016-01-22 23:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-22 17:17 [PATCH] uninative: Fix conflicts with normal sysroot Richard Purdie
2016-01-22 19:01 ` Mark Hatle
2016-01-22 23:18 ` Richard Purdie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1453504694.6378.28.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox