[Buildroot] [git commit master] package: Add $(HOST_DIR)/usr/lib to LD_LIBRARY_PATH for host but not target

[Buildroot] [git commit master] package: Add $(HOST_DIR)/usr/lib to LD_LIBRARY_PATH for host but not target

[Peter Korsgaard]

commit: http://git.buildroot.net/buildroot/commit/?id=0d1830b07db4ebfd14e77a258de6fb391e57e960
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

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.

Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 package/Makefile.in |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/package/Makefile.in b/package/Makefile.in
index acba382..eab9168 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -210,7 +210,6 @@ TARGET_CONFIGURE_OPTS=PATH=$(TARGET_PATH) \
 		PKG_CONFIG="$(PKG_CONFIG_HOST_BINARY)" \
 		PKG_CONFIG_PATH="$(STAGING_DIR)/usr/lib/pkgconfig:$(PKG_CONFIG_PATH)" \
 		PERLLIB="$(HOST_DIR)/usr/lib/perl" \
-		LD_LIBRARY_PATH="$(HOST_DIR)/usr/lib" \
 		STAGING_DIR="$(STAGING_DIR)"
 
 TARGET_CONFIGURE_ENV=\
@@ -220,7 +219,6 @@ TARGET_CONFIGURE_ENV=\
 	FCFLAGS="$(TARGET_FCFLAGS)" \
 
 TARGET_MAKE_ENV=PATH=$(TARGET_PATH) \
-		LD_LIBRARY_PATH="$(HOST_DIR)/usr/lib:$(LD_LIBRARY_PATH)" \
 		PERLLIB="$(HOST_DIR)/usr/lib/perl"
 
 HOST_CONFIGURE_OPTS=PATH=$(HOST_PATH) \
@@ -258,9 +256,12 @@ HOST_CONFIGURE_OPTS=PATH=$(HOST_PATH) \
 		ORIGINAL_LD_FOR_TARGET="$(TARGET_LD)" \
 		ORIGINAL_NM_FOR_TARGET="$(TARGET_NM)" \
 		ORIGINAL_OBJDUMP_FOR_TARGET="$(TARGET_OBJDUMP)" \
+		PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 \
+		PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 \
 		PKG_CONFIG="$(PKG_CONFIG_HOST_BINARY)" \
 		PKG_CONFIG_LIBDIR="$(HOST_DIR)/usr/lib/pkgconfig" \
-		PERLLIB="$(HOST_DIR)/usr/lib/perl"
+		PERLLIB="$(HOST_DIR)/usr/lib/perl" \
+		LD_LIBRARY_PATH="$(HOST_DIR)/usr/lib:$(LD_LIBRARY_PATH)"
 
 HOST_MAKE_ENV=PATH=$(HOST_PATH) \
 		LD_LIBRARY_PATH="$(HOST_DIR)/usr/lib:$(LD_LIBRARY_PATH)" \
-- 
1.6.3.3

[Buildroot] [git commit master] package: Add $(HOST_DIR)/usr/lib to LD_LIBRARY_PATH for host but not target

[Thomas Petazzoni]

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

[Buildroot] [git commit master] package: Add $(HOST_DIR)/usr/lib to LD_LIBRARY_PATH for host but not target

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:


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

Yes, it won't win any prices for prettyness, but I think it's the best
we can do.

Thanks.

-- 
Bye, Peter Korsgaard