Make problem on 64-bit linux with CS 2009q1

Hello,

I tried a simple build (.config in attachment) on a 64-bit Linux (openSUSE 12.1) with CS 2009q1 toolchain (and last buildroot trunk) and some libs are built to output/target/usr/lib64/ so they are not found as dependencies. With the .config in attachment, you can try a build and check directfb config.log file and PNG lib and others are not found, so directfb is built without support for them. In the final image, they are also in usr/lib64 folder. It may be a problem for other packages.

What could be the problem and how to solve it?

List of files in lib64:
directfb-1.4-6
libdirect-1.4.so.6
libdirect-1.4.so.6.0.9
libdirect.a
libdirectfb-1.4.so.6
libdirectfb-1.4.so.6.0.9
libdirectfb.a
libdirectfb.la
libdirectfb.so
libdirect.la
libdirect.so
libexif.a
libexif.la
libexif.so
libexif.so.12
libexif.so.12.3.2
libfreetype.a
libfreetype.la
libfreetype.so
libfreetype.so.6
libfreetype.so.6.8.0
libfusion-1.4.so.6
libfusion-1.4.so.6.0.9
libfusion.a
libfusion.la
libfusion.so
libjpeg.a
libjpeg.la
libjpeg.so
libjpeg.so.8
libjpeg.so.8.3.0
libpng14.a
libpng14.la
libpng14.so
libpng14.so.14
libpng14.so.14.8.0
libpng.a
libpng.la
libpng.so
libts-1.0.so.0
libts-1.0.so.0.0.0
libts.a
libts.la
libts.so
libungif.a
libungif.la
libungif.so
libungif.so.4
libungif.so.4.1.4
pkgconfig
ts

Best regards,

Guillaume

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.config
Type: application/x-config
Size: 18316 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111209/dd83d763/attachment-0001.bin>

Hello Guillaume,

Le Fri, 09 Dec 2011 09:47:16 +0100,
Guillaume Gardet <[email protected]> a ?crit :

Yeah, we had report of issues with openSUSE. I guess it's the multilib implementation in openSUSE that confuses Buildroot somehow. I need to get my hand on an openSUSE system to debug this.

Can you easily provide me a basic chroot environment with openSUSE installed in it, or point me to the documentation to set it up (knowing, of course, that I don't have openSUSE installed here, so I can't use openSUSE specific utilities to build the openSUSE chroot) ?

Thanks!

Thomas

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

Thomas> Yeah, we had report of issues with openSUSE. I guess it's the multilib Thomas> implementation in openSUSE that confuses Buildroot somehow. I need to Thomas> get my hand on an openSUSE system to debug this.

I just did a suse install in kvm, and haven't been able to reproduce the issue yet. The SUSE devs does seem to have a few peculiar choices, such as having . in the path and using /usr/lib64 for the native 64bit libs.

I'll try the specific .config next.

Bye, Peter Korsgaard

Peter> I just did a suse install in kvm, and haven't been able to reproduce the Peter> issue yet. The SUSE devs does seem to have a few peculiar choices, such Peter> as having . in the path and using /usr/lib64 for the native 64bit libs.

Peter> I'll try the specific .config next.

Which just finished building here without any problems and no usr/lib64. Any ideas?

Bye, Peter Korsgaard

I too am not able to reproduce this build failure.

Starting with a fresh, basic, install of openSUSE 12.1 x86_64 (i.e. not adding any extra packages above and beyond what the installer chooses by default) then:

# zypper -n install git-core gcc ncurses-devel gcc-c++ bison flex
texinfo patch gmp-devel mpfr-devel mpc-devel

After that I ran a default build using the latest buildroot from git; it succeeded. Then I tried using the config as provided in the initial email (I only had to change it to download the CS toolchain) and it too succeeded. I do end up with a target/usr/lib64 directory which appears to contain everything yours does (quick glance) but it doesn't seem to be a problem.

