[Buildroot] Host libraries - status

[Buildroot] Host libraries - status

[Yann E. MORIN]

Thomas, All,

To sum up our discussion on IRC yesterday.

- we are building libraries to run on the host (the machine we build on)

- those libraries get installed in a non-standard place, so the dynaminc
  linker (ld.so) can not find them

- we do not want our executables to runtime-link with standard libraries
  when we have our own versions

The issue is not at link-time, but at runtime.

Some plans were devised to overcome this issue:

- use LD_LIBRARY_PATH to point the linker to the proper place where to find
  our own libraries. Using LD_LIBRARY_PATH has the advantage that the libs
  are searched for in there before the linker attempts the standard places.
  But LD_LIBRARY_PATH breaks mkfontscale (used to build fonts for X)

- use the linker arg -rpath. rpath adds the search dir directly into the
  executable in an attribute of the .dynamic section. Passing -rpath in
  the CFLAGS breaks binutils. Passing it in the LDFLAGS breaks fakeroot.

We still have some options:

- statically build all host libraries. That would surely fix this issue,
  but could be considered ugly, as *all* dependable libraries would have
  to be specified in the LDFLAGS (Thomas on IRC). Plus the fact that we
  should take care to avoid linking with shared versions of those libs
  if they are present in the standard places (the linker prefers .so
  to .a libs).

- fix fakeroot, so it works with rpath. Might require a huge amount of
  work.

- a third solution would be to craft a simple wrapper for all host
  executables we install. That wrapper would be responsible for exporting
  LD_LIBRARY_PATH. That way, LD_LIBRARY_PATH is set only when running
  those executables, for those executables (and their children), and
  whatever calls them does not have to care about it, nor be mislead.
  For the records, I'va had to do that in crosstool-NG, and it has
  worked pretty nicely. I have a shell script version [1] and also a
  C program [2] that implement such a wrapper.

- anything else I missed ?

Regards,
Yann E. MORIN.

[1] http://ymorin.is-a-geek.org/hg/crosstool-ng/file/eebcaff6626f/scripts/wrapper.in
[2] http://ymorin.is-a-geek.org/hg/crosstool-ng/file/eebcaff6626f/scripts/wrapper.c

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Host libraries - status

[Thomas Petazzoni]

Hello Yann,

Thanks for jumping into this longstanding issue!

On Wed, 23 Jun 2010 00:45:22 +0200
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> wrote:

> To sum up our discussion on IRC yesterday.
> 
> - we are building libraries to run on the host (the machine we build
> on)
> 
> - those libraries get installed in a non-standard place, so the
> dynaminc linker (ld.so) can not find them

Correct.

> - we do not want our executables to runtime-link with standard
> libraries when we have our own versions

Actually, this is what happens today and it doesn't seem to be causing
particular issues. But it's true that if we bother building libraries
for the host in order to be as independent as possible from the build
machine, it'd be better to actually use those libraries. Not counting
issues like the build machine having a different version of the library
than the one we have in Buildroot.

> The issue is not at link-time, but at runtime.

Yes.

> Some plans were devised to overcome this issue:
> 
> - use LD_LIBRARY_PATH to point the linker to the proper place where
> to find our own libraries. Using LD_LIBRARY_PATH has the advantage
> that the libs are searched for in there before the linker attempts
> the standard places. But LD_LIBRARY_PATH breaks mkfontscale (used to
> build fonts for X)

Actually, it doesn't break mkfontscale specifically. mkfontscale is the
test-case I have for the whole problem.

This LD_LIBRARY_PATH solution is the one I implemented in commit
c1b6242fdcf2cff7ebf09fec4cc1be58963e8427.

However, it was causing build issues with 'icu', described in commit
0d1830b07db4ebfd14e77a258de6fb391e57e960. The issue seems to be that
the build was using host libraries instead of target libraries. In this
commit, we removed the passing of LD_LIBRARY_PATH when building target
packages, to avoid the 'icu' build breakage.

