Summary: | [cross-x86/glibc] crossdev glibc failure | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bryan Jacobs <BryanRJ> |
Component: | [OLD] Unspecified | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED WORKSFORME | ||
Severity: | minor | CC: | eradicator, Storklerk |
Priority: | High | ||
Version: | 2006.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Bryan Jacobs
2006-06-22 13:40:03 UTC
If it's any help, it should be cding to /var/tmp/cross/i686-pc-linux-gnu/portage/glibc-2.4-r3/work/build-default-i686- pc-linux-gnu-nptl. The ${ABI} environmental variable controls this command, IIRC. Why is it trying for a posix glibc? Where is it getting "pos" from? This doesn't look like it has anything to do with eselect-compiler. Any just curious... why are you pulling in a crossdev i686 toolchain on amd64 anyways? You have one already... I'll test this out, though... Yeah... he doesn't even have eselect-compiler on is system. He's using gcc-config. so it can't be eselect-compiler related. pos is coming from crossdev ... it was used to force ABI to something sane when using gcc-config-1.x as the ABI just broke cross-compilers horribly otherwise Ok, well the sane value would be "default" or just unset it (in which case it would be "default"). (In reply to comment #2) > Where is it getting "pos" from? This doesn't look like it has anything to do > with eselect-compiler. > > Any just curious... why are you pulling in a crossdev i686 toolchain on amd64 > anyways? You have one already... > > I'll test this out, though... > I needed to build a 32-bit libusb to support some proprietary drivers I have, and all the Gentoo documentation pointed me to using crossdev. Plus I was kind of curious about how well this worked b/c I often cross-compile things for arm (handhelds) and a genkernel-like tool for crosscompiling could be very useful :-P. Is there some way to tell emerge to put things into /lib32 and /usr/lib32 and to allow a second installation of a package? Or should I create a second ebuild for the 32bit version? I just built the package from source with --host and --libdir... Speaking of which, I got this to work with the command "crossdev -t i686" when I removed test and maketest from my FEATURES. glibc was failing an nptl-related test because it tried to cd into the aforementioned incorrect directory. So there are three (I think) problems here: 1. The ABI setting is wrong, causing some of the glibcs to fail 2. Some versions of glibc perform the linux-headers version check incorrectly 3. The options descriptions for crossdev are incorrect I just tried to emerge a arm-softfloat-linux-gnu environment to play with my zaurus. It was a nearly comlete disaster, but i think I'm making slow progress. The base system is an up todate ~x86 system, I used the latest crossdev with the following command: crossdev -t arm-softfloat-linux-gnu It failed when it tried to emerge glibc-2.4, because the glibc-configure complained about missing __thread-support. From the log: hecking for stdint.h... no checking for unistd.h... no checking for long double... no checking size of long double... 0 running configure fragment for ports/sysdeps/arm/elf checking for ARM TLS support... no running configure fragment for nptl/sysdeps/pthread configure: error: compiler support for __thread is required !!! ERROR: cross-arm-softfloat-linux-gnu/glibc-2.4-r3 failed. It seems that thread-support is needed from compiling nptl. But the stage1-gcc will not build thread-support if there is no glibc. Chicken-Egg-Problem: * No glibc means no __thread in gcc * No __thread in gcc means no nptl with means no glibc-2.4 I tried to emerge nearly all other <glibc-2.4 versions with the stage1-gcc-4.1. All failed in nptl-mode with above error, using only linuxthreads with severaly other erros. :( The only way to get a arm-glibc was to emerge an additional 3.4.6-crossgcc. It will still fail build glibc-2.4 because of the chicken-egg-problem, but now I have a arm-glibc-2.3.6-r4. Status for crossdev seems to be right now: Broken for gcc-4* Broken for glibc-2.4* Is there some page where I can see working combinations of gcc/glibc for an architecture? The homepage for crossdev only says 'www.gentoo.org' and the packages itself has no docs, but arm/glibc is called 'supported' in crossdev -t help Thanks for any pointers to more docs. I will report later, if building glibc2.4 is working, after I build a __thread-gcc with the glibc-2.3... Ok, glibc-2.4 still does not compile. But as it has neither an arm nor an ~arm keyword, I should not complain about it. Still it looks like a bug in emerge or crossdev that crossdev or a drirect emerge cross-arm-softfloat-linux-gnu/glibc will try to emerge it. (packages.keywords contains the following lines, generated by crossdev: cross-arm-softfloat-linux-gnu/binutils arm ~arm cross-arm-softfloat-linux-gnu/gcc arm ~arm cross-arm-softfloat-linux-gnu/linux-headers arm ~arm cross-arm-softfloat-linux-gnu/glibc arm ~arm cross-arm-softfloat-linux-gnu/gdb arm ~arm My make.conf contains KEYWORDS="~x86") I also found another bug, this one is much more serious: ariolc ~ # eix -e glibc eix: error while loading shared libraries: /usr/lib/gcc/arm-softfloat-linux-gnu/4.1.1/libgcc_s.so.1: ELF file OS ABI invalid I do not know when this was first caused, but I made the following switches with eselect compiler: Switching to cross-arm-softfloat-linux-gnu/gcc-3.4.6 after emerging it Switching back to cross-arm-softfloat-linux-gnu/gcc-4.1.1 for the second try with glibc-2.4 Switching to sys-devel/gcc-4.1.1 to try to cure this error. It did not help. The cause is the following: ld.so.conf contains: ... /usr/lib/gcc/arm-softfloat-linux-gnu/4.1.1 /usr/lib/gcc/i686-pc-linux-gnu/4.1.1 ... /etc/env.d/05compiler contains: # Configuration file for eselect # This file has been automatically generated. INFOPATH="/usr/share/gcc-data/arm-softfloat-linux-gnu/4.1.1/info:/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info" MANPATH="/usr/share/gcc-data/arm-softfloat-linux-gnu/4.1.1/man:/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man" LDPATH="/usr/lib/gcc/arm-softfloat-linux-gnu/4.1.1:/usr/lib/gcc/i686-pc-linux-gnu/4.1.1" /etc/env.d/gcc contains the following files: rm-softfloat-linux-gnu-3.4.6 arm-softfloat-linux-gnu-3.4.6-hardenednopiessp arm-softfloat-linux-gnu-4.1.1 config config- config-i686-pc-linux-gnu i686-pc-linux-gnu-3.4.6 i686-pc-linux-gnu-3.4.6-hardened i686-pc-linux-gnu-3.4.6-hardenednopie i686-pc-linux-gnu-3.4.6-hardenednopiessp i686-pc-linux-gnu-3.4.6-hardenednossp i686-pc-linux-gnu-4.0.3 i686-pc-linux-gnu-4.1.1 So becaus [a]rm comes before [i]686, eselect seems to think I prefer using arm libraries on an x86 system. :( I will fix this manually, but should I file a new bug about this? Using the .so from another architecture seems to be a rather bad thing to do. Torsten, your issue is unrelated to the one originally reported. Can you please open a new one and assign it to me? Thanks. Bugs filed as #137909 and #137917 But I could not assign them to you, as the assign-to-inputfield on the new-bug-page seems to be readonly in Konqueror. latest stuff works for me ... considering the wierd error, looks like the source tree was deleted after building or something ... |