GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition

[Gerald Pfeifer]

On Sat, 29 Apr 2017, Dimitry Andric wrote:
> This is because gcc's fixincludes process makes copies of certain system
> headers (in this case, /usr/include/sys/types.h) with slight
> modifications.  Then, it places the directory containing the modified
> headers at the front of the include search path.  So far so good.
> 
> Now, whenever sys/types.h is updated, as happened with the vm_ooffset_t
> change, the header in gcc's own preferred directory might not match the
> definitions which are expected, leading to compilation errors.

>> If the port/package is builts from scratch, does this trigger the 
>> problem?
> Yes, basically you need to rebuild all gcc ports from scratch, whenever
> you update any system header that matches gcc's list of files it wants
> to modify.

That, or run the fixinc.sh script in 
./libexec/gcc/$TARGETTRIPLET/$VERSION/install-tools/fixinc.sh.

The proposed patch would help with that, but still require a 
manual run, hence my original question.

On Sun, 30 Apr 2017, Konstantin Belousov wrote:
> Am I right that Jung-uk fix replaces vm_ooffset_t and vm_pindex_t with
> explicit int64_t and uint64_t use, as the course of action for gcc
> fixincludes step ?  If yes, I completely disagree.
> 
> The change blocks any future changes to the type that might occur in the
> base system, for the code compiled by gcc.  End result might be as bad
> as mismatched ABI, in the worst case.

Okay, thanks for your feedback.

> With all of the above, IMO most sane way to fix problems is to
> rename fixincludes directory to some name which is ignored by gcc,
> e.g. include-fixed -> include-fixed.saved. This can be done as
> post-installation step in the ports.

This is what I figured, too, and plan on giving a try.  It probably
warrants an -exp run to be on the safe side.

On Sun, 30 Apr 2017, Dimitry Andric wrote:
> I agree, it would be best to avoid storing any copies of system headers
> completely.
> 
> Maybe the port can have an option FIX_INCLUDES, which defaults to off?
> I am not sure if there is anybody that really wants these 'fixed'
> headers, though. :)

There are two infrastructure improvements for the (current) GCC ports 
(orthogonal to a few simpler things I've been simplifying today in
older ports) that I'd like to conclude first, otherwise there'll be 
too many balls in the air.

( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218475 is the
last hold-off on the first of them, in case anyone can give this
a try. ;-)

It is on my list to pursue directly afterwards, then.

(Luckily this only hits with most -CURRENT versions of FreeBSD and
older packages only.)

Gerald