> - use the linker arg -rpath. rpath adds the search dir directly into
> the executable in an attribute of the .dynamic section. Passing
> -rpath in the CFLAGS breaks binutils. Passing it in the LDFLAGS
> breaks fakeroot.

The CFLAGS variant was implemented in
6b939d40f6a29a43277566adc9d4312d49cb3abf. This one apparently causes a
build breakage in binutils (cross variant), as reported in
http://lists.busybox.net/pipermail/buildroot/2010-May/034609.html and
https://bugs.busybox.net/show_bug.cgi?id=1789 (the initial bug report).
I have never been able to reproduce this issue, even though I had
tested the exact same BR configuration as the bug reporters.

Then, we tried the LDFLAGS variant (which was never committed), who
worked better for the bug reporters, but was causing a build breakage in
fakeroot. See https://bugs.busybox.net/show_bug.cgi?id=1789#c3. I don't
remember if I tried to reproduce it or not.

The current status is that 6b939d40f6a29a43277566adc9d4312d49cb3abf got
reverted just before the release in order to avoid the reported binutils
build breakage. So the status as of today is the same as the one we had
at the beginning of the whole story :-)

> We still have some options:
> 
> - statically build all host libraries. That would surely fix this
> issue, but could be considered ugly, as *all* dependable libraries
> would have to be specified in the LDFLAGS (Thomas on IRC). Plus the
> fact that we should take care to avoid linking with shared versions
> of those libs if they are present in the standard places (the linker
> prefers .so to .a libs).

I find it rather ugly.

> - fix fakeroot, so it works with rpath. Might require a huge amount of
>   work.

I'm not sure what the exact problem with fakeroot is. Maybe we should
dig into this.

> - a third solution would be to craft a simple wrapper for all host
>   executables we install. That wrapper would be responsible for
> exporting LD_LIBRARY_PATH. That way, LD_LIBRARY_PATH is set only when
> running those executables, for those executables (and their
> children), and whatever calls them does not have to care about it,
> nor be mislead. For the records, I'va had to do that in crosstool-NG,
> and it has worked pretty nicely. I have a shell script version [1]
> and also a C program [2] that implement such a wrapper.

The problem is that in CT-NG, you *know* the list of binaries for which
such a wrapper needs to be created. In BR, we have no idea which
binaries are installed by the various packages. So basically, to
implement this, we would have, after the installation of every package,
to look at all binaries in $(HOST_DIR), and if they are an ELF binary,
replace them with a shell wrapper.

> - anything else I missed ?

 * I have another option running here. It involves using a program
   called "patchelf", that allows to insert a rpath value into an
   existing binary. After the installation of all packages, I run
   "patchelf" on all binaries in $(HOST_DIR) to add an rpath to them.
   So it has the same level of uglyness as creating wrappers in that
   all binaries have to be looked at after the installation of every
   package, but it has the advantage of not requiring the creation of
   shell wrappers.

 * Investigate whether passing LD_RUN_PATH to the linker (which has a
   similar behaviour to -Wl,-rpath) would work better.

 * Actually fix the issue with either LD_LIBRARY_PATH or -Wl,-rpath,
   since those two are the correct way to do this IMO.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Host libraries - status

[Thomas Petazzoni]

Hello,

On Wed, 23 Jun 2010 09:00:15 +0200
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> > - fix fakeroot, so it works with rpath. Might require a huge amount
> > of work.
> 
> I'm not sure what the exact problem with fakeroot is. Maybe we should
> dig into this.

Ok, I took the time to investigate this. I tried:

HOST_LDFLAGS += -Wl,-rpath -Wl,$(HOST_DIR)/usr/lib

