Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

[Konstantin Belousov]

On Wed, Jul 19, 2017 at 10:06:13PM -0400, Alexander Kabaev wrote:
> On Wed, 19 Jul 2017 22:50:04 +0200 (CEST)
> Gerald Pfeifer  wrote:
> 
> > On Fri, 14 Apr 2017, Alexander Kabaev wrote:
> > > it was suggested multiple times that the whole fixinc step is
> > > ultimately harmful and serves no useful purpose and probably should
> > > be disabled in built packages outright. Is there a reason not to do
> > > it? Even Redhat appears to do the slimming in their rpms:  
> > 
> > For the more current lang/gcc* ports (not the gcc5-aux and gcc6-aux 
> > ports which I do not maintain) I have now removed packaging the
> > headers processed by fixincludes, so any problems in that direction
> > should be gone.
> > 
> > Gerald
> 
> Thank you, Gerald!

This is very good news, thank you.  Gcc should be much more usable now.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

[Alexander Kabaev]

On Wed, 19 Jul 2017 22:50:04 +0200 (CEST)
Gerald Pfeifer  wrote:

> On Fri, 14 Apr 2017, Alexander Kabaev wrote:
> > it was suggested multiple times that the whole fixinc step is
> > ultimately harmful and serves no useful purpose and probably should
> > be disabled in built packages outright. Is there a reason not to do
> > it? Even Redhat appears to do the slimming in their rpms:  
> 
> For the more current lang/gcc* ports (not the gcc5-aux and gcc6-aux 
> ports which I do not maintain) I have now removed packaging the
> headers processed by fixincludes, so any problems in that direction
> should be gone.
> 
> Gerald

Thank you, Gerald!

-- 
Alexander Kabaev


pgpGWVxeaZmdj.pgp
Description: Цифровая подпись OpenPGP

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

[Gerald Pfeifer]

On Fri, 14 Apr 2017, Alexander Kabaev wrote:
> it was suggested multiple times that the whole fixinc step is
> ultimately harmful and serves no useful purpose and probably should be
> disabled in built packages outright. Is there a reason not to do it?
> Even Redhat appears to do the slimming in their rpms:

For the more current lang/gcc* ports (not the gcc5-aux and gcc6-aux 
ports which I do not maintain) I have now removed packaging the headers
processed by fixincludes, so any problems in that direction should be
gone.

Gerald
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) [amd64 system ld being lld vs. binutils based]

[Mark Millard]

On 2017-Apr-15, at 11:30 PM, Mark Millard  wrote:

