Ozgun | 1 Feb 08:58
Picon

lib files



I used chroot environment to get the error log easily. Normally I use the rootfs in a embedded pc.
But the error message are same.

When I try to run application (./affine), it gives "file not found" error.

When I check the dependency (ldd affine)  below log occurs. (even the file compiled static.)
It looks like dynamic library loader finds the .so files under /lib but couldn't find .so files under /usr/lib

I used crosstool glibc instead of uclibc toolchain and the problem solved. (with same etc folder)
But I want to know what cause this problem.

thanks,
Ozgun



    libdl.so.0 => /lib/libdl.so.0 (0xb7788000)
    libc.so.0 => /lib/libc.so.0 (0xb7733000)
    ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb778e000)
    ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb77f9000)
    libc.so.0 => /lib/libc.so.0 (0xb783d000)
    ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7894000)
    libc.so.0 => /lib/libc.so.0 (0xb777c000)
    ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb77d3000)
checking sub-depends for '/usr/lib/libSM.so.6'
checking sub-depends for '/usr/lib/libICE.so.6'
checking sub-depends for '/usr/lib/libXrender.so.1'
checking sub-depends for '/usr/lib/libXcursor.so.1'
checking sub-depends for '/usr/lib/libfontconfig.so.1'
checking sub-depends for '/usr/lib/libfreetype.so.6'
checking sub-depends for '/usr/lib/libXext.so.6'
checking sub-depends for '/usr/lib/libX11.so.6'
checking sub-depends for 'not found'
checking sub-depends for 'not found'
checking sub-depends for '/usr/lib/libGL.so.1'
checking sub-depends for '/lib/libpthread.so.0'
checking sub-depends for '/usr/lib/libstdc++.so.6'
checking sub-depends for 'not found'
checking sub-depends for '/lib/libgcc_s.so.1'
checking sub-depends for 'not found'
checking sub-depends for '/lib/libc.so.0'
checking sub-depends for '/usr/lib/libXfixes.so.3'
checking sub-depends for '/usr/lib/libz.so.1'
checking sub-depends for '/usr/lib/libbz2.so.1.0'
checking sub-depends for '/usr/lib/libexpat.so.1'
checking sub-depends for '/usr/lib/libxcb.so.1'
checking sub-depends for '/lib/libdl.so.0'
checking sub-depends for '/usr/lib/libXdamage.so.1'
checking sub-depends for '/usr/lib/libXxf86vm.so.1'
checking sub-depends for '/usr/lib/libdrm.so.2'
checking sub-depends for '/lib/libm.so.0'
checking sub-depends for '/usr/lib/libXau.so.6'
checking sub-depends for '/usr/lib/libXdmcp.so.6'
    libSM.so.6 => /usr/lib/libSM.so.6 (0x00000000)
    libICE.so.6 => /usr/lib/libICE.so.6 (0x00000000)
    libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00000000)
    libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00000000)
    libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00000000)
    libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00000000)
    libXext.so.6 => /usr/lib/libXext.so.6 (0x00000000)
    libX11.so.6 => /usr/lib/libX11.so.6 (0x00000000)
    libdl.so.2 => not found (0x00000000)
    librt.so.1 => not found (0x00000000)
    libGL.so.1 => /usr/lib/libGL.so.1 (0x00000000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x00000000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00000000)
    libm.so.6 => not found (0x00000000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00000000)
    libc.so.6 => not found (0x00000000)
    libc.so.0 => /lib/libc.so.0 (0x00000000)
    libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00000000)
    libz.so.1 => /usr/lib/libz.so.1 (0x00000000)
    libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00000000)
    libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00000000)
    libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00000000)
    libdl.so.0 => /lib/libdl.so.0 (0x00000000)
    libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00000000)
    libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00000000)
    libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00000000)
    libm.so.0 => /lib/libm.so.0 (0x00000000)
    /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000)
    libXau.so.6 => /usr/lib/libXau.so.6 (0x00000000)
    libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00000000)
    not a dynamic executable





Date: Tue, 31 Jan 2012 17:22:42 +0100
From: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
To: buildroot-9GAsQqxh4YTR7s880joybQ@public.gmane.org
Subject: Re: [Buildroot] lib files
Message-ID: <20120131172242.3a84c018 <at> skate>
Content-Type: text/plain; charset=UTF-8

Le Tue, 31 Jan 2012 18:01:01 +0200,
Ozgun <ozgun.gunay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> a ?crit :

