Mark Millard
2017-Jun-25 00:55 UTC
lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work
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
Patrick Powell
2017-Jun-26 14:00 UTC
lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work
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-ports at freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org" >-- Patrick Powell Astart Technologies papowell at 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
Mark Millard
2017-Jun-26 19:05 UTC
lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work
Top post on one point. . . Patrick Powell papowell at astart.com wrote on Mon Jun 26 14:10:44 UTC 2017 (He was quoting Gerald. I was also part of some earlier discussions.)> (Luckily this only hits with most -CURRENT versions of FreeBSD and > older packages only.) > > GeraldUnfortunately this part is false if it is about the vm_ooffset_t and vm_pindex_t issue: stable/11/ and release/11.1.0/ also have the vm_ooffset_t and vm_pindex_t issue vs. lang/gcc* packages built by release/11.0.1/ . The issue is not limited to head (12) at this point: Installing a gcc* package built by release/11.0.1/ fails now for stable/11/ and the drafs oft release/11.1.0/ . Anyone progressing to one of those has to build the lang/gcc* of interest from source under the newer system context. (Mixing source builds and package builds is discouraged as I understand.) I'm not claiming which specific handling needs to be made. But the vm_ooffset_t and vm_pindex_t changes did not even make the UPDATING notes. Right now things look to have the worst combination for lang/gcc* when release/11.1.0/ becomes official: lang/gcc* 's break without notification or suggestion of a workaround. ==Mark Millard markmi at dsl-only.net On 2017-Jun-24, at 5:55 PM, Mark Millard <markmi at dsl-only.net> 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-toolchain at freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe at freebsd.org"