Summary: | glibc 2.3.3_pre20040420 compile failure on reiser4: ./nss/nss.h: Permission denied | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ed Catmur <ed> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED UPSTREAM | ||
Severity: | major | CC: | joe, robmoss |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Patch to make EACCES non-fatal |
Description
Ed Catmur
2004-06-01 23:05:01 UTC
I've never seen this bug before, and looking at your error messages, I'm surprised that workaround works. I think what's going on is glibc is getting its paths screwed up. It looks like the compiler enters nss_nis/ and starts parsing nis-proto.c. In parsing that file, it needs to read nss.h in the include folder one level up (hence ../include/nss.h). Parsing that include, it needs to access another header, ./nss/nss.h. Now assuming this is from the point of view of the compiler sitting in nss_nis/ while calling that second nss.h file, it will indeed fail because nss_nis/nss is a file and not a directory, and the compiler should be looking for ../nss/nss.h (up one level, in the nss/ dir). Same goes for the other files gcc is looking for. I'm not sure if this error is a bug in reiserfs4, or a bug in glibc. You said this workaround came form the forums, which topic, and what filesystem is everyone in that topic running? I'm suspecting reiserfs4 having a minor quirk smply because of a slight bias and because it looks like make is getting confused. I've compiled this glibc on several systems of different archs, and never bumped into this before. http://forums.gentoo.org/viewtopic.php?t=108718&start=600#1093328 and above. The compiler is sitting in ${S}/nis so includes will be relative to that dir. (gcc does not enter directories, make does that.) The structure is: ${S}/ ${S}/include/nss.h ${S}/nss/nss.h ${S}/nis/ (compiler's wd) ${S}/nis/nss_nis/nis-service.c (source file) ${S}/nis/nss (ordinary file) From wd of the compiler, ${S}/include/nss.h is ../include/nss.h. ./nss/nss.h is indeed ${S}/nis/nss/nss.h (failed chdir) but the gcc line includes -I.. so on most filesystems ./nss/nss.h will try .././nss/nss.h i.e. ${S}/nss/nss.h which is correct. glibc is not at fault here. Behaviour of reiser4 is that every file is a directory. This allows various metadata, ACLs, mime types etc. to be implemented. However it causes problems of this sort. See the gstreamer bug 49081 (which I fixed). Confirmatory data: Removing -I. from the gcc command line allows successful compile. Moving the compilation to a reiser3 (reiserfs) filesystem allows successful compile. Moving the directory to a tmpfs/ramfs filesystem allows successful compile. More cases of this bug: http://linuxfromscratch.org/pipermail/lfs-hackers/2004-May/001096.html and others. Every instance of this bug I have found has been on a reiser4 filesystem. Just had a genius moment (yeah, they don't come too often). I was checking the gcc source to see how includes work and it seems to be concentrated in gcc/cppfiles.c (open_file(), find_file_in_dir(), _cpp_find_file() are the functions to look at). The reason the error is "Permission denied" is that gcc tries to open() nss/nss.h and as nss is 0644 we get a EACCES. Changing nss to 0755 changes the error to ENOENT which gcc knows how to recover from (moving on to the next directory in the include search path). On non-reiser4 fss the error is ENOENT in both cases. (confirmed experimentally.) And indeed, running chmod +x nss allows the compilation to proceed. This suggests that the ebuild should do that, rather than moving nss out of the way which is potentially destructive. --- /usr/portage/sys-libs/glibc/glibc-2.3.3_pre20040420.ebuild 2004-05-08 23:07:40.000000000 +0100 +++ /srv/gentoo/trees/forums.gentoo.org/sys-libs/glibc/glibc-2.3.3_pre20040420.ebuild 2004-06-01 03:43:00.991041326 +0100 @@ -532,8 +532,9 @@ src_compile() { ${myconf} || die einfo "Building GLIBC..." + chmod +x ${S}/nis/nss cd ${S}/buildhere make PARALLELMFLAGS="${MAKEOPTS}" || die # einfo "Doing GLIBC checks..." # make check } Further analysis and soon a patch: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15772 Once I have tested the patch I will split it off allowing this bug to be for the workaround. mr_bones_: please assign glibc/gcc bugs to toolchain@g.o Created attachment 32522 [details, diff]
Patch to make EACCES non-fatal
Upstreamed etc. Have some (initially sceptical) developer interest.
For #include <foo/bar.h>, causes a warning:
foo.c:1:27: warning: ./foo/bar.h: Permission denied
to be issued when foo is a non-readable directory or an ordinary file on a
reiser4 filesystem, but keeps searching for <foo/bar.h> in the include path.
since this seems to be a reiser4 bug please report this upstream Not a reiser 4 bug; this is a gcc bug with a glibc workaround. I reported it upstream at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15772 but the patch can be used here as well. the fix has been added to gcc 3.4.0-r6 *** Bug 54237 has been marked as a duplicate of this bug. *** |