> I built rootfs with opengl and QT without problem. (The compiled examples
> of QT also run in ubuntu without problem)
> But when I tried to run these qt examples in created rootfs, it gives "file
> not found" error. (I both tried these examples static and shared compiled.)

Can you show exactly how this error appears? If it appears when you try
to run the application, then it usually means that the kernel can't
find your dynamic library loader.

I never use Buildroot to generate a filesystem in which I'm chroot-ing.
If the target architecture is the same as the host, it should work, but
there might be issues, it's not the common use case for Buildroot
(usually, you take the generated root filesystem image and put it on a
target device).

> Then I cheked the dependency of application, you can see results below.
> The /usr/lib folder has the lib files but in a .a format.
> For example libm.a is exist but libm.so absent.

The shared versions of the C library and related libraries (libm, etc.)
are in /lib, not in /usr/lib.

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



_______________________________________________
buildroot mailing list
buildroot@...
http://lists.busybox.net/mailman/listinfo/buildroot
Thomas Petazzoni | 1 Feb 09:12
Gravatar

Re: [PATCH 1/8] linux: use the depmod built in HOST_DIR

Le Tue, 31 Jan 2012 23:30:36 +0100,
Peter Korsgaard <jacmet <at> uclibc.org> a écrit :

> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni <at> free-electrons.com> writes:
> 
>  Thomas> Signed-off-by: Thomas Petazzoni <thomas.petazzoni <at> free-electrons.com>
>  Thomas> ---
>  Thomas>  linux/linux.mk |    3 ++-
>  Thomas>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
>  Thomas> diff --git a/linux/linux.mk b/linux/linux.mk
>  Thomas> index 5c5a1d2..dbe1ad7 100644
>  Thomas> --- a/linux/linux.mk
>  Thomas> +++ b/linux/linux.mk
>  Thomas> @@ -40,7 +40,8 @@ LINUX_MAKE_FLAGS = \
>  Thomas>  	ARCH=$(KERNEL_ARCH) \
>  Thomas>  	INSTALL_MOD_PATH=$(TARGET_DIR) \
>  Thomas>  	CROSS_COMPILE="$(CCACHE) $(TARGET_CROSS)" \
>  Thomas> -	LZMA="$(LZMA)"
>  Thomas> +	LZMA="$(LZMA)" \
>  Thomas> +	DEPMOD=$(HOST_DIR)/usr/sbin/depmod
> 
> Committed, thanks. Not released to this patch, but is the LZMA stuff
> still used/needed?

It has been added by
http://git.buildroot.net/buildroot/commit/target/linux/Makefile.in?id=ea8b1fa6a60705eedc5bd4f405f45c8f531c2126,
which is a bit limited in details on why it was needed. I guess the
goal was to tell the Linux build process to use the lzma utility built
for the host by Buildroot, in case the Linux kernel is built (or the
initramfs) with LZMA compression. But that remains to be verified.

Thomas
--

-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot <at> busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Thomas Petazzoni | 1 Feb 09:13
Gravatar

Re: [PATCH 8/8] lttng-babeltrace: new package

Le Tue, 31 Jan 2012 23:52:55 +0100,
Peter Korsgaard <jacmet <at> uclibc.org> a écrit :

> HOST_..._DEPENDENCIES are now automatically derived from _DEPENDENCIES
> by default, so this can be dropped.

Ah, yes, sorry. The patch has been written prior to the introduction of
this mechanism, and I forgot to check this point. Thanks for taking
care of reviewing and fixing!

Regards,

Thomas
--

-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot <at> busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Peter Korsgaard | 1 Feb 09:18
Picon

[git commit] libevas: disable sse3 optimizations for host builds

commit: http://git.buildroot.net/buildroot/commit/?id=2a273b6129efaf07e01b9fc4a70d7730481c68d6
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

There's not really any advantage to adding it, and it depends on
immintrin.h which was added in gcc 4.4, so it breaks with older
host compilers.

For details, see:

http://trac.enlightenment.org/e/ticket/942

Signed-off-by: Peter Korsgaard <jacmet@...>
---
 package/efl/libevas/libevas.mk |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/package/efl/libevas/libevas.mk b/package/efl/libevas/libevas.mk
index acb2f4b..e34967b 100644
--- a/package/efl/libevas/libevas.mk
+++ b/package/efl/libevas/libevas.mk
@@ -13,7 +13,7 @@ LIBEVAS_DEPENDENCIES = host-pkg-config zlib libeina freetype

 HOST_LIBEVAS_DEPENDENCIES = host-pkg-config host-zlib host-libeina \
 				host-freetype host-libpng