and I could reproduce the fakeroot problem: "preload library not
found". This happens because libfakeroot.so doesn't get compiled. This
in turn happens because ./configure detects that LD doesn't support
shared libraries, which in turn happens because ./configure detects
that LD isn't GNU LD, which happens because for ld, "-Wl,-rpath
-Wl,$(HOST_DIR)/usr/lib" are incorrect options. And it's true, since
the ld option is just "-rpath", the -Wl thing being here to tell gcc to
pass these options down to ld.

So, I decided to try :

HOST_LDFLAGS += -rpath $(HOST_DIR)/usr/lib

unfortunately, it breaks host-genext2fs, because this stupid guy passes
those LDFLAGS directly to gcc :

configure:2562: checking for C compiler default output file name
configure:2589: /usr/bin/gcc -I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/include -I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/include -I/home/test/outputs/arm-2009q
3-2010-06-23-08-58-40/output/host/include -I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/include  -L/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/lib -L/home/test/outputs
/arm-2009q3-2010-06-23-08-58-40/output/host/usr/lib -rpath /home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/lib conftest.c  >&5
gcc: /home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/lib: No such file or directory
gcc: unrecognized option '-rpath'

I have therefore looked at the ./configure options and environment we
are passing to host-genext2fs ./configure script, and we *never* pass
the -rpath option in CFLAGS. Here is the full command line that is used
to run host-genext2fs ./configure, formatted for readability:

(
cd /home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/build/host-genext2fs-1.4/ && rm -rf config.cache;
PATH=/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/bin:/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
AR="/usr/bin/ar"
AS="/usr/bin/as"
LD="/usr/bin/ld -L/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/lib -L/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/lib -rpath /home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/lib"
NM="/usr/bin/nm"
CC="/usr/bin/gcc -I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/include -I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/include"
GCC="/usr/bin/gcc -I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/include -I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/include"
CXX="/usr/bin/g++ -I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/include -I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/include"
CPP="/usr/bin/cpp -I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/include -I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/include"
AR_FOR_BUILD="/usr/bin/ar"
AS_FOR_BUILD="/usr/bin/as"
CC_FOR_BUILD="/usr/bin/gcc"
GCC_FOR_BUILD="/usr/bin/gcc"
CXX_FOR_BUILD="/usr/bin/g++"
LD_FOR_BUILD="/usr/bin/ld"
FC_FOR_BUILD="/usr/bin/ld"
CFLAGS_FOR_BUILD="-I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/include -I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/include"
CXXFLAGS_FOR_BUILD="-I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/include -I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/include"
LDFLAGS_FOR_BUILD="-L/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/lib -L/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/lib -rpath /home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/lib"
FCFLAGS_FOR_BUILD=""
AR_FOR_TARGET="/home/test/arm-2009q3/bin/arm-none-linux-gnueabi-ar"
AS_FOR_TARGET="/home/test/arm-2009q3/bin/arm-none-linux-gnueabi-as"
CC_FOR_TARGET="/home/test/arm-2009q3/bin/arm-none-linux-gnueabi-gcc"
LD_FOR_TARGET="/home/test/arm-2009q3/bin/arm-none-linux-gnueabi-ld"
NM_FOR_TARGET="/home/test/arm-2009q3/bin/arm-none-linux-gnueabi-nm"
RANLIB_FOR_TARGET="/home/test/arm-2009q3/bin/arm-none-linux-gnueabi-ranlib"
STRIP_FOR_TARGET="/home/test/arm-2009q3/bin/arm-none-linux-gnueabi-strip"
OBJCOPY_FOR_TARGET="/home/test/arm-2009q3/bin/arm-none-linux-gnueabi-objcopy"
OBJDUMP_FOR_TARGET="/home/test/arm-2009q3/bin/arm-none-linux-gnueabi-objdump"
DEFAULT_ASSEMBLER="/home/test/arm-2009q3/bin/arm-none-linux-gnueabi-as"
DEFAULT_LINKER="/home/test/arm-2009q3/bin/arm-none-linux-gnueabi-ld"
ORIGINAL_AS_FOR_TARGET="/home/test/arm-2009q3/bin/arm-none-linux-gnueabi-as"
ORIGINAL_LD_FOR_TARGET="/home/test/arm-2009q3/bin/arm-none-linux-gnueabi-ld"
ORIGINAL_NM_FOR_TARGET="/home/test/arm-2009q3/bin/arm-none-linux-gnueabi-nm"
ORIGINAL_OBJDUMP_FOR_TARGET="/home/test/arm-2009q3/bin/arm-none-linux-gnueabi-objdump"
PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1
PKG_CONFIG_ALLOW_SYSTEM_LIBS=1
PKG_CONFIG="/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/bin/pkg-config"
PKG_CONFIG_LIBDIR="/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/lib/pkgconfig"
PERLLIB="/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/lib/perl"
LD_LIBRARY_PATH="/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/lib:"
CFLAGS="-I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/include -I/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/include"
LDFLAGS="-L/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/lib -L/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/lib -rpath /home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr/lib"
./configure
--verbose
--prefix="/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/usr"
--sysconfdir="/home/test/outputs/arm-2009q3-2010-06-23-08-58-40/output/host/etc"
)

