[Buildroot] this commit breaks x86_64 toolchain builds

[Buildroot] this commit breaks x86_64 toolchain builds

[Roderick Taylor]

x86_64, by default uses the lib64 directory to hold 64-bit libraries.
not the lib directory as assumed by this commit.

http://buildroot.busybox.net/cgi-bin/viewcvs.cgi?rev=19702&view=rev

[Buildroot] this commit breaks x86_64 toolchain builds

[Bernhard Fischer]

On Thu, Sep 06, 2007 at 10:59:56PM +1000, Roderick Taylor wrote:
>x86_64, by default uses the lib64 directory to hold 64-bit libraries.
>not the lib directory as assumed by this commit.

I don't see how the patch mentioned below is the culprit?
>
>http://buildroot.busybox.net/cgi-bin/viewcvs.cgi?rev=19702&view=rev

Isn't there a target_gcc_lib_dir we should rather use?

[Buildroot] this commit breaks x86_64 toolchain builds

[Roderick Taylor]

On 07/09/2007, Bernhard Fischer <rep.dot.nop@gmail.com> wrote:
> On Thu, Sep 06, 2007 at 10:59:56PM +1000, Roderick Taylor wrote:
> >x86_64, by default uses the lib64 directory to hold 64-bit libraries.
> >not the lib directory as assumed by this commit.
>
> I don't see how the patch mentioned below is the culprit?

the "-" infront of the cp means ignore errors.  When you build for
x86_64, buildroot puts libgcc_s* etc. in $(REAL_GNU_TARGET_NAME)/lib64
not in lib.  so this line will produce an error, and because the patch
stops make from ignoring this, the build stops.

-	-cp -dpf $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib/libgcc_s*
$(TARGET_DIR)/lib/
+	cp -dpf $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib/libgcc_s*


> Isn't there a target_gcc_lib_dir we should rather use?
>

I don't know.   I know we can either modify the gcc build to install
into lib instead of lib64 but I haven't tried it.

[Buildroot] this commit breaks x86_64 toolchain builds

[Bernhard Fischer]

On Tue, Sep 11, 2007 at 07:45:09AM +1000, Roderick Taylor wrote:
>On 07/09/2007, Bernhard Fischer <rep.dot.nop@gmail.com> wrote:
>> On Thu, Sep 06, 2007 at 10:59:56PM +1000, Roderick Taylor wrote:
>> >x86_64, by default uses the lib64 directory to hold 64-bit libraries.
>> >not the lib directory as assumed by this commit.
>>
>> I don't see how the patch mentioned below is the culprit?
>
>the "-" infront of the cp means ignore errors.  When you build for
>x86_64, buildroot puts libgcc_s* etc. in $(REAL_GNU_TARGET_NAME)/lib64
>not in lib.  so this line will produce an error, and because the patch
>stops make from ignoring this, the build stops.
>
>-	-cp -dpf $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib/libgcc_s*
>$(TARGET_DIR)/lib/
>+	cp -dpf $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib/libgcc_s*
>
>
>> Isn't there a target_gcc_lib_dir we should rather use?
>>
>
>I don't know.   I know we can either modify the gcc build to install
>into lib instead of lib64 but I haven't tried it.

If the cp errors are ignored, you'd have no libgcc on the target, is
that assumption correct? If so, the we have to handle lib64 in a better
way. Please verify and let me know..

TIA,

[Buildroot] this commit breaks x86_64 toolchain builds

[Roderick Taylor]

On 12/09/2007, Bernhard Fischer <rep.dot.nop@gmail.com> wrote:
> On Tue, Sep 11, 2007 at 07:45:09AM +1000, Roderick Taylor wrote:
> >On 07/09/2007, Bernhard Fischer <rep.dot.nop@gmail.com> wrote:
> >> On Thu, Sep 06, 2007 at 10:59:56PM +1000, Roderick Taylor wrote:
> >> >x86_64, by default uses the lib64 directory to hold 64-bit libraries.
> >> >not the lib directory as assumed by this commit.
> >>
> >> I don't see how the patch mentioned below is the culprit?
> >
> >the "-" infront of the cp means ignore errors.  When you build for
> >x86_64, buildroot puts libgcc_s* etc. in $(REAL_GNU_TARGET_NAME)/lib64
> >not in lib.  so this line will produce an error, and because the patch
> >stops make from ignoring this, the build stops.
> >
> >-      -cp -dpf $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib/libgcc_s*
> >$(TARGET_DIR)/lib/
> >+      cp -dpf $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib/libgcc_s*
> >
> >
> >> Isn't there a target_gcc_lib_dir we should rather use?
> >>
> >
> >I don't know.   I know we can either modify the gcc build to install
> >into lib instead of lib64 but I haven't tried it.
>
> If the cp errors are ignored, you'd have no libgcc on the target, is
> that assumption correct? If so, the we have to handle lib64 in a better
> way. Please verify and let me know..
>
> TIA,
>

Yes, libgcc is missing from the target, but I'm not having any
problems running programs (Although, the only programs I've tested
busybox and lspci)

