Bugzilla Bug 201490

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 ***