Do you see anything wrong here ?

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Host libraries - status

[Thomas Petazzoni]

On Wed, 23 Jun 2010 11:20:22 +0200
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> Ok, I took the time to investigate this. I tried:
> 
> HOST_LDFLAGS += -Wl,-rpath -Wl,$(HOST_DIR)/usr/lib
> 
> and I could reproduce the fakeroot problem: "preload library not
> found". This happens because libfakeroot.so doesn't get compiled. This
> in turn happens because ./configure detects that LD doesn't support
> shared libraries, which in turn happens because ./configure detects
> that LD isn't GNU LD, which happens because for ld, "-Wl,-rpath
> -Wl,$(HOST_DIR)/usr/lib" are incorrect options. And it's true, since
> the ld option is just "-rpath", the -Wl thing being here to tell gcc
> to pass these options down to ld.

After seeing that PTXdist does exactly this (see
http://git.pengutronix.de/?p=ptxdist.git;a=blob;f=rules/pre/Rules.make;h=1fd3707311a19bc06d9b0d0668e9fb4ae2f6176d;hb=HEAD#l284),
I decided to go deeper into this.

And in fact, the problem comes from :

	LD="$(HOSTLD) $(HOST_LDFLAGS)" \

which I turned into:

	LD="$(HOSTLD)" \

in HOST_CONFIGURE_OPTS.

With this + the HOST_LDFLAGS as shown above, my mkfontscale test case
is OK, and fakeroot continues to work properly. I managed to build a
X.org stack + ext2 filesystem for ARM correctly.

Generally speaking, I think we shouldn't do:

                CC="$(HOSTCC) $(HOST_CFLAGS)" \
                GCC="$(HOSTCC) $(HOST_CFLAGS)" \
                CXX="$(HOSTCXX) $(HOST_CXXFLAGS)" \
                CPP="$(HOSTCPP) $(HOST_CFLAGS)" \

But only set CC="$(HOSTCC)", and pass CFLAGS in a separate variable.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Host libraries - status

[Yann E. MORIN]

Thomas, All,

On Wednesday 23 June 2010 112022 Thomas Petazzoni wrote:
> So, I decided to try :
> HOST_LDFLAGS += -rpath $(HOST_DIR)/usr/lib
> unfortunately, it breaks host-genext2fs, because this stupid guy passes
> those LDFLAGS directly to gcc :

Unfortunately, genext2fs is not the only sucker in this category. A lot
of packages happen to use gcc as the frontend to ld, and mis-interpret
things such as --fatal-warnings

On Wednesday 23 June 2010 131800 Thomas Petazzoni wrote:
> With this + the HOST_LDFLAGS as shown above, my mkfontscale test case
> is OK, and fakeroot continues to work properly. I managed to build a
> X.org stack + ext2 filesystem for ARM correctly.

Hmm... That's great news, then!

I dwelved into it yesterday evening^Wnight, but mostly from a theoretical
point of view. That is, I googled for such errors. :-/



> Generally speaking, I think we shouldn't do:
>                 CC="$(HOSTCC) $(HOST_CFLAGS)" \
>                 GCC="$(HOSTCC) $(HOST_CFLAGS)" \
>                 CXX="$(HOSTCXX) $(HOST_CXXFLAGS)" \
>                 CPP="$(HOSTCPP) $(HOST_CFLAGS)" \
> But only set CC="$(HOSTCC)", and pass CFLAGS in a separate variable.

Ditto for GCC, GXX, CPP and LD, I guess. And ./configure just does honor the
CPPFLAGS, CFLAGS, CXXFLAGS and LDFLAGS if given in the environmanet and/or
on the command line, IIRC.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'

[Buildroot] Host libraries - status

[Mitch Davis]

Hello,

Yesterday I got bitten by the "mkfontscale" shared library problem
which was discussed in this thread:

  http://lists.busybox.net/pipermail/buildroot/2010-June/035581.html

I also don't think futzing with the rpath is the right solution.  (The
Debian people discuss it here):

  http://wiki.debian.org/RpathIssue

One idea is to have a make var that says how to set the environment
when calling host binaries that we've compiled, something along the
lines of $(HOST_MAKE_ENV).  For each package which calls a host exe
we've compiled, we can overload the calling of that executable with
that var, which would set LD_LIBRARY_PATH just for running that exe.

Here's another idea: We already set PATH to pick up our compiled host
binaries.  And if those binaries expect shared libs in a certain
place, then shouldn't we also set LD_LIBRARY_PATH at the same time as
PATH?  And if not, why not?  Otherwise how are those exes ever
supposed to run?

This would solve the mkfontscale problem, and I don't think this
approach would stop fakeroot from working.  Not sure about the icu
stuff.

Anyway, there may be poor people out there who, like me, are trying to
get 2010.05 working.  I've attached a patch, that while it's not
ideal, it at least Works For Me[tm], and so it may be useful for
others.  One problem with this solution is that people who need more
fonts than me would need to alter more .mk files, whereas setting
LD_LIBRARY_PATH at the same time as PATH wouldn't require this.

Mitch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-mkfontscale-so-locn.diff
Type: application/octet-stream
Size: 3201 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100624/c473bc2e/attachment-0001.obj>

[Buildroot] Host libraries - status

[Thomas Petazzoni]

Hello,

On Thu, 24 Jun 2010 12:21:28 +1000
Mitch Davis <mjd+buildroot@afork.com> wrote:

> Yesterday I got bitten by the "mkfontscale" shared library problem
> which was discussed in this thread:
> 
>   http://lists.busybox.net/pipermail/buildroot/2010-June/035581.html
> 
> I also don't think futzing with the rpath is the right solution.  (The
> Debian people discuss it here):
> 
>   http://wiki.debian.org/RpathIssue

The problem they are describing only occurs when there are migrations
from one library version to another, which is something that never
occurs in Buildroot: we build a single version of a given library, and
all packages that use this library use the same version of the library.

> One idea is to have a make var that says how to set the environment
> when calling host binaries that we've compiled, something along the
> lines of $(HOST_MAKE_ENV).  For each package which calls a host exe
> we've compiled, we can overload the calling of that executable with
> that var, which would set LD_LIBRARY_PATH just for running that exe.

We already tried this, see

 http://git.buildroot.net/buildroot/commit/?id=c1b6242fdcf2cff7ebf09fec4cc1be58963e8427

Unfortunately, it was causing issues, so it got removed:

 http://git.buildroot.net/buildroot/commit/?id=0d1830b07db4ebfd14e77a258de6fb391e57e960

