All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mike \(mwester\)" <mwester@dls.net>
To: <openembedded-devel@lists.openembedded.org>
Subject: Re: STAGING_LIBDIR_NATIVE needed in bitbake.conf
Date: Tue, 7 Aug 2007 04:14:04 -0500	[thread overview]
Message-ID: <0cf301c7d8d3$4d422cb0$6e01a8c0@twilight> (raw)
In-Reply-To: 1186476730.5653.6.camel@localhost.localdomain

----- Original Message ----- 
From: "Richard Purdie" <rpurdie@rpsys.net>
To: <openembedded-devel@openembedded.org>
Sent: Tuesday, August 07, 2007 3:52 AM
Subject: Re: [oe] STAGING_LIBDIR_NATIVE needed in bitbake.conf


> On Tue, 2007-08-07 at 08:22 +0200, Marcin Juszkiewicz wrote:

> > It should be done in classes/native.bbclass not in ncurses-native. The
> > problem is wider as there are few distributions which have host versions
> > of stuff other then OE use as native. As a result building of native
> > stuff which depend on native libraries can fail - when you will set
> > LD_LIBRARY_PATH in native.bbclass then it should work.
>
> Just to be clear, this is a problem with ncurses-native? If so,
> STAGING_LIBDIR_NATIVE == STAGING_LIBDIR due to native.bbclass anyway so
> we don't need the _NATIVE version?

No, this is a problem with ncurses, not ncurses-native.  The issue arises
because ncurses-native builds a utility (dynamically linked), and stages
same along with it's library.  This staged utility is executed during the
do_install task of ncurses itself, and that's the point at which it fails if
LD_LIBRARY_PATH is not set.  It's gone unnoticed, I suspect, because up to
recently the utility has successfully dynamically linked to the host's copy
of that library instead of the one in staging.

So LD_LIBRARY_PATH needs only to be set for ncurses, not for ncurses-native
(but since ncurses-native includes ncurses, it ends up set (harmlessly) for
ncurses-native as well).

> We'd only need a _NATIVE version if our cross compiled packages needed
> to reference something there explicitly (like they do some of the
> binaries). DoO we need to do that (and if so, which package and why)?

I think they do -- how else do the dynamically-linked executables in staging
find their shared libraries?

Of course, using staticly-linked executables in staging will solve *this*
problem -- but it creates major headaches for utilities such as fakeroot,
which require that everything be dynamically-linked.

> Setting LD_LIBRARY_PATH for native.bbclass sounds like a worthwhile
> experiment...
>
> Cheers,
>
> Richard


Thanks,
Mike (mwester)




  reply	other threads:[~2007-08-07  9:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-06 17:58 STAGING_LIBDIR_NATIVE needed in bitbake.conf Mike (mwester)
2007-08-06 18:42 ` Khem Raj
2007-08-07  6:22 ` Marcin Juszkiewicz
2007-08-07  8:52   ` Richard Purdie
2007-08-07  9:14     ` Mike (mwester) [this message]
2007-08-07 12:27       ` Richard Purdie
2007-08-07 20:28         ` Mike (mwester)
2007-08-07 22:02         ` Dr. Michael Lauer

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='0cf301c7d8d3$4d422cb0$6e01a8c0@twilight' \
    --to=mwester@dls.net \
    --cc=openembedded-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.