-HOST_LIBEVAS_CONF_OPT += --enable-image-loader-png
+HOST_LIBEVAS_CONF_OPT += --enable-image-loader-png --disable-cpu-sse3

 # rendering options
 ifeq ($(BR2_PACKAGE_LIBEVAS_SCALE_SAMPLE),y)
bugzilla | 1 Feb 09:45
Favicon

[Bug 4303] Toolchains qmake causes DEBUG builds with -O2

https://bugs.busybox.net/show_bug.cgi?id=4303

--- Comment #2 from Will Wagner <will_wagner@...> 2012-02-01
08:45:47 UTC ---
(In reply to comment #1)
> Why should we make a special case for Qt here ? If you tell Buildroot to use
> -O2, then it sounds quite logical to have -O2 in the qmake CXXFLAGS, no ? If
> you don't want -O2 in the qmake CXXFLAGS, then tell Buildroot to not use -O2,
> and you're all set.

The reason Qt is different from other packages is that there is a menu option
on whether you want to build debug or release. If you were to select debug it
doesn't seem unreasonable that it should be built with -O0.

That said, I'm not too bothered about seeing this fixed.

--

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Warlich, Christof | 1 Feb 09:35
Picon

External Toolchain: Calculation of SYSROOT_DIR in toolchain/toolchain-external/ext-tool.mk wrong?

Hi,
 
I have an issue with the integration of an external toolchain into buildroot. When I do this,
buildroot complains "Incorrect selection of the C library".
 
Digging for the root case of the problem, I found that SYSROOT_DIR is not calculated correctly
in toolchain/toolchain-external/ext-tool.mk. To fix the problem, I had to replace line 272 of that file:
 
SYSROOT_DIR=`readlink -f $$(LANG=C $(TOOLCHAIN_EXTERNAL_CC) -print-file-name=libc.a) |sed -r -e 's:usr/lib/libc\.a::;'` ; \
 
with
 
SYSROOT_DIR=`readlink -f $$(LANG=C $(TOOLCHAIN_EXTERNAL_CC) -print-file-name=libc.a) |sed -r -e 's:lib/libc\.a::;'` ; \
 
As I'm just new to buildroot, I'm not sure if this is a bug or if this fix is just needed due to an uncommon
packaging of my external toolchain. I'm using the latest buildroot release, i.e. buildroot-2011.11. The
(downstripped) directory structure of my toolchain looks like this:
 
linux_tools
linux_tools/man
linux_tools/man/man7
linux_tools/man/man1
linux_tools/lib
linux_tools/lib/gcc
linux_tools/lib/gcc/i686-v42-linux
linux_tools/lib/gcc/i686-v42-linux/4.2.3
linux_tools/lib/gcc/i686-v42-linux/4.2.3/install-tools
linux_tools/lib/gcc/i686-v42-linux/4.2.3/install-tools/include
linux_tools/lib/gcc/i686-v42-linux/4.2.3/include
linux_tools/lib/gcc/i686-v42-linux/4.2.3/include/ssp
linux_tools/libexec
linux_tools/libexec/gcc
linux_tools/libexec/gcc/i686-v42-linux
linux_tools/libexec/gcc/i686-v42-linux/4.2.3
linux_tools/libexec/gcc/i686-v42-linux/4.2.3/install-tools
linux_tools/info
linux_tools/bin
linux_tools/i686-v42-linux
linux_tools/i686-v42-linux/lib
linux_tools/i686-v42-linux/lib/ldscripts
linux_tools/i686-v42-linux/lib/gconv
linux_tools/i686-v42-linux/libexec
linux_tools/i686-v42-linux/libexec/getconf
linux_tools/i686-v42-linux/bin
linux_tools/i686-v42-linux/sbin
linux_tools/i686-v42-linux/include
linux_tools/i686-v42-linux/etc
linux_tools/i686-v42-linux/share
linux_tools/share
 
and my PATH / PREFIX setting in menuconfig is: /someDirectory/linux_tools / $(ARCH)-v42 with $(ARCH) == i686.
 
Can anyone help in telling me if I found (and fixed? :-)) a bug in buildroot or if something is wrong with my toolchain,
and if so, what's wrong?
 
Thanks for any help,
 