> Here's another idea: We already set PATH to pick up our compiled host
> binaries.  And if those binaries expect shared libs in a certain
> place, then shouldn't we also set LD_LIBRARY_PATH at the same time as
> PATH?  And if not, why not?  Otherwise how are those exes ever
> supposed to run?

See above :-)

> This would solve the mkfontscale problem, and I don't think this
> approach would stop fakeroot from working.  Not sure about the icu
> stuff.

Theorically, yes, using LD_LIBRARY_PATH should work, but we have seen
it causing strange libtool issues. See
http://lists.busybox.net/pipermail/buildroot/2010-May/034163.html for
an example of an issue that was solved by *removing* this
LD_LIBRARY_PATH thing.

But those issues can of course be investigated before we decide to go
with the rpath way or the LD_LIBRARY_PATH way.

> Anyway, there may be poor people out there who, like me, are trying to
> get 2010.05 working.  I've attached a patch, that while it's not
> ideal, it at least Works For Me[tm], and so it may be useful for
> others.  One problem with this solution is that people who need more
> fonts than me would need to alter more .mk files, whereas setting
> LD_LIBRARY_PATH at the same time as PATH wouldn't require this.

I'm sorry, but this patch isn't correct, for two reasons:

 * It is using $(HOST_MAKE_ENV) when doing the installation of *target*
   packages, while HOST_MAKE_ENV, is, as its name suggest, reserved for
   *host* packages. We have $(TARGET_MAKE_ENV) for target packages (see
   references to patches above)

 * It is only using $(HOST_MAKE_ENV) for the installation. Which solves
   the problem you have if the host utility is used at install time and
   not at build time. Adding LD_LIBRARY_PATH to TARGET_MAKE_ENV is
   therefore the appropriate way of doing this. But it unfortunately
   was causing some issues.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Host libraries - status

[Mitch Davis]

On Thu, Jun 24, 2010 at 5:38 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> On Thu, 24 Jun 2010 12:21:28 +1000
> Mitch Davis <mjd+buildroot@afork.com> wrote:
>
>> One idea is to have a make var that says how to set the environment
>> when calling host binaries that we've compiled, something along the
>> lines of $(HOST_MAKE_ENV). ?For each package which calls a host exe
>> we've compiled, we can overload the calling of that executable with
>> that var, which would set LD_LIBRARY_PATH just for running that exe.
>
> We already tried this, see
>
> ?http://git.buildroot.net/buildroot/commit/?id=c1b6242fdcf2cff7ebf09fec4cc1be58963e8427
>
> Unfortunately, it was causing issues, so it got removed:
>
> ?http://git.buildroot.net/buildroot/commit/?id=0d1830b07db4ebfd14e77a258de6fb391e57e960

I see that LD_LIBRARY_PATH isn't just used to resolve libraries at run
time, it's also used by the linker to indicate where shared libs can
be found to link against.  No wonder it doesn't work :-(  I looked at
LD_RUN_PATH, and it seems it's just as bad...

>> Anyway, there may be poor people out there who, like me, are trying to
>> get 2010.05 working. ?I've attached a patch, that while it's not
>> ideal, it at least Works For Me[tm], and so it may be useful for
>> others. ?One problem with this solution is that people who need more
>> fonts than me would need to alter more .mk files, whereas setting
>> LD_LIBRARY_PATH at the same time as PATH wouldn't require this.
>
> I'm sorry, but this patch isn't correct, for two reasons:

Yes the patch isn't correct, and for several reasons.  Nevertheless,
it may be useful for some people until there's a proper fix.

Ok, how about instead of setting LD_LIBRARY_PATH globally, only
setting it temporarily when certain buildroot-builds-for-host binaries
(such as mkfontscale) get called?  (Actually, that's what my patch
does).  That way, the compile-time linker won't get confused.  How
many of these host bins are there?  Can we make some convenience
makefile variables that wrap this?  For example, have a var called
MKFONTSCALE which temporarily sets PATH and LD_LIBRARY_PATH then calls
mkfontscale?

Mitch.