I then installed the "glibc-devel-32bit" package and tried again. It too succeeded (after a "make clean"). I installed that package because the presence of the "/usr/include/gnu/stubs-32.h" file this package installs was interfering with a prior yocto build I had performed (so I thought it might also be a culprit here too, but it wasn't).

Best regards,
Trevor

Le 09/12/2011 22:40, Peter Korsgaard a ?crit :

I am using openSUSE (not SUSE Enterprise). Which version are you using? PATH should not contain . and mine (openSUSE 12.1) does not have it.

Le 10/12/2011 00:27, Trevor Woerner a ?crit :

It was not a real failure, just a directfb build without PNG support. If you want a build failure, try to add fbgrab.

It is since ld will not find libraries in it.

Guillaume

Hello,

Le 09/12/2011 19:37, Thomas Petazzoni a ?crit :

Cannot you make a VM? Because I cannot provide you an openSUSE chroot.

Guillaume

Guillaume> Le 10/12/2011 00:27, Trevor Woerner a ?crit :

Peter> I'll try the specific .config next.

Guillaume> It was not a real failure, just a directfb build without PNG Guillaume> support. If you want a build failure, try to add fbgrab.

Builds here fine. I also don't get any usr/lib64 dirs, so there must be something special about your setup.

Bye, Peter Korsgaard

Hi,

Guillaume> I am using openSUSE (not SUSE Enterprise). Which version are Guillaume> you using? PATH should not contain . and mine (openSUSE Guillaume> 12.1) does not have it.

OpenSUSE 12.1 installed from the gnome livecd. Everything standard except for the extra packages needed for buildroot.

Bye, Peter Korsgaard

Hi,

I finally found the problem. It comes from the file /usr/share/site/x86_64-unknown-linux-gnu which deals with lib64 and does not support arm. A bug report with a patch has been submitted on openSUSE bugzilla :
https://bugzilla.novell.com/show_bug.cgi?id=736143

If needed, you can apply it on a running machine :
https://bugzillafiles.novell.org/attachment.cgi?id=466930

Regards,

Guillaume

Hi,

Le 10/12/2011 20:28, Peter Korsgaard a ?crit :

It is best to install from DVD (especially for non english langages). I assumed you used a 64-bit live CD.

Anyway, I found the (openSUSE) problem and made a patch for it. (See my previous email).

Regards,

Guillaume

Guillaume> Hi,
Guillaume> I finally found the problem. It comes from the file /usr/share/site/x86_64-unknown-linux-gnu which deals with lib64 and does not support arm. Guillaume> A bug report with a patch has been submitted on openSUSE bugzilla :
Guillaume> https://bugzilla.novell.com/show_bug.cgi?id=736143

Ahh. I guess the best approach in buildroot is simply to unset CONFIG_SITE.

Thanks.

Bye, Peter Korsgaard

Le 12/12/2011 10:15, Peter Korsgaard a ?crit :

If buildroot do not use/need it, yes.
Because I have same kind of troubles with some host packages now (not yet released packages). :(

If I unset CONFIG_SITE, it seems to work fine. :)
Could you unset CONFIG_SITE in Buildroot, please?

Guillaume

Le Mon, 12 Dec 2011 11:13:15 +0100,
Guillaume Gardet <[email protected]> a ?crit :

Peter has already modified Buildroot to unset CONFIG_SITE following your report:

http://git.buildroot.net/buildroot/commit/?id=12c9f7dd6dee9c6029b4f9a12d6aac1516911ab4

Thomas

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

Le 12/12/2011 11:17, Thomas Petazzoni a ?crit :

He is too fast! ;)

Thanks.

Guillaume

Hi,

Guillaume> Because I have same kind of troubles with some host packages Guillaume> now (not yet released packages). :(

Guillaume> If I unset CONFIG_SITE, it seems to work fine. :) Guillaume> Could you unset CONFIG_SITE in Buildroot, please?

I already did (12c9f7dd6d).

Bye, Peter Korsgaard

Le 12/12/2011 11:35, Peter Korsgaard a ?crit :

Thanks.

Guillaume

Awesome catch! Thanks for the update.

It appears that the contents of openSUSE 12.1's site file are buggy.

The CONFIG_SITE mechanism is purposefully provided to help "prime the cache" for ./configure scripts when cross compiling to provide answers to questions which would normally require code to be compiled and run (which fails, of course, when the compiler being used is a cross compiler).

Should the CONFIG_SITE feature be disabled and otherwise unavailable to users just because there's a bug in openSUSE's implementation?

Hi,

Trevor> It appears that the contents of openSUSE 12.1's site file are buggy.

Trevor> The CONFIG_SITE mechanism is purposefully provided to help "prime the Trevor> cache" for ./configure scripts when cross compiling to provide answers Trevor> to questions which would normally require code to be compiled and run Trevor> (which fails, of course, when the compiler being used is a cross Trevor> compiler).

Trevor> Should the CONFIG_SITE feature be disabled and otherwise unavailable Trevor> to users just because there's a bug in openSUSE's implementation?

Yes, because whatever defaults potentially could make sense for the build host in general doesn't make sense for the target, and for BR builds to reproducable behaviour shouldn't change depending on something outside our control.

You could perhaps argue for allowing it for host packages, but the simplest/safest option is just to disallow it for all.

Bye, Peter Korsgaard

Or better yet, to use our own and prime it with all the generic configure
variables. That may bring down the huge amount of time spent in running configure scripts...

OTOH, if the one that SUSE provides is buggy, that is probably because it
is difficult to get it correct...

Regards,
Arnout

Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43

Le Wed, 14 Dec 2011 08:08:49 +0100,
Arnout Vandecappelle <[email protected]> a ?crit :

We tried to share the configure variables in the past by sharing the configure cache between packages and this has proven to be very unreliable. However, sharing some really generic variables that are known to be understood by all configure scripts in the same way, is a possibility.

Regards,

Thomas

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

Thomas> Le Wed, 14 Dec 2011 08:08:49 +0100, Thomas> Arnout Vandecappelle <[email protected]> a ?crit :

Thomas> We tried to share the configure variables in the past by sharing the Thomas> configure cache between packages and this has proven to be very Thomas> unreliable. However, sharing some really generic variables that are Thomas> known to be understood by all configure scripts in the same way, is a Thomas> possibility.

We already do that with TARGET_CONFIGURE_ARGS. Putting those in a config.site would afaik be equivalent, but arguably somewhat cleaner.

Bye, Peter Korsgaard

Hi,

Arnout> OTOH, if the one that SUSE provides is buggy, that is probably Arnout> because it is difficult to get it correct...

Well, it's correct for building stuff natively on SUSE, just not for doing cross compilation.

Bye, Peter Korsgaard