> On 2017-Apr-15, at 2:30 AM, Mark Linimon  wrote:
> 
>> On Fri, Apr 14, 2017 at 08:27:29PM -0700, Mark Millard wrote:
>>> I've seen material quoted from a exp-run that reported
>>> that about 54(?) ports were then blocked by lang/gcc6-aux
>>> not building.
>> 
>> Although the first is an older run (the last complete run IIUC), there
>> were 50 and 51 respectively as of:
>> 
>> http://thunderx1.nyi.freebsd.org/build.html?mastername=110arm64-default=423029
>> http://beefy8.nyi.freebsd.org/build.html?mastername=head-armv6-default=p437390_s316341
>> 
>> I think you're fairly deep into unexplored territory here.
> 
> 
> Looks like it. I tried an amd64 context (that was built using
> WITH_LLD_IS_LD= in case that matters) and ports-mgmt/synth's
> indirect build of lang/gcc6-aux quickly stopped for:
> 
> configure:4439: 
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/bin/gcc -O2 -pipe  
> -g -fstack-protector -fno-strict-aliasing -I/usr/local/include  
> -L/usr/local/lib -fstack-protector conftest.c  >&5
> /usr/bin/ld: error: unable to find library -lssp_nonshared
> /usr/bin/ld: error: unable to find library -lc
> collect2: error: ld returned 1 exit status
> configure:4443: $? = 1
> configure:4480: result: 
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME ""
> | #define PACKAGE_TARNAME ""
> | #define PACKAGE_VERSION ""
> | #define PACKAGE_STRING ""
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL ""
> | /* end confdefs.h.  */
> | 
> | int
> | main ()
> | {
> | 
> |   ;
> |   return 0;
> | }
> configure:4486: error: in 
> `/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/build':
> configure:4490: error: C compiler cannot create executables
> 
> This happened even if I checked off in gcc6-aux's config
> to do a bootstrap.
> 
> Even amd64 has build problems (at least for use of the
> modern/experimental ld).

I reverted to an amd64 system based on WITHOUT_LLD_IS_LD= and
that avoided this issue: at least the build has gotten farther
and is still in progress.

It looks like the lang/gcc6-aux bootstrap/bin/gcc for amd64 is
using /usr/bin/ld in a way that is binutils specific at this
point.

===
Mark Millard
markmi at dsl-only.net

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

[Mark Linimon]

On Fri, Apr 14, 2017 at 08:27:29PM -0700, Mark Millard wrote:
> I've seen material quoted from a exp-run that reported
> that about 54(?) ports were then blocked by lang/gcc6-aux
> not building.

Although the first is an older run (the last complete run IIUC), there
were 50 and 51 respectively as of:

http://thunderx1.nyi.freebsd.org/build.html?mastername=110arm64-default=423029
http://beefy8.nyi.freebsd.org/build.html?mastername=head-armv6-default=p437390_s316341

I think you're fairly deep into unexplored territory here.

mcl
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

[Mark Millard]

On 2017-Apr-14, at 8:07 PM, Ngie Cooper (yaneurabeya)  wrote:

>   Is there a reason why you need ada support (that seems to be the only 
> real reason for installing gcc6 vs gcc6-aux)? gcc6-aux uses a snapshot of 
> gcc6 with custom options.
> Thanks!
> -Ngie

I got to lang/gcc6-aux indirectly:

I saw the ports checkin notice and github information
for ports-mgmt/synth indicating that native aarch64
support was now in place/possible.

When I looked at what pkg would provide it was older.

So on a Pine64+ 2GB [an aarch64 context] I did an
svnlite update for /usr/ports and then tried to build
ports-mgmt/synth .

Synth is written in ada and so indirectly then attempts
a lang/gcc6-aux build if it is not already in place.
[gcc5-aux likely would not support aarch64.]

I've no direct interest in lang/gcc6-aux or ada as
stands. But indirectly such is involved in what I
wanted to explore.

I've seen material quoted from a exp-run that reported
that about 54(?) ports were then blocked by lang/gcc6-aux
not building. (So some problems might not be aarch64
specific despite my example context: the "54" material
was likely not for an aarch64 context.)

===
Mark Millard
markmi at dsl-only.net

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

[Mark Millard]

On 2017-Apr-14, at 4:30 PM, Gerald Pfeifer  wrote:

> On Thu, 13 Apr 2017, Pedro Giffuni wrote:
>> I didn’t want to get into this but the problem is that as part of it's
>> build/bootstrapping process, GCC historically takes system headers
>> and attempts to “fix” them. I am unsure the fixes do anything at all
>> nowadays but the effect is that the compiler tends to take snapshots
>> of the system headers when it is built. cdefs.h is used by all the
>> system headers so changes in cdefs.h have good chances affecting
>> such builds but any change are likely to cause similar trouble.
>> 
>> In the case of gcc-aux, it appears the compilation is based on a
>> bootstrap compiler which already carries outdated headers.
>> A workaround, suggested by gerald@ the last time a similar issue
>> happened was to run for install-tools/fixinc.sh. I think that may
>> regenerate the headers and let the build use updated headers.
>> Ultimately gcc-aux needs maintainer intervention and using
>> outdated headers will break sooner or later: especially on -current.
> 
> Indeed, thanks for the analysis/background, Pedro!
> 
> I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6, 
> and perhaps John (as the maintainer of that port) has plans to update 
> it?  Let me copy him.

[As I have a prior E-mail exchange with John M. indicating that
he was not intending to be the lang/gcc6-aux maintainer, I
avoid spamming him with this material: I've removed him from
the CC list in this reply. I can send the material to him if I
see evidence of his wanting it.]

Just FYI:

[Previously: temporarily adding __nonnull and __nonnull_all
back into into my local head FreeBSD variant got problems
with: __vm_ooffset_t and __vm_pindex_t no longer existing and
also the same pid_t issue indicated below.]


I tried using [on a Pine64+ 2GB aarch64 system]:

# 
/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/libexec/gcc/aarch64-aux-freebsd12.0/6.3.1/install-tools/mkheaders
 /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap

to deal with __nonnull, __nonnull_all, __vm_ooffset_t, and __vm_pindex_t.

I then built via portmaster -CDK usage. Various header issues
did go away but the build of lang/gcc6-aux still stopped with:

In file included from 
/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:20:0:
./config.h:556:15: error: two or more data types in declaration specifiers
 #define pid_t int
   ^

I'm guessing that the define for pid_t in config.h resulted
in something like:

typedef ??? pid_t;

that turned into something like a:

typedef ??? int;

for the error listed above.

There were also implicit-declaration warnings:

/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:
 In function 'simple_object_internal_read':
/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:75:21:
 warning: implicit declaration of function 'read' 
[-Wimplicit-function-declaration]
   ssize_t got = read (descriptor, buffer, size);
 ^~~~
/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:
 In function 'simple_object_internal_write':
/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:119:23:
 warning: implicit declaration of function 'write' 
[-Wimplicit-function-declaration]
   ssize_t wrote = write (descriptor, buffer, size);
   ^

The implicit-declaration warnings for read and write may well
also not be expected/desirable.

It may be that more than a script run is needed to make
things be appropriate.

===
Mark Millard
markmi at dsl-only.net

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

[Alexander Kabaev]

On Sat, 15 Apr 2017 09:30:49 +1000 (AEST)
Gerald Pfeifer  wrote:

> On Thu, 13 Apr 2017, Pedro Giffuni wrote:
> > I didn't want to get into this but the problem is that as part of
> > it's build/bootstrapping process, GCC historically takes system
> > headers and attempts to "fix" them. I am unsure the fixes do
> > anything at all nowadays but the effect is that the compiler tends
> > to take snapshots of the system headers when it is built. cdefs.h
> > is used by all the system headers so changes in cdefs.h have good
> > chances affecting such builds but any change are likely to cause
> > similar trouble.
> > 
> > In the case of gcc-aux, it appears the compilation is based on a
> > bootstrap compiler which already carries outdated headers.
> > A workaround, suggested by gerald@ the last time a similar issue
> > happened was to run for install-tools/fixinc.sh. I think that may
> > regenerate the headers and let the build use updated headers.
> > Ultimately gcc-aux needs maintainer intervention and using
> > outdated headers will break sooner or later: especially on
> > -current.  
> 
> Indeed, thanks for the analysis/background, Pedro!
> 
> I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6, 
> and perhaps John (as the maintainer of that port) has plans to update 
> it?  Let me copy him.
> 
> Gerald
> 
> PS: John, if you have an update, happy to help and apply that for you.

Hi Gerald,

it was suggested multiple times that the whole fixinc step is
ultimately harmful and serves no useful purpose and probably should be
disabled in built packages outright. Is there a reason not to do it?
Even Redhat appears to do the slimming in their rpms:

mv $FULLPATH/include-fixed/syslimits.h $FULLPATH/include/syslimits.h
mv $FULLPATH/include-fixed/limits.h $FULLPATH/include/limits.h
for h in `find $FULLPATH/include -name \*.h`; do
  if grep -q 'It has been auto-edited by fixincludes from' $h; then
rh=`grep -A2 'It has been auto-edited by fixincludes from' $h |
tail -1 | sed 's|^.*"\(.*\)".*$|\1|'` diff -up $rh $h || :
rm -f $h
  fi
done

-- 
Alexander Kabaev


pgpG5jabvm7gZ.pgp
Description: Цифровая подпись OpenPGP

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

[Gerald Pfeifer]

On Thu, 13 Apr 2017, Pedro Giffuni wrote:
> I didn’t want to get into this but the problem is that as part of it's
> build/bootstrapping process, GCC historically takes system headers
> and attempts to “fix” them. I am unsure the fixes do anything at all
> nowadays but the effect is that the compiler tends to take snapshots
> of the system headers when it is built. cdefs.h is used by all the
> system headers so changes in cdefs.h have good chances affecting
> such builds but any change are likely to cause similar trouble.
> 
> In the case of gcc-aux, it appears the compilation is based on a
> bootstrap compiler which already carries outdated headers.
> A workaround, suggested by gerald@ the last time a similar issue
> happened was to run for install-tools/fixinc.sh. I think that may
> regenerate the headers and let the build use updated headers.
> Ultimately gcc-aux needs maintainer intervention and using
> outdated headers will break sooner or later: especially on -current.

Indeed, thanks for the analysis/background, Pedro!

I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6, 
and perhaps John (as the maintainer of that port) has plans to update 
it?  Let me copy him.

Gerald

PS: John, if you have an update, happy to help and apply that for you.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

[Pedro Giffuni]

> On Apr 13, 2017, at 20:38, Mark Millard  wrote:
> 
> [I accidentally sent the original of the "on . . . wrote"
> below to the wrong toolchain list. This just corrects that.]
> 
> [I'll also note that lang/gcc6-aux was indirectly attempted
> when I tried to build ports-mgmt/synth on a Pine64+ 2GB
> (an aarch64 context). I had noticed the recent update claiming
> native aarch64 support for synth and tried to build it. I've
> no direct interest in lang/gcc6-aux . I just ended up with
> FYI information about lang/gcc6-aux .]
> 

I didn’t want to get into this but the problem is that as part of it's
build/bootstrapping process, GCC historically takes system headers
and attempts to “fix” them. I am unsure the fixes do anything at all
nowadays but the effect is that the compiler tends to take snapshots
of the system headers when it is built. cdefs.h is used by all the
system headers so changes in cdefs.h have good chances affecting
such builds but any change are likely to cause similar trouble.

In the case of gcc-aux, it appears the compilation is based on a
bootstrap compiler which already carries outdated headers.
A workaround, suggested by gerald@ the last time a similar issue
happened was to run for install-tools/fixinc.sh. I think that may
regenerate the headers and let the build use updated headers.
Ultimately gcc-aux needs maintainer intervention and using
outdated headers will break sooner or later: especially on -current.

Hope that helps,

Pedro.



> ===
> Mark Millard
> markmi at dsl-only.net
> 
> (I've added a missing "n" in the first "__nonnull_all" below.)
> On 2017-Apr-13, at 6:04 PM, Mark Millard  wrote:
> 
>> As means of investigating if lang/gcc6-aux has other problems
>> building on aarch64 than just __nonnull and __nonnull_all I did:
>> 
>> # svnlite diff /usr/src/sys/sys/
>> Index: /usr/src/sys/sys/cdefs.h
>> ===
>> --- /usr/src/sys/sys/cdefs.h (revision 315914)
>> +++ /usr/src/sys/sys/cdefs.h (working copy)
>> @@ -376,6 +376,10 @@
>> #define  __noinline
>> #endif
>> 
>> +// HACK to enable older source that did not track.
>> +#define __nonnull(x)
>> +#define __nonnull_all
>> +
>> #if __GNUC_PREREQ__(3, 4)
>> #define  __fastcall  __attribute__((__fastcall__))
>> #define  __result_use_check  __attribute__((__warn_unused_result__))
>> 
>> and so such similarly shows up in /usr/include/sys/cdefs.h .
>> 
>> The attempt to build lang/gcc6-aux (as part of attempting
>> to build ports-mgmt/synth) resulted in:
>> 
>> 
>> In file included from 
>> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/fdmatch.c:45:0:
>> ./config.h:556:15: error: two or more data types in declaration specifiers
>> #define pid_t int
>>  ^
>> In file included from 
>> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/fdmatch.c:49:0:
>> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:266:9:
>>  error: unknown type name '__vm_ooffset_t'
>> typedef __vm_ooffset_t vm_ooffset_t;
>>^~
>> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:268:9:
>>  error: unknown type name '__vm_pindex_t'
>> typedef __vm_pindex_t vm_pindex_t;
>>^
>> gmake[4]: *** [Makefile:732: fdmatch.o] Error 1
>> gmake[4]: Leaving directory 
>> '/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/build/libiberty'
>> gmake[3]: *** [Makefile:7458: all-libiberty] Error 2
>> gmake[3]: *** Waiting for unfinished jobs
>> 
>> 
>> vm_ooffset_t and vm_pindex_t has 2017-Feb-4 changes:
>> 
>> Revision 313194 - (view) (download) (annotate) - [select for diffs] 
>> Modified Sat Feb 4 12:26:38 2017 UTC (2 months, 1 week ago) by kib 
>> File length: 10733 byte(s) 
>> Diff to previous 299571
>> 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.
>> 
>> Reviewed by: alc
>> Sponsored by:The FreeBSD Foundation
>> MFC after:   1 week
>> 
>> 
>> The "#define pid_t int" in the local:
>> 
>> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/build/libiberty/config.h
>> 
>> likely messes up some later "typedef . . . pid_t;", such as:
>> 
>> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:typedef
>>__pid_t pid_t;  /* process id */
>> 
>> resulting in:
>> 
>> typedef __pid_t int;
>> 
>> 
>> 
>> So lang/gcc6-aux bootstrapping has more problems than just __nonnull
>> and __nonnull_all issues, at least for aarch64 head.
>> 
>> lang/gcc6-aux might not be the only thing with such 

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

[Mark Millard]

[I accidentally sent the original of the "on . . . wrote"
below to the wrong toolchain list. This just corrects that.]

[I'll also note that lang/gcc6-aux was indirectly attempted
when I tried to build ports-mgmt/synth on a Pine64+ 2GB
(an aarch64 context). I had noticed the recent update claiming
native aarch64 support for synth and tried to build it. I've
no direct interest in lang/gcc6-aux . I just ended up with
FYI information about lang/gcc6-aux .]

===
Mark Millard
markmi at dsl-only.net

(I've added a missing "n" in the first "__nonnull_all" below.)
On 2017-Apr-13, at 6:04 PM, Mark Millard  wrote:

> As means of investigating if lang/gcc6-aux has other problems
> building on aarch64 than just __nonnull and __nonnull_all I did:
> 
> # svnlite diff /usr/src/sys/sys/
> Index: /usr/src/sys/sys/cdefs.h
> ===
> --- /usr/src/sys/sys/cdefs.h  (revision 315914)
> +++ /usr/src/sys/sys/cdefs.h  (working copy)
> @@ -376,6 +376,10 @@
> #define   __noinline
> #endif
> 
> +// HACK to enable older source that did not track.
> +#define __nonnull(x)
> +#define __nonnull_all
> +
> #if __GNUC_PREREQ__(3, 4)
> #define   __fastcall  __attribute__((__fastcall__))
> #define   __result_use_check  __attribute__((__warn_unused_result__))
> 
> and so such similarly shows up in /usr/include/sys/cdefs.h .
> 
> The attempt to build lang/gcc6-aux (as part of attempting
> to build ports-mgmt/synth) resulted in:
> 
> 
> In file included from 
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/fdmatch.c:45:0:
> ./config.h:556:15: error: two or more data types in declaration specifiers
> #define pid_t int
>   ^
> In file included from 
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/fdmatch.c:49:0:
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:266:9:
>  error: unknown type name '__vm_ooffset_t'
> typedef __vm_ooffset_t vm_ooffset_t;
> ^~
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:268:9:
>  error: unknown type name '__vm_pindex_t'
> typedef __vm_pindex_t vm_pindex_t;
> ^
> gmake[4]: *** [Makefile:732: fdmatch.o] Error 1
> gmake[4]: Leaving directory 
> '/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/build/libiberty'
> gmake[3]: *** [Makefile:7458: all-libiberty] Error 2
> gmake[3]: *** Waiting for unfinished jobs
> 
> 
> vm_ooffset_t and vm_pindex_t has 2017-Feb-4 changes:
> 
> Revision 313194 - (view) (download) (annotate) - [select for diffs] 
> Modified Sat Feb 4 12:26:38 2017 UTC (2 months, 1 week ago) by kib 
> File length: 10733 byte(s) 
> Diff to previous 299571
> 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.
> 
> Reviewed by:  alc
> Sponsored by: The FreeBSD Foundation
> MFC after:1 week
> 
> 
> The "#define pid_t int" in the local:
> 
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/build/libiberty/config.h
> 
> likely messes up some later "typedef . . . pid_t;", such as:
> 
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:typedef
>__pid_t pid_t;  /* process id */
> 
> resulting in:
> 
> typedef __pid_t int;
> 
> 
> 
> So lang/gcc6-aux bootstrapping has more problems than just __nonnull
> and __nonnull_all issues, at least for aarch64 head.
> 
> lang/gcc6-aux might not be the only thing with such issues.
> 
> 
> I stopped with this. There could be more issues for lang/gcc6-aux .

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"