I think a better way is to configure gcc to use
$(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib and not lib64

Here is an small patch for gcc to do this.  I have tested it with
gcc-4.2.1 in buildroot and it works.  i.e. libgcc_s.so* are placed in
$(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib and subsequently copied
to the target.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: swaplibdirs.patch
Type: text/x-patch
Size: 449 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20070912/3608dde2/attachment.bin 

[Buildroot] this commit breaks x86_64 toolchain builds

[Bernhard Fischer]

On Wed, Sep 12, 2007 at 10:54:35PM +1000, Roderick Taylor wrote:
>On 12/09/2007, Bernhard Fischer <rep.dot.nop@gmail.com> wrote:
>> On Tue, Sep 11, 2007 at 07:45:09AM +1000, Roderick Taylor wrote:
>> >On 07/09/2007, Bernhard Fischer <rep.dot.nop@gmail.com> wrote:
>> >> On Thu, Sep 06, 2007 at 10:59:56PM +1000, Roderick Taylor wrote:
>> >> >x86_64, by default uses the lib64 directory to hold 64-bit libraries.
>> >> >not the lib directory as assumed by this commit.
>> >>
>> >> I don't see how the patch mentioned below is the culprit?
>> >
>> >the "-" infront of the cp means ignore errors.  When you build for
>> >x86_64, buildroot puts libgcc_s* etc. in $(REAL_GNU_TARGET_NAME)/lib64
>> >not in lib.  so this line will produce an error, and because the patch
>> >stops make from ignoring this, the build stops.
>> >
>> >-      -cp -dpf $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib/libgcc_s*
>> >$(TARGET_DIR)/lib/
>> >+      cp -dpf $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib/libgcc_s*
>> >
>> >
>> >> Isn't there a target_gcc_lib_dir we should rather use?
>> >>
>> >
>> >I don't know.   I know we can either modify the gcc build to install
>> >into lib instead of lib64 but I haven't tried it.
>>
>> If the cp errors are ignored, you'd have no libgcc on the target, is
>> that assumption correct? If so, the we have to handle lib64 in a better
>> way. Please verify and let me know..
>>
>> TIA,
>>
>
>Yes, libgcc is missing from the target, but I'm not having any
>problems running programs (Although, the only programs I've tested
>busybox and lspci)
>
>I think a better way is to configure gcc to use
>$(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib and not lib64

Unfortunately this is not accurate, you'd break multilib support by
this.

We will have to retain the lib/ vs. lib64/ layout for multilib anyway.
The proper thing to do is to copy the correct libgcc_s to the
corresponding dir (in both the staging dir and the target dir, if asked
to). Look at BR2_MULTILIB. If it is set, copy the libgcc_s that are
currently built. If it is not set, look at the target arch and copy the
corresponding (one) libgcc_s to the appropriate dir.

Care to do that?

[Buildroot] this commit breaks x86_64 toolchain builds

[Roderick Taylor]

On 21/09/2007, Bernhard Fischer <rep.dot.nop@gmail.com> wrote:
> On Wed, Sep 12, 2007 at 10:54:35PM +1000, Roderick Taylor wrote:
> >On 12/09/2007, Bernhard Fischer <rep.dot.nop@gmail.com> wrote:
> >> On Tue, Sep 11, 2007 at 07:45:09AM +1000, Roderick Taylor wrote:
> >> >On 07/09/2007, Bernhard Fischer <rep.dot.nop@gmail.com> wrote:
> >> >> On Thu, Sep 06, 2007 at 10:59:56PM +1000, Roderick Taylor wrote:
> >> >> >x86_64, by default uses the lib64 directory to hold 64-bit libraries.
> >> >> >not the lib directory as assumed by this commit.
> >> >>
> >> >> I don't see how the patch mentioned below is the culprit?
> >> >
> >> >the "-" infront of the cp means ignore errors.  When you build for
> >> >x86_64, buildroot puts libgcc_s* etc. in $(REAL_GNU_TARGET_NAME)/lib64
> >> >not in lib.  so this line will produce an error, and because the patch
> >> >stops make from ignoring this, the build stops.
> >> >
> >> >-      -cp -dpf $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib/libgcc_s*
> >> >$(TARGET_DIR)/lib/
> >> >+      cp -dpf $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib/libgcc_s*
> >> >
> >> >
> >> >> Isn't there a target_gcc_lib_dir we should rather use?
> >> >>
> >> >
> >> >I don't know.   I know we can either modify the gcc build to install
> >> >into lib instead of lib64 but I haven't tried it.
> >>
> >> If the cp errors are ignored, you'd have no libgcc on the target, is
> >> that assumption correct? If so, the we have to handle lib64 in a better
> >> way. Please verify and let me know..
> >>
> >> TIA,
> >>
> >
> >Yes, libgcc is missing from the target, but I'm not having any
> >problems running programs (Although, the only programs I've tested
> >busybox and lspci)
> >
> >I think a better way is to configure gcc to use
> >$(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib and not lib64
>
> Unfortunately this is not accurate, you'd break multilib support by
> this.
>
> We will have to retain the lib/ vs. lib64/ layout for multilib anyway.
> The proper thing to do is to copy the correct libgcc_s to the
> corresponding dir (in both the staging dir and the target dir, if asked
> to). Look at BR2_MULTILIB. If it is set, copy the libgcc_s that are
> currently built. If it is not set, look at the target arch and copy the
> corresponding (one) libgcc_s to the appropriate dir.
>
> Care to do that?
>

[Buildroot] this commit breaks x86_64 toolchain builds

[Roderick Taylor]

> We will have to retain the lib/ vs. lib64/ layout for multilib anyway.

I dont' use Debian but from what I've read when investigating the
original problem, it doesn't use this directory scheme, it uses lib
and lib32. Thats how I come across this patch.  I'm not sure how
changing multilib directories will break support for it.  I'd say it
would only be broken if something that is built later on in buildroot
was hardcoded to use the lib64 directory, or you wanted to use a
32-bit proprietary program that expects libraries are in lib.  But
which is broken?  The directory structure or the thing that depends
upon it?

http://www.redhat.com/magazine/009jul05/features/multilib/

> to). Look at BR2_MULTILIB.

You mean BR2_ENABLE_MULTILIB.

x86_64 builds of GCC-4.2.1 puts the 64-bit libraries into /lib64 even
if you disable multilib.