I have been recompiling my system with -ggdb3 because I had some Krashes in Konqueror I wanted to investigate and then I found out about the splitdebug feature, which seems handy, and my last system recompile was with linux-headers-2.6.19.2-r2 and gcc-4.1.1-r3 so I thought I might be able to fix a few compile failures while I'm at it. Anyway, when I reached perl, it totally threw a hissyfit at me because linux-headers-2.6.20-r1 does not have asm/page.h. I thought it might be prudent to try without ggdb3, but that yielded the same result. Diagnostics: loki ~ # equery files linux-headers|grep -i page.h loki ~ # Build failure: i686-pc-linux-gnu-gcc -c -fno-strict-aliasing -pipe -Wdeclaration-after-statement -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -march=athlon-xp -pipe -DVERSION=\"1.04\" -DXS_VERSION=\"1.04\" -fPIC "-I../../.." SysV.c SysV.xs:7:25: error: asm/page.h: No such file or directory make[1]: *** [SysV.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/dev-lang/perl-5.8.8-r2/work/perl-5.8.8/ext/IPC/SysV' make: *** [lib/auto/IPC/SysV/SysV.so] Error 2 !!! ERROR: dev-lang/perl-5.8.8-r2 failed. Call stack: ebuild.sh, line 1614: Called dyn_compile ebuild.sh, line 971: Called qa_call 'src_compile' environment, line 3328: Called src_compile perl-5.8.8-r2.ebuild, line 273: Called die !!! Unable to make !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/dev-lang/perl-5.8.8-r2/temp/build.log'. Emerge --info and the build.log will be attached as files Reproducible: Always Steps to Reproduce: 1. emerge -e world, having upgraded to gcc-4.1.2 and linux-header-2.6.20-r1 2. wait 3. <boom> build failure 4. emerge --resume 5. <boom> build failure 6. ad nauseum
Created attachment 111180 [details] "/var/tmp/portage/dev-lang/perl-5.8.8-r2/temp/build.log"
Created attachment 111181 [details] emerge --info
Created attachment 111184 [details] My emrge --info output Same bug for me with same output when I try to emmerge -evat world .
I solved this bug by adding a symbolic link from /usr/src/linux/include/asm/page.h to /usr/include/asm/page.h with the following command : ln -s /usr/src/linux/include/asm/page.h /usr/include/asm and perl compile now perfectly.
(In reply to comment #4) > I solved this bug by adding a symbolic link from > /usr/src/linux/include/asm/page.h to /usr/include/asm/page.h with the following > command : > ln -s /usr/src/linux/include/asm/page.h /usr/include/asm > and perl compile now perfectly. > Yeah, that's a workaround. The underlying problem is not solved by that. From http://lkml.org/lkml/2007/1/4/20 <---vapier I understand that we really don't want to export asm/page.h to userspace (do we.. ?) so the real fix here is to get perl to compile without it. Or to re-add it to linux-headers so perl compiles. Added vapier CC.
I can confirm this issue and work-around. I should also note that this affects multiple ebuilds and can even cause problems with genkernel and busybox, making it very difficult to re-compile your kernel.
Patch available at: http://www.nntp.perl.org/group/perl.perl5.porters/2007/02/msg121370.html
Created attachment 111426 [details] perl-5.8.8-r2.ebuild please try this ebuild. File needed in the files/ dir: perl-5.8.8-asm-page-h-compile-failure.patch Compiles for me on ~x86.
Created attachment 111427 [details, diff] perl-5.8.8-asm-page-h-compile-failure.patch
however the perl guys want to get perl to build w/out asm/page.h is fine by me the proposed patch seems OK
(In reply to comment #9) > Created an attachment (id=111427) [edit] > perl-5.8.8-asm-page-h-compile-failure.patch > have you posted to this p5p? Mostly so it gets added to blead, or at least a definable reason why not to, can be addressed upstream. I can post it with credit if you aren't subscribed/interested, but I'd like to get feedback on how page.h was being utilized before whacking it completely.
the only thing ever came from asm/page.h is the PAGE_SIZE macro (well maybe one or two other PAGE_* defines as well, but no one uses those) using the PAGE_SIZE define is wrong anyways as the value may be dynamic at runtime so the preferred method is sysconf(_SC_PAGESIZE)
Missing page.h also breaks: sys-apps/util-linux-2.12r-r5 sys-block/nbd-2.9.2
(In reply to comment #13) > Missing page.h also breaks: > > sys-apps/util-linux-2.12r-r5 > sys-block/nbd-2.9.2 > bug #168278 sys-apps/util-linux-2.12r-r5 fails to compile against linux-headers-2.6.20-r1 Ebuild+patch provided. bug #168952 [PATCH] sys-block/nbd-2.9.2 fails to compile against linux-header-2.6.20-r1 Ebuild+patch provided.
*** Bug 168972 has been marked as a duplicate of this bug. ***
I hit this today with perl and busybox... On top of that, linux-headers-2.6.20-r1 does not have asm directory, it is split by arch... So the workaround is: ln -nfs /usr/src/linux/include/asm-i386/page.h /usr/include/asm (for my system anyway) BTW, busybox-1.4.1-r2 works without the workaround, while 1.2.2.1 (the stable) does NOT work.
*** Bug 168995 has been marked as a duplicate of this bug. ***
this bug is about perl only, dont post crap about other bugs
I think the reason you may be seeing users posting "crap" to this bug is that when a user sees an ebuild fail on page.h, and then subsequently goes to bugs.gentoo.org and searches for page.h, this is the only relevant bug that shows up. The user might have thought that this issue was previously only known to break perl and, in the interest of getting their problem solved as well as the overall stability of Gentoo, add information which that thought was relevant to this bug. Dismissing a user's input as "crap" might dissuade him/her from providing information in the future.
I have the same problem with xawtv. Why not (sym)linking the complete architecture specific asm directory to '/usr/include/asm'?
please forget my previous comment...
dev-db/myodbc-3.51.12 is affected too
please read the actual history here ... this bug report is only about perl
thanks .... the patch and ebuild are working fine here
Posted. Thanks Peter, ~mcummings
I've been encountering this problem with perl-5.8.8-r5 and linux-headers-2.6.23-r3 for a few months now. Is there something on the user end that needs to be done to resolve this?
