* [Buildroot] this commit breaks x86_64 toolchain builds @ 2007-09-06 12:59 Roderick Taylor 2007-09-07 13:14 ` Bernhard Fischer 0 siblings, 1 reply; 8+ messages in thread From: Roderick Taylor @ 2007-09-06 12:59 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] this commit breaks x86_64 toolchain builds 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 0 siblings, 1 reply; 8+ messages in thread From: Bernhard Fischer @ 2007-09-07 13:14 UTC (permalink / raw) To: buildroot 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? ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] this commit breaks x86_64 toolchain builds 2007-09-07 13:14 ` Bernhard Fischer @ 2007-09-10 21:45 ` Roderick Taylor 2007-09-11 18:35 ` Bernhard Fischer 0 siblings, 1 reply; 8+ messages in thread From: Roderick Taylor @ 2007-09-10 21:45 UTC (permalink / raw) To: buildroot 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] this commit breaks x86_64 toolchain builds 2007-09-10 21:45 ` Roderick Taylor @ 2007-09-11 18:35 ` Bernhard Fischer 2007-09-12 12:54 ` Roderick Taylor 0 siblings, 1 reply; 8+ messages in thread From: Bernhard Fischer @ 2007-09-11 18:35 UTC (permalink / raw) To: buildroot 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, ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] this commit breaks x86_64 toolchain builds 2007-09-11 18:35 ` Bernhard Fischer @ 2007-09-12 12:54 ` Roderick Taylor 2007-09-21 9:31 ` Bernhard Fischer 0 siblings, 1 reply; 8+ messages in thread From: Roderick Taylor @ 2007-09-12 12:54 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] this commit breaks x86_64 toolchain builds 2007-09-12 12:54 ` Roderick Taylor @ 2007-09-21 9:31 ` Bernhard Fischer 2007-09-23 2:37 ` Roderick Taylor 2007-09-23 3:30 ` Roderick Taylor 0 siblings, 2 replies; 8+ messages in thread From: Bernhard Fischer @ 2007-09-21 9:31 UTC (permalink / raw) To: buildroot 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? ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] this commit breaks x86_64 toolchain builds 2007-09-21 9:31 ` Bernhard Fischer @ 2007-09-23 2:37 ` Roderick Taylor 2007-09-23 3:30 ` Roderick Taylor 1 sibling, 0 replies; 8+ messages in thread From: Roderick Taylor @ 2007-09-23 2:37 UTC (permalink / raw) To: buildroot 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? > ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] this commit breaks x86_64 toolchain builds 2007-09-21 9:31 ` Bernhard Fischer 2007-09-23 2:37 ` Roderick Taylor @ 2007-09-23 3:30 ` Roderick Taylor 1 sibling, 0 replies; 8+ messages in thread From: Roderick Taylor @ 2007-09-23 3:30 UTC (permalink / raw) To: buildroot > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2007-09-23 3:30 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2007-09-23 2:37 ` Roderick Taylor 2007-09-23 3:30 ` Roderick Taylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox