All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [git commit master] package: Add $(HOST_DIR)/usr/lib to LD_LIBRARY_PATH for host but not target
Date: Thu, 6 May 2010 17:31:39 +0200	[thread overview]
Message-ID: <20100506173139.6962b92d@surf> (raw)
In-Reply-To: <20100503113725.506018D55F@busybox.osuosl.org>

Hello,

On Mon, 3 May 2010 13:37:11 +0200
Peter Korsgaard <jacmet@sunsite.dk> wrote:

> Some packages like icu requires to be compiled against the host system
> first to be able to compile against the target. This is due to the
> usage of self generated binaries by the package to build itself. When
> the generated tools also depends on generated libraries it is required
> to add the path to these libraries in the library path
> (LD_LIBRARY_PATH) especially for the configure step.
> 
> Adding $(HOST_DIR)/usr/lib to LD_LIBRARY_PATH for target compilation
> might break the link step by mixing host libraries and target
> binaries.

In the discussion around this patch, I said that it would break
something : build of target packages that rely on host tools that we
built, that themselves rely on host libraries that we built. But back
in the discussion, I didn't had an example at hand. I have one, now:

make[2]: Entering directory `/home/test/buildroot/output.ctng-arm-eglibc-2010-05-04-12-41-00/build/xfont_font-adobe-100dpi-1.0.1'
/home/test/buildroot/output.ctng-arm-eglibc-2010-05-04-12-41-00/host/usr/bin/mkfontdir /home/test/buildroot/output.ctng-arm-eglibc-2010-05-04-12-41-00/target/usr/share/fonts/X11/100dpi
/home/test/buildroot/output.ctng-arm-eglibc-2010-05-04-12-41-00/host/usr/bin/mkfontscale: error while loading shared libraries: libfontenc.so.1: cannot open shared object file: No such file or directory
make[2]: *** [install-data-hook] Error 127

Here, we are building xfont_font-adobe-100dpi-1.0.1, which requires
mkfontdir, as installed in $(HOST_DIR)/usr/bin. And in turn, mkfontdir
requires libfontenc.so.1 which is installed in $(HOST_DIR)/usr/lib.

My original fix for this was to add $(HOST_DIR)/usr/lib to
LD_LIBRARY_PATH even for the build of target packages. But this was
causing other problems because libtool thought that it could link
against libraries in $(HOST_DIR)/usr/lib while building target
packages, which obviously, isn't possible.

Therefore, the new fix I have tested successfully so far is :

=================================================================================

diff --git a/package/Makefile.in b/package/Makefile.in
index 3dfc712..454b6d5 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -77,6 +77,7 @@ ifeq ($(BR2_LARGEFILE),y)
 TARGET_CFLAGS+=-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
 endif
 
+HOST_CFLAGS+=-Wl,-rpath -Wl,$(HOST_DIR)/usr/lib
 
 #########################################################################
 ifeq ($(BR2_TOOLCHAIN_BUILDROOT),y)

=================================================================================

With this, the host tools are compiled with an rpath included in their
binary, and they are now able to find their libraries, as needed:

$ readelf -d output.ctng-arm-eglibc-2010-05-04-12-41-00/host/usr/bin/mkfontscale  | grep rpath
 0x000000000000000f (RPATH)              Library rpath: [/home/test/buildroot/output.ctng-arm-eglibc-2010-05-04-12-41-00/host/usr/lib]

What do you think of such a change ? Would it be acceptable ? Of
course, I would add a comment before that HOST_CFLAGS line explaining
what the intention is.

Regards,

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

  reply	other threads:[~2010-05-06 15:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-03 11:37 [Buildroot] [git commit master] package: Add $(HOST_DIR)/usr/lib to LD_LIBRARY_PATH for host but not target Peter Korsgaard
2010-05-06 15:31 ` Thomas Petazzoni [this message]
2010-05-06 15:38   ` Peter Korsgaard

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=20100506173139.6962b92d@surf \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /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.