From: Bernhard Fischer <rep.dot.nop@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] this commit breaks x86_64 toolchain builds
Date: Fri, 21 Sep 2007 11:31:01 +0200 [thread overview]
Message-ID: <20070921093101.GD24467@aon.at> (raw)
In-Reply-To: <e83232070709120554h3d995dfdwbc055e701b271f80@mail.gmail.com>
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?
next prev parent reply other threads:[~2007-09-21 9:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-06 12:59 [Buildroot] this commit breaks x86_64 toolchain builds Roderick Taylor
2007-09-07 13:14 ` Bernhard Fischer
2007-09-10 21:45 ` Roderick Taylor
2007-09-11 18:35 ` Bernhard Fischer
2007-09-12 12:54 ` Roderick Taylor
2007-09-21 9:31 ` Bernhard Fischer [this message]
2007-09-23 2:37 ` Roderick Taylor
2007-09-23 3:30 ` Roderick Taylor
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=20070921093101.GD24467@aon.at \
--to=rep.dot.nop@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox