Created attachment 436742 [details] build.log quote from the build log POSIX.xs: In function 'my_fegetround': POSIX.xs:992:18: error: 'FE_TOWARDZERO' undeclared (first use in this function) case 0: return FE_TOWARDZERO; ^ POSIX.xs:992:18: note: each undeclared identifier is reported only once for each function it appears in POSIX.xs:994:18: error: 'FE_UPWARD' undeclared (first use in this function) case 2: return FE_UPWARD; ^ POSIX.xs:995:18: error: 'FE_DOWNWARD' undeclared (first use in this function) case 3: return FE_DOWNWARD; It seems as if uclibc does not provide fenv.h, therefore the build fails. I can confirm this bug for arm, but I have not tested any other arch. 5.22.2 is not yet stable on x86/amd64 anyway, so it won't break stages, won't it?
Created attachment 436744 [details] output of emerge --info
Created attachment 436746 [details, diff] proposed patch Compilation is fixed by commenting out this section. There may be some more convenient solution though.
You need to turn on the option UCLIBC_HAS_FENV=y. If you have that on and its still failing, then reopen this bug.
Created attachment 436750 [details] uclibc config cat /etc/portage/savedconfig/uclibc/uclibc-0.9.33.2-r15 | grep FENV UCLIBC_HAS_FENV=y I'm using the savedconfig useflag for uclibc, hence fenv.h is activated.
(In reply to tt_1 from comment #4) > Created attachment 436750 [details] > uclibc config > > cat /etc/portage/savedconfig/uclibc/uclibc-0.9.33.2-r15 | grep FENV > UCLIBC_HAS_FENV=y > > I'm using the savedconfig useflag for uclibc, hence fenv.h is activated. comment #0 says "uclibc does not provide fenv.h", so i assumed you had it off. can you give me the results to `find /usr/include -iname fenv.h`. if you find fenv.h, then can you test the following program. you need to compile it with gcc -o test test.c -lm #include <stdio.h> #include <fenv.h> int main() { int m, c, f; double d = 2.0; printf("Enter an int. >10 will overflow: "); scanf("%d", &m); if (m < 0) perror("int not positive."); for (c = 0; c < m; c++) d *= d; //printf("%lf\n", d); f = fetestexcept(FE_OVERFLOW); if (f & FE_OVERFLOW) printf("Got overflow\n"); else printf("No overflow\n"); }
(In reply to Anthony Basile from comment #5) > perror("int not positive."); stupid minor error. i meant to use errx(0, "int not positive."); there since perror() doesn't exit.
Well, I guessed that uclibc doesn't provide fenv.h as to me the error seemed to be about the lack of it. However, it is present: user ~ $ find /usr/include -iname fenv.h /usr/include/fenv.h /usr/include/bits/fenv.h the testcase you posted fails on armv7a-hardfp-uclibc with the following error /tmp/ccoYxz9l.o: In function `main': test.c:(.text+0xa0): undefined reference to `fetestexcept' collect2: error: ld returned 1 exit status
(In reply to tt_1 from comment #7) > Well, I guessed that uclibc doesn't provide fenv.h as to me the error seemed > to be about the lack of it. However, it is present: > > user ~ $ find /usr/include -iname fenv.h > /usr/include/fenv.h > /usr/include/bits/fenv.h > > the testcase you posted fails on armv7a-hardfp-uclibc with the following > error > > > /tmp/ccoYxz9l.o: In function `main': > test.c:(.text+0xa0): undefined reference to `fetestexcept' > collect2: error: ld returned 1 exit status I've confirmed that uclibc-0.9.33.2-r15 is not supplying any of the fenv functions. you can check with `readelf -sW /lib/libm.so.0` I need to check -9999 and uclibc-ng.
(In reply to Anthony Basile from comment #8) > I've confirmed that uclibc-0.9.33.2-r15 is not supplying any of the fenv > functions. you can check with `readelf -sW /lib/libm.so.0` I need to check > -9999 and uclibc-ng. No version of uclibc{,-ng} provides the floating point exception functions protoyped in fenv.h. However, this seems to cause a problem only for perl >5.22.0 on arm. I had no problem building perl on amd64. So I cc-ed the perl team to inform them. I'm looking now to see what's going on with perl on arm.
(In reply to Anthony Basile from comment #9) > (In reply to Anthony Basile from comment #8) > > > I've confirmed that uclibc-0.9.33.2-r15 is not supplying any of the fenv > > functions. you can check with `readelf -sW /lib/libm.so.0` I need to check > > -9999 and uclibc-ng. > > No version of uclibc{,-ng} provides the floating point exception functions > protoyped in fenv.h. However, this seems to cause a problem only for perl > >5.22.0 on arm. I had no problem building perl on amd64. So I cc-ed the > perl team to inform them. > > I'm looking now to see what's going on with perl on arm. I found the issue. <bits/fenv.h> on arm guards the enums and defines with "#ifdef __MAVERICK__" It doesn't on amd64 nor x86. You should be able to build perl 5.22.2 as follows # echo "dev-lang/perl perl.conf" >> /etc/portage/package.env # mkdir -p /etc/portage/env # echo "CPPFLAGS=-D__MAVERICK__" >> /etc/portage/env/perl.conf # emerge perl can you verify.
(In reply to Anthony Basile from comment #10) > # echo "CPPFLAGS=-D__MAVERICK__" >> /etc/portage/env/perl.conf looks like perl's build system doesn't respect CPPFLAGS. i tested and the following works with CFLAGS, so replace this line with # echo "CFLAGS=-D__MAVERICK__" >> /etc/portage/env/perl.conf
I can confirm that this workaround is fixing the compile issue, on armv7a profile.
Right now I have no clue how to 1) either upstream this (preferable) or 2) add it to an ebuild... please advise!
(In reply to Andreas K. Hüttel from comment #13) > Right now I have no clue how to 1) either upstream this (preferable) or 2) > add it to an ebuild... please advise! We've moved past uclibc to uclibc-ng. I don't have my arm system up right now, but it may be the case that this is no longer needed. Check <bits/fenv.h> and see if __MAVERICK__ is still present. If it is, then I'll upstream the fix to uclibc-ng. If it isn't then I'll close this bug WONTFIX because uclibc is dead. @dilfridge, don't add anything to an ebuild as this is way too hacky to polute our ebuilds. The fix, if needed, must go into uclibc-ng.
sys-libs/uclibc has been removed from the tree, replaced by sys-libs/uclibc-ng. if this is still a problem on uclibc-ng, please open a new bug.
Sorry this should be kept open. (In reply to Anthony Basile from comment #15) > sys-libs/uclibc has been removed from the tree, replaced by > sys-libs/uclibc-ng. if this is still a problem on uclibc-ng, please open a > new bug.
I think it was dev-lang/perl failing due to this, and that you fixed it by adding a certain cflag to it which disabled the use of fenv.h, wasn't it?
(In reply to tt_1 from comment #17) > I think it was dev-lang/perl failing due to this, and that you fixed it by > adding a certain cflag to it which disabled the use of fenv.h, wasn't it? Correct, but the fix hasn't gone into uclibc-ng yet. (Busy with real life) If you like you can try to upstream it. Just reference this bug.
I may send it to upstream in your name, but for that I need the patch and their bugtracker, mailinglist, or whatever they are using for handing in patches.