Chris
 
 
_______________________________________________
buildroot mailing list
buildroot@...
http://lists.busybox.net/mailman/listinfo/buildroot
Thomas Petazzoni | 1 Feb 10:38
Gravatar

Re: External Toolchain: Calculation of SYSROOT_DIR in toolchain/toolchain-external/ext-tool.mk wrong?

Hello Christof,

Le Wed, 1 Feb 2012 09:35:06 +0100,
"Warlich, Christof" <christof.warlich <at> siemens.com> a écrit :

> I have an issue with the integration of an external toolchain into buildroot. When I do this,
> buildroot complains "Incorrect selection of the C library".
> 
> Digging for the root case of the problem, I found that SYSROOT_DIR is not calculated correctly
> in toolchain/toolchain-external/ext-tool.mk. To fix the problem, I had to replace line 272 of that file:
> 
> SYSROOT_DIR=`readlink -f $$(LANG=C $(TOOLCHAIN_EXTERNAL_CC) -print-file-name=libc.a) |sed -r -e
's:usr/lib/libc\.a::;'` ; \
> 
> with
> 
> SYSROOT_DIR=`readlink -f $$(LANG=C $(TOOLCHAIN_EXTERNAL_CC) -print-file-name=libc.a) |sed -r -e
's:lib/libc\.a::;'` ; \

Interesting. In all external toolchains I have seen until now, the
dynamic version of libc is in lib/, but the static version is in
usr/lib/.

If we just do your change, then it will basically break the support for
all other external toolchains. We need to be a little bit smarter.

> and my PATH / PREFIX setting in menuconfig is: /someDirectory/linux_tools / $(ARCH)-v42 with $(ARCH) == i686.
> 
> Can anyone help in telling me if I found (and fixed? :-)) a bug in buildroot or if something is wrong with my toolchain,
> and if so, what's wrong?

The directory organization of the various external toolchains available
is such that Buildroot does not necessarily support any random
toolchain.

Would it be possible to get your external toolchain, so that I could do
some testing, and integrate it in my set of external toolchains, so
that we keep it working in the future?

Thanks,

Thomas
--

-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot <at> busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Warlich, Christof | 1 Feb 12:20
Picon

Re: External Toolchain: Calculation of SYSROOT_DIR in toolchain/toolchain-external/ext-tool.mk wrong?

Hi Thomas, 

> Would it be possible to get your external toolchain, so that I could do
> some testing, and integrate it in my set of external toolchains, so
> that we keep it working in the future?

Thanks a lot for the offer, but I doubt that it is worth the effort.

Cheers,

Chris
Thomas Petazzoni | 1 Feb 12:34
Gravatar

Re: External Toolchain: Calculation of SYSROOT_DIR in toolchain/toolchain-external/ext-tool.mk wrong?

Le Wed, 1 Feb 2012 12:20:02 +0100,
"Warlich, Christof" <christof.warlich <at> siemens.com> a écrit :

> > Would it be possible to get your external toolchain, so that I could do
> > some testing, and integrate it in my set of external toolchains, so
> > that we keep it working in the future?
> 
> Thanks a lot for the offer, but I doubt that it is worth the effort.

Well, if we can't test it, it's going to be hard to improve Buildroot
to support this type of toolchain. If you have solved your specific
problem, it's great, but it would have been ever better to improve the
mainline Buildroot so that other users in your case would find things
working nicely :)

Best regards,

Thomas
--

-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot <at> busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Peter Korsgaard | 1 Feb 12:49
Favicon

Re: [PATCH 1/8] linux: use the depmod built in HOST_DIR

>>>>> "Thomas" == Thomas Petazzoni
<thomas.petazzoni@...> writes:

 >> Committed, thanks. Not released to this patch, but is the LZMA stuff
 >> still used/needed?

 Thomas> It has been added by
 Thomas> http://git.buildroot.net/buildroot/commit/target/linux/Makefile.in?id=ea8b1fa6a60705eedc5bd4f405f45c8f531c2126,
 Thomas> which is a bit limited in details on why it was needed. I guess the
 Thomas> goal was to tell the Linux build process to use the lzma utility built
 Thomas> for the host by Buildroot, in case the Linux kernel is built (or the
 Thomas> initramfs) with LZMA compression. But that remains to be verified.

Yes, I know - But I don't see anything using it right away grepping the
kernel. I just wondered if anyone remembered what it was used for (and
if it still is)?

--

-- 
Bye, Peter Korsgaard

Gmane