STAGING_LIBDIR_NATIVE needed in bitbake.conf

STAGING_LIBDIR_NATIVE needed in bitbake.conf

[Mike (mwester)]

In order to fix an ncurses build bug
(http://bugs.openembedded.org/show_bug.cgi?id=2554), we need to set
LD_LIBRARY_PATH in the ncurses bb file.

I've tested, and the following resolves the problem with ncurses not
installing:

    export LD_LIBRARY_PATH = "${STAGING_BINDIR_NATIVE}/../lib"

That's not too elegant, so I'd like to create "STAGING_LIBDIR_NATIVE" in the
bitbake.conf file instead, which will clean up the recipe and make more
obvious what it is that we're doing.


Anyone have any heartburn with this approach to resolving this problem?

Thanks,
Mike (mwester)

Re: STAGING_LIBDIR_NATIVE needed in bitbake.conf

[Khem Raj]

On 8/6/07, Mike (mwester) <mwester@dls.net> wrote:
> In order to fix an ncurses build bug
> (http://bugs.openembedded.org/show_bug.cgi?id=2554), we need to set
> LD_LIBRARY_PATH in the ncurses bb file.
>
> I've tested, and the following resolves the problem with ncurses not
> installing:
>
>     export LD_LIBRARY_PATH = "${STAGING_BINDIR_NATIVE}/../lib"
>
> That's not too elegant, so I'd like to create "STAGING_LIBDIR_NATIVE" in the
> bitbake.conf file instead, which will clean up the recipe and make more
> obvious what it is that we're doing.
>
>
> Anyone have any heartburn with this approach to resolving this problem?

I have encountered exactly same issue and I did the LD_LIBRARY_PATH
trick in env. Your fix looks reasonable.

>
> Thanks,
> Mike (mwester)
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: STAGING_LIBDIR_NATIVE needed in bitbake.conf

[Marcin Juszkiewicz]

Dnia poniedziałek, 6 sierpnia 2007, Mike (mwester) napisał:
> In order to fix an ncurses build bug
> (http://bugs.openembedded.org/show_bug.cgi?id=2554), we need to set
> LD_LIBRARY_PATH in the ncurses bb file.
>
> I've tested, and the following resolves the problem with ncurses not
> installing:
>
>     export LD_LIBRARY_PATH = "${STAGING_BINDIR_NATIVE}/../lib"
>
> That's not too elegant, so I'd like to create "STAGING_LIBDIR_NATIVE"
> in the bitbake.conf file instead, which will clean up the recipe and
> make more obvious what it is that we're doing.

STAGING_LIBDIR_NATIVE sounds ok for me

> Anyone have any heartburn with this approach to resolving this problem?

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.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

              whats mean ubuntu?
              it's african word for "can't configure debian"

Re: STAGING_LIBDIR_NATIVE needed in bitbake.conf

[Richard Purdie]

On Tue, 2007-08-07 at 08:22 +0200, Marcin Juszkiewicz wrote:
> STAGING_LIBDIR_NATIVE sounds ok for me

I'd certainly prefer STAGING_LIBDIR_NATIVE rather than paths with the
"/../" in them :). I'm wondering if we need it though?

> > Anyone have any heartburn with this approach to resolving this problem?
> 
> 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?

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)?

Setting LD_LIBRARY_PATH for native.bbclass sounds like a worthwhile
experiment...

Cheers,

Richard

Re: STAGING_LIBDIR_NATIVE needed in bitbake.conf

[Mike (mwester)]

----- 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)

Re: STAGING_LIBDIR_NATIVE needed in bitbake.conf

[Richard Purdie]

On Tue, 2007-08-07 at 04:14 -0500, Mike (mwester) wrote:
> > On Tue, 2007-08-07 at 08:22 +0200, Marcin Juszkiewicz wrote:
> > 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. 

Ok, fair enough, I wondered but wasn't sure. its clear now :)

> > 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?

I'm convinced, it make sense. Feel free to add STAGING_LIBDIR_NATIVE and
then use it in the ncurses bb file (maybe mention in a comment there is
a util used in do_install which needs to find libraries from
ncurses-native).

In fact this raises the question of whether that should be set globally?

Cheers,

Richard

Re: STAGING_LIBDIR_NATIVE needed in bitbake.conf

[Mike (mwester)]

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


> I'm convinced, it make sense. Feel free to add STAGING_LIBDIR_NATIVE and
> then use it in the ncurses bb file (maybe mention in a comment there is
> a util used in do_install which needs to find libraries from
> ncurses-native).
>
> In fact this raises the question of whether that should be set globally?

It seems logical to me that it should be global -- if something lives in
STAGING_BINDIR_NATIVE, it stands to reason that it should prefer to link to
shared libraries that have been staged along with it.  Making this global
(by manually setting LD_LIBRARY_PATH before a build) has been tested by a
number of folks on different distros, and works fine.

Just to satisfy my own curiosity, I did a bit of checking with ldd on the
contents of STAGING_BINDIR_NATIVE, and it reveals that for SlugOS, only the
ncurses build is affected at present.

So we could go either way.

I edited bitbake.conf and added:

    export LD_LIBRARY_PATH_prepend = "${STAGING_LIBDIR_NATIVE}:"

but that doesn't seem to have any effect.  :-(  I presume that the logic is
missing to handle this variable.  Using:

    export LD_LIBRARY_PATH = "${STAGING_LIBDIR_NATIVE}"

works fine, though.  However, that line ignores the existing
LD_LIBRARY_PATH, and I've not found the magic incantation to make bitbake do
the shell equivalent of
LD_LIBRARY_PATH="/new/prepended/path:$LD_LIBRARY_PATH".  Everything obvious
I've tried with my limited bitbake skills has resulted in something
complaining about the expansion in some way.

  I would prefer to leave ncurses.bb alone, and fix it globally -- how
should we do that, then: pursue the "_prepend" approach, or just explicitly
set it in bitbake.conf?

  Or is there a nice class somewhere that we can add some logic to do this
(I didn't find it yet!)?

Thanks,
Mike (mwester)

Re: STAGING_LIBDIR_NATIVE needed in bitbake.conf

[Dr. Michael Lauer]

> In fact this raises the question of whether that should be set globally?

+1 for setting it globally. We may encounter more packages like that
and then it makes sense to have the "guideline" right from the start.

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de