Trying to update powerpc cross compiler to 4.3.4 from 4.1.2 fails during emerge with missing fenv.h, tested on x86 and amd64 and both fail in the same way. Reproducible: Always Steps to Reproduce: 1. crossdev -S --target powerpc-softfloat-linux-uclibc 2. 3. Actual Results: gcc failed :( decExcept.c:30:18: error: fenv.h: No such file or directory Expected Results: Successful install of cross compiler. To fix the problem copy /usr/include/fenv.h to /usr/powerpc-softfloat-linux-uclibc/usr/include/fenv.h This should be included with uclibc. powerpc-softfloat-linux-uclibc-gcc successfully builds and compiles binaries.
Created attachment 215568 [details] cross-powerpc-softfloat-linux-uclibc-info
Created attachment 215570 [details] cross-powerpc-softfloat-linux-uclibc-gcc-stage2
Created attachment 215573 [details] emerge info
use a newer uclibc that provides fenv.h
(In reply to comment #4) > use a newer uclibc that provides fenv.h > Sorry Spanky but this does not wash with me, this is supposed to be the stable build and I have not selected the uclibc to use other than stable and it doesn't work. crossdev -S --target powerpc-softfloat-linux-uclibc
(In reply to comment #5) > (In reply to comment #4) > > use a newer uclibc that provides fenv.h > > > > Sorry Spanky but this does not wash with me, this is supposed to be the stable > build and I have not selected the uclibc to use other than stable and it > doesn't work. Then you should file a bug to request a newer uClibc be marked stable for your platform/arch.
> Then you should file a bug to request a newer uClibc be marked stable for your > platform/arch. > Thanks Solar, Would it be wise to change this bug or link to it in some way?
Mark this one as a dep on the "new" one you file for the arch maintainers. imo it's time to move all the arches away from the .28 uClibc. But sadly it's not a clean upgrade path.
> Sorry Spanky but this does not wash with me, this is supposed to be the stable > build and I have not selected the uclibc to use other than stable and it > doesn't work. i really dont care. unless you're assisting in maintenance, no one else is, which means only the latest gets attention.
(In reply to comment #9) > > Sorry Spanky but this does not wash with me, this is supposed to be the stable > > build and I have not selected the uclibc to use other than stable and it > > doesn't work. > > i really dont care. unless you're assisting in maintenance, no one else is, > which means only the latest gets attention. Here's what Mike meant, translated into English: "Please send a patch, I'll be happy to commit it. Thanks in advance." Or, if you're young (and thus lucky) enough to understand Twittish: "plz2patch kthxbye" You'll note the lack of punctuation which is one of the major features of Twittish. Denis.
Sorry SpanKY, what I wrote earlier came across wrong. I happen to maintain with a colleague a collection of cross compilers including powerpc arm, x86 and x86_64, from a collection of x86 and x86_64 hosts. We will possibly be creating more cross compilers in the future depending on what CPU will be used in our next product. If we can be of use in the testing and maintenance of cross compilers please let me know how. The cross build platform to date has been good and is one of the main reasons we use gentoo. I was just expecting the stable build to work.
the stable build used to work until a newer version of gcc went stable. as Denis mentioned, we'll add patches, but generally when it comes to cross-compiling, i only have time to make sure unstable works (and some might say i dont even do that enough). the stable policy here has not changed -- it's been a pure trickle down effect. so we can either do Bug 289522 (and make sure outstanding regressions there are resolved), or someone can post a patch for me to merge.
I understand where you are coming from.. you only have so much time to get things working... I see uclibc-0.9.30.2 is out today to add to the fun!
Created attachment 222857 [details, diff] 64_all_uClibc-add-glibc-fenvh.patch adds the fenv.h header from glibc (this is identical to what they do in later versions uClibc) alters makefile to remove the installed header if no floating point environment is available. (is this c
Created attachment 222859 [details, diff] 65_all_uClibc-kernel-fsid-t.patch I guess some define mangling occurred with the newer stable gcc. This adds the new define as well as the older ones to prevent namespace collision.
(In reply to comment #9) > i really dont care. unless you're assisting in maintenance, no one else is, > which means only the latest gets attention. > Should be fixed with the above two patches. Builds for me, but only with USE="-iconv". That is probably an unrelated bug, but in either case the relevent output is: ... gcc -O2 -Wall -DCTYPE_PACKED=1 -DDO_WIDE_CHAR=1 -D__UCLIBC_GEN_LOCALE gen_wc8bi t.c -o gen_wc8bit gen_wc8bit.c: In function 'main': gen_wc8bit.c:462: warning: pointer targets in assignment differ in signedness gen_wc8bit.c:613: warning: pointer targets in assignment differ in signedness gen_wc8bit.c:351: warning: array subscript is above array bounds gen_wc8bit.c:410: warning: array subscript is above array bounds gen_wc8bit.c:476: warning: array subscript is above array bounds ... ishift 1 tshift 10 size 23636 ishift 2 tshift 10 size 23636 smallest = 6136 setting ishift 5 tshift 1 make: *** [wctables.h] Segmentation fault * ERROR: cross-i686-pc-linux-uclibc/uclibc-0.9.28.3-r9 failed: * make locales failed ... NOTES: * requires a new uClibc-0.9.28.3-patches-2.0.tar.bz2, and * alter uCibc-0.9.28.3-r8.ebuild or make a new uCibc-0.9.28.3-r9.ebuild: change PATCH_VER="1.9" to "2.0"
Just to clarify, my first solution was to use a newer uClibc, like SpanKY said, but there is likely some person (e.g. the person who reported this bug) who would like it to 'just work' with -S .
(In reply to comment #15) > Created an attachment (id=222859) [details] > 65_all_uClibc-kernel-fsid-t.patch Also thought that I should mention, the reason that this is necessary is because of: ... /usr/i686-pc-linux-uclibc/sys-include/asm/posix_types_32.h:43: error: conflicting types for ‘__kernel_fsid_t’ /usr/i686-pc-linux-uclibc/sys-include/bits/kernel_types.h:46: error: previous declaration of ‘__kernel_fsid_t’ was here make[2]: *** [unwind-dw2.o] Error 1 ...
