The mmap() function of dietlibc-0.30-r2 (stable in portage) and -0.31 (bug #227429) will always fail with ENODEV in some circumstances. The mmap_test.c included with the lib could be used as a test case but it must be compiled with LargeFile support. The bug will not show up without LargeFile. So far I found this only on hppa, changing or removing CFLAGS doesn't make any difference. daniel_hozac of #vserver/OFTC (thanks for help) says other archs should be unaffected since parisc is the only one with different syscall functions. Tested so far, with bug: dietlibc-0.30-r1 gcc-4.1.1 HPPA dietlibc-0.30-r1 gcc-4.1.2 HPPA dietlibc-0.31 gcc-4.1.2 HPPA Tested so far, without bug: dietlibc-0.31 gcc-3.4.6 x86_64/hardenedtoolchain dietlibc-0.29-8 gcc-4.0? i386 (ubuntu 6.06.2 precompiled deb)
Created attachment 157255 [details] test case This is a quick script that'll use dietlibc's mmap_test.c to check for the issue.
dev-libs/dietlibc-0.32_pre20080829 still uncorrected
Created attachment 170570 [details, diff] patch to fix on HPPA
Created attachment 170572 [details] ebuild to apply the fix on HPPA only the included ebuild will apply the patch only when compiling on HPPA to fix the mmap() issue. Many thanks to Bertl of #vserver @ OFTC for providing the fix. The patch will probably mess up other archs so in the ebuild I only apply it when USE=hppa. Upstream (fefe.de) has already been informed of this but I think we'll have to fix the problem by ourselves for some time before a properly fixed dietlibc will come out.
vserver guys ? Anyone please to commit this simple fix ? Do you want me to commit it ? I'd really like to get this fixed on hppa. Thanks
i have merged the latest changes from upstream and the mmap patch into 0.32_pre20081116, please give it a try
dev-libs/dietlibc-0.32_pre20081116 compiles fine on HPPA with: CFLAGS="-pipe -O2 -march=2.0" MAKEOPTS="-j3" glibc-2.7-r2 both gcc-4.2.4 and gcc-4.3.2 the mmap() issue of this bug is solved as proved by the attached test case. it still suffers bug #221961 as example of a working application, after putting in place the workaround for #221961 (symlink) sys-cluster/util-vserver will compile and run fine. please note that if you used the patch I included in this report, it'll probably mess up other archs, so you'll need to test it on non-hppa systems to be sure. that's why I conditionally included the patch from the ebuild only on hppa. thanks.
(In reply to comment #7) > please note that if you used the patch I included in this report, it'll > probably mess up other archs, so you'll need to test it on non-hppa systems to > be sure. that's why I conditionally included the patch from the ebuild only on > hppa. i added #ifdef __hppa__ around the syscall, so it only applies for hppa