I have reported this problem - see email to freebsd-stable
Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition
Here is part of the discussion:
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
On 06/24/17 17:55, Mark Millard wrote:
The following is based mostly on an extraction from a
private exchange in which a question was asked and my
answer was unsettling: incompatibilities within the
11.* family. I would not normally send to re but doing
so was explicitly mentioned. Hopefully this example is
reasonable for doing that.
Aspect #0: what is broken currently (and in the future?)
within the 11.* family?
lang/gcc* packages built on release/11.0.1/ to not work
fully on stable/11/ or on the drafts of
release/11.1.0/ . (I leave releng/11.*/'s implicit.)
-r313194 in head and was describied with:
Define the vm_ooffset_t and vm_pindex_t types as machine-independend.
The types are for the byte offset and page index in vm object. They
are similar to off_t, which is defined as 64bit MI integer. Using MI
definitions will allow to provide consistent MD values of vm
object-related maximum sizes.
The known issue is the generation of header dependencies
in the lang/gcc* builds on release/11.0.1/ that when
used on stable/11/ or release/11.0.1/ generate reports
like:
/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys/types.h:266:9:
error: '__vm_ooffset_t' does not name a type
typedef __vm_ooffset_t vm_ooffset_t;
^
/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys/types.h:268:9:
error: '__vm_pindex_t' does not name a type
typedef __vm_pindex_t vm_pindex_t;
^
*** [CoinFactorization2.lo] Error code 1
Unfortunately UPDATING was not updated
for head/'s -r313194 (2017-Feb-4) --nor for
stable/11/'s -r313574 (2017-Feb-11), the MFC.
(No MFC was made to stable/10/ or to
release/10.3.0 as far as I found.)
(These changes predate the INO64 issue in head/ .
Head ends up with more issues than I'm dealing
with here.)
Aspect #1: what 11.* version builds the pre-built packages
targeting 11.* and the apparent consequences
(given the vm_ooffset_t and vm_pindex_t changes
and the lang/gcc* build behavior)
This is the unsettling part for pre-built
packages: incompatibilities within the 11.*
family for the lang/gcc* packages.
http://portsmon.freebsd.org/portoverview.py?category=%3Bamng&portname=gcc5&wildcard=
shows categories for builds for
8.4
9.3
10.1
10.3
11.0
head
(Nothing for stable/*/ .)
But the 10.3 rows show no package
builds. I would guess that they
start once 10.1 stops
(approximately).
So it may be that 11.1 will not
get package builds until 11.0
stops (approximately).
If so unless lang/gcc* are changed
to bootstrap differently they will
configure to match release/11.0.1/
and will not be compatible with the
vm_ooffset_t and vm_pindex_t changes
in stable/11/ and release/11.1.0/ .
But as I understand updating how the
lang/gcc* builds work to remove such
dependencies is under investigation.
I do not know any timing relative to
release/11.1.0/ if my understanding
is right.
Until then (if I was right):
Unless there are separate packages made for
targeting release/11.0.1/ vs. release/11.1.0/
it is not obvious when lang/gcc* packages
will be generally compatible with various
folks choices about what to install as the
system version within the release/11.*/
and stable/11/ family. This would likely
be true even if they were built on
release/11.1.0/ : then release/11.0.1/
likely would have compatibility problems.
The ABI versioning does not cover the specific
issues involved based on how vm_ooffset_t and
vm_pindex_t were changed and what the
lang/gcc* builds do relative to such changes.
Yet there is incompatibility for some
fairly-significant-usage ports.
Aspect #2: stable/10/ and release/10.4.0/
Just covered for completeness:
I do not see a MFC of -r313194 to stable/10/ :
its sys/sys/types.h dates back to 2015-Oct-10.
So it looks like 10.x has a permanent difference
in this area: 10.x continues to get separate
lang/gcc* package builds from 11.x and later.
No problem for this context as far as I know.
Note: To simplify I choose to not be explicit
about what authors wrote what original text.
If that becomes an issue, it is correctable.
Blame me for any errors in the above.
===
Mark Millard
markmi at dsl-only.net
_______________________________________________
freebsd-po...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
--
Patrick Powell Astart Technologies
papow...@astart.com 1530 Jamacha Rd, Suite X
Network and System San Diego, CA 92019
Consulting Cell 858-518-7581 FAX 858-751-2435
Web: papowell at astart dot com
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
