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-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-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-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).

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

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Ngie Cooper (yaneurabeya)]

> On Apr 14, 2017, at 19:53, Mark Millard  wrote:
> 
> 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.

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

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-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"