crossdev is not able to build a cross toolchain against uclibc-0.9.33.2-r15 on x86_64. The bootstrap fails on a stage2 gcc and even the stage1 gcc does not work properly. Reproducible: Always Steps to Reproduce: 1. Try building a crosstoolchain 2. Try to build and execute something Actual Results: Boostrap bails out Expected Results: Clean build I'll add posts to complete this step by step as there'S several issues involved. First one is: stage2 gcc fails to build, because of a missing wordexp.h. That is, when gcc[+sanitize] is being built during stage 2. Unfortunately that's the default setup by crossdev. gcc[-sanitize] will build properly though and should probably be the preset USE flags by crossdev..
Building a stage2 gcc with +sanitize will require a uclibc with +wordexp. Unfortunately that will not do - the stage2 build still bails out with a missing netrom/netrom.h header. On the host this header seems to belong to glibc. Of course glibc does not ship with netorm.h but it is rather generated from a kernel header. I did not see any option in uclibc for that.
Further uclibc is generally misconfigured. By default it does not enable LDSO's support for gnu hashes. Even though binutils ld's man page claims that the default hash type is sysv, ld defaults to gnu hash style. But even when setting --hash-style=sysv (or =both for that matter) uclibc's ld.so cannot dynamically link the created executeables. It will rather bail out with an error about unresolveable symbols. Which is a little puzzling to me. But obviously gnu hash support is mandatory (for recent binutils) and should be added to the default options when building the cross toolchain.
Copying netrom.h from the rost into the target sysroot fixes the missing netrom.h issue. This is however not a real fix. Next missing header is ustat.h, which is provided by uclibc when: UCLIBC_SV4_DEPRECATED=y Now gcc[sanitize] bails out with: in file included from /usr/x86_64-pc-linux-uclibc/sys-include/linux/kernel.h:4:0, from /usr/x86_64-pc-linux-uclibc/sys-include/linux/sysctl.h:25, from /var/tmp/portage/cross-x86_64-pc-linux-uclibc/gcc-5.3.0/work/gcc-5.3.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:73: /usr/x86_64-pc-linux-uclibc/sys-include/linux/sysinfo.h:7:8: error: redefinition of ‘struct sysinfo’ struct sysinfo { ^ In file included from /var/tmp/portage/cross-x86_64-pc-linux-uclibc/gcc-5.3.0/work/gcc-5.3.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:64:0: /usr/x86_64-pc-linux-uclibc/sys-include/sys/sysinfo.h:28:8: error: previous definition of ‘struct sysinfo’ struct sysinfo { ^ mv -f .deps/reshape_i8.Tpo .deps/reshape_i8.Plo
Another 'misconfiguration' of uclibc that triggers problems when +shadow is set: crypt method not supported by libcrypt? (SHA512) The default uclibc configuration for a cross toolchain however sets: # UCLIBC_HAS_SHA256_CRYPT_IMPL is not set # UCLIBC_HAS_SHA512_CRYPT_IMPL is not set So for cross targets where USE="shadow" those two need to be set.
One thing I noticed about uclibc's ebuild in general is the lack of synchronization of use flags and config. Example, build a cross uclibc. Then set USE="savedconfig". Now changes to USE flags have no effect. The other way round the same. Changes to savedconfig do not get reflected in USE flags. This is quite problematic with respect to dependencies. And yes, I am aware that there's no simple solution to this problem. I doubt this really would change with uclibc-ng?
(In reply to Sven E. from comment #5) the whole point of USE=savedconfig is that you have full control over settings. what you describe is not a bug. you must attach full details on what you're trying to do (exact commands) and full build logs showing the failures.
(In reply to SpanKY from comment #6) > (In reply to Sven E. from comment #5) > > the whole point of USE=savedconfig is that you have full control over > settings. what you describe is not a bug. I see. But you do see the problem that lies in there? All USE-flags based dependencies get killed by the precedence of 'savedconfig'. Then again, almost all Options required to compile stuff need to be set manually as there's no USE-flags and proper dependencies for them. I could easily agree with your view if all necessary options were enabled by default, where necessary means covering all possible USE-flags. Anyhow, this is a problem intrinsic to uclibc and it'S ebuild. > > you must attach full details on what you're trying to do (exact commands) > and full build logs showing the failures. Okay, I'll have to rm -rf to do that and find a way to get the logs in here more easily.
USE-flags as (pre)set by crossdev: stratus ~ # cat /etc/portage/package.use/cross-x86_64-pc-linux-uclibc cross-x86_64-pc-linux-uclibc/binutils -selinux -multilib cross-x86_64-pc-linux-uclibc/linux-headers -selinux -multilib cross-x86_64-pc-linux-uclibc/uclibc -selinux -multilib cross-x86_64-pc-linux-uclibc/gcc -selinux -boundschecking -d -gcj -gtk -libffi -mudflap -objc -objc++ -objc-gc -fortran -go nocxx -cxx -openmp -sanitize -multilib
Created attachment 433132 [details] gcc stage2 build failure (1) This is the build.log from a failing stage2 gcc build. Note that the failure happens in libsanitizer which is enabled by default
As I already said: wordexp.h is missing.
Addind wordexp to USE: cat /etc/portage/package.use/cross-x86_64-pc-linux-uclibc cross-x86_64-pc-linux-uclibc/binutils -selinux -multilib cross-x86_64-pc-linux-uclibc/linux-headers -selinux -multilib cross-x86_64-pc-linux-uclibc/uclibc -selinux -multilib wordexp cross-x86_64-pc-linux-uclibc/gcc -selinux -boundschecking -d -gcj -gtk -libffi -mudflap -objc -objc++ -objc-gc -multilib
Previously mentioned ldso misconfiguration: # echo "int main(){return 0;}" > dummy.c # x86_64-pc-linux-uclibc-gcc -o dummy dummy.c # x86_64-pc-linux-uclibc-ldd dummy checking sub-depends for 'not found' libc.so.0 => not found (0x00000000) /lib/ld64-uClibc.so.0 => /lib/ld64-uClibc.so.0 (0x00000000) # chroot . /dummy /dummy: symbol '_stdio_openlist_use_count': can't resolve symbol
Created attachment 433134 [details] gcc stage2 build failure (2) Failing build with +wrodexp
Missing netrom.h as described.
While waiting for the next build failure and log, let's look at the LDSO problem a little more: Quote: --hash-style=style Set the type of linker's hash table(s). style can be either "sysv" for classic ELF ".hash" section, "gnu" for new style GNU ".gnu.hash" section or "both" for both the classic ELF ".hash" and new style GNU ".gnu.hash" hash tables. The default is "sysv". Let's see: objdump -h -j .hash dummy dummy: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn objdump: section '.hash' mentioned in a -j option, but not found in any input file objdump -h -j .gnu.hash dummy dummy: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn 1 .gnu.hash 00000034 0000000000400250 0000000000400250 00000250 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA Really looks like sysv hashes are default .... Let's look at the uclibc config as given by crossdev: grep HASH /etc/portage/savedconfig/cross-x86_64-pc-linux-uclibc/uclibc-0.9.33.2-r15 # LDSO_GNU_HASH_SUPPORT is not set Let's try a little harder: # x86_64-pc-linux-uclibc-gcc -Wl,--hash-style=sysv -o dummy dummy.c # chroot . /dummy /dummy: symbol '_stdio_openlist_use_count': can't resolve symbol Maybe the linker does not care and created a gnu hash again? # objdump -h -j .gnu.hash dummy dummy: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn objdump: section '.gnu.hash' mentioned in a -j option, but not found in any input file No GNU hash anymore stratus x86_64-pc-linux-uclibc # objdump -h -j .hash dummy dummy: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn 1 .hash 0000002c 0000000000400250 0000000000400250 00000250 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA But a sysv hash is present. Okay, another one, for the sake of completeness: # x86_64-pc-linux-uclibc-gcc -Wl,--hash-style=both -o dummy dummy.c # chroot . /dummy /dummy: symbol '_stdio_openlist_use_count': can't resolve symbol # objdump -h -j .hash dummy dummy: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn 1 .hash 0000002c 0000000000400250 0000000000400250 00000250 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA # objdump -h -j .gnu.hash dummy dummy: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn 2 .gnu.hash 00000034 0000000000400280 0000000000400280 00000280 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA Even though the dynamic linker can use whatever hash it likes, no success.
Created attachment 433136 [details] gcc stage2 build failure (3) After copying over netrom.h another build failure down the road
Now ustat.h is missing. uclibc can provide ustat.h (as previously mentioned). Now, let's see what USE flags we need to get ustat.h and while at it, the one for GNU HASH support.... Oh, no USE-flag? No more seatbelts? Okay, modify options, rebuild uclibc && build stage2 gcc: stratus x86_64-pc-linux-uclibc # x86_64-pc-linux-uclibc-gcc -o dummy dummy.c stratus x86_64-pc-linux-uclibc # chroot . /dummy Now gnu hashes seem to work... stratus x86_64-pc-linux-uclibc # x86_64-pc-linux-uclibc-gcc -Wl,--hash-style=sysv -o dummy dummy.c stratus x86_64-pc-linux-uclibc # chroot . /dummy And sysv-hashes. So GNU-HASH support is needed for both hash types. That's quite understandable, that we need GNU-HASH support for sysv hashes. Only thing that I could think of (don't know how to debug this): gold ld with LTO which is needed even for sysv hashes and only enabled when gnu hash support is enabled in uclibc. But unfortunately gcc still fails to build.
Created attachment 433138 [details] gcc stage2 build failure (4) Now that ustat.h is provided the fun-errors pop up
First error (redifinition of struct sysinfo): wrong include and wrong inclusion order. Next one's failed assertions: Obviously some types have a storage size of 0. I have no idea so far what causes this. The assertions about missing members could be caused by a missing include which is only provided by glibc extensions or so.
So, afterall I decided to go for gcc[-sanitize] which is probably what crosddev should set up. (Unfortunately Comment 11 already includes a later change, -sanitize was not part of the USE-flags after crossdev setup the package.use file) Regarding Comment 4: After x-ermerging some core packages including bash, shadow and some more), the commands in detail are: stratus ~ # chroot /usr/x86_64-pc-linux-uclibc/ stratus / # passwd root Changing password for root Enter the new password (minimum of 5 characters) Please use a combination of upper and lower case letters and numbers. New password: Bad password: too short. Warning: weak password (enter it again to use it anyway). New password: Re-enter new password: crypt method not supported by libcrypt? (SHA512) Which seems legit as the configuration as created by crossdev says: UCLIBC_HAS_CRYPT_IMPL=y # UCLIBC_HAS_SHA256_CRYPT_IMPL is not set # UCLIBC_HAS_SHA512_CRYPT_IMPL is not set UCLIBC_HAS_CRYPT=y
Created attachment 433142 [details] build.log net-misc/iputils-20151218 build failure (also due to a misconfigured uclibc)
# grep LIBRESOLV /etc/portage/savedconfig/cross-x86_64-pc-linux-uclibc/uclibc-0.9.33.2-r15 # UCLIBC_HAS_LIBRESOLV_STUB is not set
(In reply to Sven E. from comment #7) this is how USE=savedconfig works for all ebuilds that leverage it, and how we want it to behave. uClibc isn't unique here. (In reply to Sven E. from comment #9) USE=sanitize issues is bug 525910, and it looks like all of your gcc build logs are failing that way. *** This bug has been marked as a duplicate of bug 525910 ***
(In reply to Sven E. from comment #21) you can probably file a new bug just for iputils. i don't think we want to make libresolv a hard requirement everywhere. should be dynamic detection.
(In reply to SpanKY from comment #23) > (In reply to Sven E. from comment #7) > > this is how USE=savedconfig works for all ebuilds that leverage it, and how > we want it to behave. uClibc isn't unique here. I wonder what you're suggesting regarding dependencies on one (or more) of uclibc's options then? Usually there's use flags to handle such deps. I doubt that +savedconfig and manual editing uclibc's configuration is an adequate way of dependency handling. > > (In reply to Sven E. from comment #9) > > USE=sanitize issues is bug 525910, and it looks like all of your gcc build > logs are failing that way. > > *** This bug has been marked as a duplicate of bug 525910 *** I suggested right at #1 that -sanitize is probably what should be done. However the dynamic linker is still not working due to uclibc's default config and that's why this is neither a duplicate nor resolved by the claimed 'duplicate'.
(In reply to SpanKY from comment #24) > (In reply to Sven E. from comment #21) > > you can probably file a new bug just for iputils. i don't think we want to > make libresolv a hard requirement everywhere. should be dynamic detection. I really wonder how a 'dynamic detection' could possibly work? And what about shadow (#4 & #20)?
if the symbol errors fail with the default config settings, i'll take a look. if it's only failing with your own USE=savedconfig settings, then you can figure it out. if you want assistance, try the user forums/mailing lists ... bugzilla isn't for that. otherwise, everything else you reported has been covered already.
(In reply to SpanKY from comment #27) > if the symbol errors fail with the default config settings, i'll take a > look. if it's only failing with your own USE=savedconfig settings, then you > can figure it out. if you want assistance, try the user forums/mailing > lists ... bugzilla isn't for that. > > otherwise, everything else you reported has been covered already. Both, the +sanitize build error on gcc stage2 as well as uclibc's failure to dynamicly link with the default configuration are trivial to spot and fix. There is simply no way something like that can slip through the maintainer's hands. It is not a matter of assistance but of fixing breakage and thus it's bugs. shadow and iputils fail to build with x-emerge, so that's bugs. Both are failing with DEFAULT configs. A savedconfig is needed to get things going. Saying people to figure out things when using an own config, while an own config is mandatory to get things to work is a major logical fallac. No matter what way you look at it, if x-emerge fails to build iputils (example) because of uclibc's (default-)configuration than this is not an iputils bug. uclibc's default configuration is simply faulty and/or incomplete. You said the way savedconfig works is intended, so be it - there is a major difference to other packages: without a savedconfig (examples) linux-firmware installs everything no matter how obscure. Same goes for busybox, the default configuration includes heaps of rather obscure applets. For uclibc not even x-emrerging @system works. And referring to the forums for assistance evem though one canot get assistance there most of the time, due to lack of capabilities is a rather snotty thing to do. So please spare people from such pointless/stupid recommendations - Thanks.
(In reply to Sven E. from comment #28) you haven't outlined any specific breakage in the USE=-savedconfig case. as for the USE=savedconfig case, i already told you what to do wrt libresolv: file a new bug. otherwise, you haven't provided any useful/actionable details.
(In reply to SpanKY from comment #29) > (In reply to Sven E. from comment #28) > > you haven't outlined any specific breakage in the USE=-savedconfig case. > > as for the USE=savedconfig case, i already told you what to do wrt > libresolv: file a new bug. otherwise, you haven't provided any > useful/actionable details. Not only did I outline it, I gave specific instructions and examples, including commands, example prog and error messages (#2, #12, #15 and #17). I even EXPLAINED that (cross-)ld in contrast to the claim in ld's manpage uses .gnu.hash sections by DEFAULT, whereas uclibc's DEFAULT configuration does not include support for GNU HASHES. Even without ANY further information the logical contradiction exposed by the defaults get OBVIOUS. So, once again (Second extra copy basicly): 1.) Setup a cross-toolchain for x86_64/uclibc: crossdev -oO /usr/local/crossport --genv USE="-sanitize" -s4 -t x86_64-pc-linux-uclibc ** --genv USE="-sanitize" required to work around bug that's not yet fixed 2.) Create minimal C only example: echo "int main(){return 0;}" > dummy.c 3.) And compile it: x86_64-pc-linux-uclibc-gcc -o dummy dummy.c 4.) Try to run it: chroot . /dummy /dummy: symbol '_stdio_openlist_use_count': can't resolve symbol ** chrooting to the cross-toolchain ROOT, so that all paths (INTERP,RUNPATH etc.) are correct. Look at the executeable to find it has a .gnu.hash section: objdump -h -j .gnu.hash /usr/x86_64-pc-linux-uclibc/dummy /usr/x86_64-pc-linux-uclibc/dummy: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn 1 .gnu.hash 00000034 0000000000400250 0000000000400250 00000250 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA look at the default uclibc config to find it has no gnu hash support activated: # LDSO_GNU_HASH_SUPPORT is not set (Holds true for both, uclibc created by crossdev as well as a uclibc cross-emerged/compiled with the cross-toolchain) I can confirm this issue for at least 4 different x86_64 platforms with different CPUs, different versions of uclibc tested over the last 12 (or so) months. (Same as for the other issues)
(In reply to Sven E. from comment #30) if the only thing you want is to turn on gnu hash by support, that's easy: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=192950b7031b42573f954f4a52800dcc4b143d22 otherwise this bug is a bit of a rambling mess that's not really possible to follow. if you have any other specific issues that haven't been covered, highlight them directly.
(In reply to SpanKY from comment #31) > (In reply to Sven E. from comment #30) > > if the only thing you want is to turn on gnu hash by support, that's easy: > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=192950b7031b42573f954f4a52800dcc4b143d22 > > otherwise this bug is a bit of a rambling mess that's not really possible to > follow. if you have any other specific issues that haven't been covered, > highlight them directly. Okay, I'll have to admit the bug is a little messy and cluttered up. No doubt. So, basicly I had a goal: x-emerge a basic system, no frills. I hit the LDSO issue and I really did not want to use +savedconfig. But it was the only way that worked, then more things came up and I gave in. Might not have been the best thing to do. Anyhow, personally I would not mind to not use gnu hashes, but as I wrote: Even when I force the linker to create sysv-hashes it will still not link (same error messages). Adding a linker flag could have avoided the need for +savedconfig on uclibc. And it's not like gnu hashes are necessarily the better choice, afaik sysv hashes are more compact and would be an alternative for a micro-libc. It just doesn't work. I don't know if the ldso issue is limited to 64-bit platforms, or to x86_64, I don't have a 64-bit arm (or any other cpu arch) at hand right now. So I added the option manually, and kept going whenever I got stuck again. So basically issues piled up (same for musl btw) and I wanted to keep going and started adding patches to a local overlay etc. . I wanted to collect all issues that are related to uclibc/crosdev setup directly, while handling the other ones separately (See 550958 as an example). It just seemed wrong to me, to create bug entries like a conveyor-belt. Probably a direct person to person interaction would be the most efficient way to sort out the vast amount of issues (for both uclibc and musl), that's why I wanted one entry covering al related things. Anyway, thanks for adding the option to the defaults. First step is taken ...
