On multilib-enabled amd64-gentoo-linux, alt/prefix does not work (yet) because gcc "fixes" system headers - specifically because of adding the include-guard. Unlike main gentoo, I don't want to remove the fixed headers at all, because I don't know if 'x86_64-unknown-linux-gnu' is gentoo/redhat/whatever. There are two fixes applied by gcc to stdio.h fex, where the (__need___va_list+stdarg.h) does not harm, but the include-guard (FIXINC_WRAP_STDIO_H_STDIO_STDARG_H) does, because any subsequent include using that '__need_*' construct fails. That include-guard is only added if there is no '#if.*__need_' found. The "fixed" stdio.h looks like this: ----------------------------------------------------------- /* DO NOT EDIT THIS FILE. It has been auto-edited by fixincludes from: "/usr/include/stdio.h" This had to be done to correct non-standard usages in the original, manufacturer supplied header file. */ #ifndef FIXINC_WRAP_STDIO_H_STDIO_STDARG_H #define FIXINC_WRAP_STDIO_H_STDIO_STDARG_H 1 #define __need___va_list #include <stdarg.h> /* Autogenerated by create_ml_includes() in multilib.eclass */ #ifdef __i386__ # include <gentoo-multilib/x86/stdio.h> #endif /* __i386__ */ #ifdef __x86_64__ # include <gentoo-multilib/amd64/stdio.h> #endif /* __x86_64__ */ #endif /* FIXINC_WRAP_STDIO_H_STDIO_STDARG_H */ ----------------------------------------------------------- There exists a patch[1] already to not add the include-guard at all, but I fear this is the "wrong" way to "fix" this - thus CC'd toolchain. [1] http://prefix-launcher.svn.sourceforge.net/viewvc/prefix-launcher/prefix-launcher/trunk/gcc/patches/include-guard.patch?revision=6&view=markup Thing is, as of sys-libs/glibc-2.6.1, there is no difference between amd64/stdio.h and x86/stdio.h at all. And for the files having a difference, it seems the amd64 version supports both x86_64 and !x86_64, specifically seen in <sys/user.h> using <bits/wordsize.h> fex. One thought has been to do that multilib include-file generation differently: Instead of adding '#include <gentoo-multilib/*/file.h>', just put <gentoo-multilib/*/file.h> between same ifdef's into /usr/include/file.h
please explain your reasoning for not deleting the fixed headers. they are bad things to package on a system like Gentoo and cause problems. i dont understand why you would keep them.
The reason to keep fixed headers is more of administrative than technical nature currently: On non-Linux, one must not remove those fixed headers, as the vendor ones really are "broken" in combination with gcc. Thus I trust gcc-dev's to have some reasons to "fix" system headers even on Linux. Did not have access to (somewhat) ancient Linux machine shipping gcc-3.x (or using uClibc) to test if gcc-4.2.2 (currently used in alt/prefix) will work with gcc-3.x compatible header files (yet). This might be a technical reason to keep fixed headers. The administrative reason simply is to avoid the need to distinguish between platforms when removing fixed headers - although this is easy to change: - [[ ${EPREFIX} == "" ]] + [[ ${CTARGET} == *-linux* ]] Or should this better be glibc only ? + [[ ${CTARGET} == *-linux-gnu ]]
the technical fix is two fold in the common Gentoo world: - the headers *arent* broken - packages get updated, gcc does not, so the fixed headers quickly become stale and cause hard to trace build failures there's no way we want to go back to that scenario ... if a package's headers are actually broken, the answer is to fix that package, not let gcc mask it i dont know how much freedom you have with alt/prefix in that regard however
(In reply to comment #3) > the technical fix is two fold in the common Gentoo world: yes, in "main Gentoo" we have control over system header files... > i dont know how much freedom you have with alt/prefix in that regard however We do not have control over system header files at all in prefix. Additionally, as most of the target machines are non-gentoo-linux (or even non-linux), system header files should not change that often - especially on non-whatever-linux. Eventually we need some "plugin" for revdep-rebuild (if it supports plugins) or sth. like that in prefix to check if gcc's fixed headers are out of date compared to the system ones...
it isnt a "linux" issue, it's an issue whether we have control over all the headers in the system. so stop thinking in terms of disabling this only for linux as that'll break bsd systems. or hurd systems. or any other system where portage isnt acting as a user-specific package. i assume you say "system" you mean "headers that you do not have access to modifying" as gcc will scan every header it can possibly find and create its own fixed version.
(In reply to comment #5) > it isnt a "linux" issue, it's an issue whether we have control over all the > headers in the system. so stop thinking in terms of disabling this only for > linux as that'll break bsd systems. or hurd systems. or any other system > where portage isnt acting as a user-specific package. Yes, this is why $EPREFIX (and not $CTARGET) currently is tested in prefix overlay to check whether to remove fixed headers. > i assume you say "system" you mean "headers that you do not have access to > modifying" as gcc will scan every header it can possibly find and create its > own fixed version. Exactly. I'm just trying to find a good way to avoid ending up with broken headers when gcc "fixes" gentoo-"system"-headers, while it is required for other "system's" headers.
Maybe this completely sucks, but anyway... I assume that all packages we install have "sane" headers (and otherwise we can patch them). Additionally, I believe GCC's fixincludes only scans /usr/include/*, not the prefix offset usr/include dirs. Non-prefix has fully controllable headers, and hence sane onces. Maybe we can extend gcc-config in such a way that fix-include shipped with that GCC is run once you switch the compiler or something? Probably doesn't make much sense, and we rather have some utility/switch to force regeneration basically for those cases where that seems to be necessary. However, in my experience, this is only necessary when the host OS is upgraded in such a way that the headers change, and that this harms. We can't really cater for that, but it hasn't been a problem in the past either. a) updates to those files are really really rare IMO, since most systems we're on need to be stable in that regard (I only know one change in the Solaris 10 system headers, but that was between different releases of the OS, looks like smpatch doesn't update that) b) once it happens, it may go unnoticed, and the next release of GCC (which is reasonably frequent these days) will fix it anyway. Side note: binary packages should *not* include the fix-include headers, they should be regenerated on the target system, I think.
(In reply to comment #7) > Additionally, I believe GCC's fixincludes only scans > /usr/include/*, not the prefix offset usr/include dirs. Exactly. > Maybe we can > extend gcc-config in such a way that fix-include shipped with that GCC is run > once you switch the compiler or something? Have thought on that too. > Side note: binary packages should *not* include the fix-include headers, they > should be regenerated on the target system, I think. If gcc-config recreates the fixed headers in prefix, we can remove it in the ebuild/eclass unconditionally, so they won't appear in binary gcc package. Although this would be nice, it won't fix the original issue that "fixing" "system"-headers on multilib amd64-gentoo "system's" will create broken headers. As this is not just an issue for prefix, but any user who wants to build its own gcc on some amd64-multilib-gentoo. So eventually we should submit an upstream gcc patch to let gcc know it must not fix headers containing "gentoo-multilib" or the like.
Until we know how the "correct fix" should look like, I've added a gcc patch in prefix overlay to be able continue on multilib-gentoo: http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/sys-devel/gcc/files/4.2.2/gentoo-fixincludes.patch?rev=14009
GCC says this isn't their problem: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915 To quote: "Why does gentoo do this kind of crap with glibc headers? They are already multilib clean." And they're right: as mentioned in the comments, the two versions are identical. So why does Gentoo do this?
as of glibc-2.7-r2 we don't generate multilib headers. see bug #191088.
Fine with me, although I cannot test any more ATM. *** This bug has been marked as a duplicate of bug 191088 ***
