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: WITH_LLD_IS_LD vs default WITHOUT_SYSTEM_COMPILER: What are the reasons?

[Dimitry Andric]

On 14 Apr 2017, at 22:40, Mark Millard  wrote:
> 
> man src.conf (from -r315914 ) reports:
> 
> WITH_LLD_IS_LD
> Set to use LLVM's LLD as the system linker, instead of GNU
> binutils ld.
> 
> This is a default setting on arm64/aarch64.  When set, these
> options are also in effect:
> 
> WITHOUT_SYSTEM_COMPILER (unless WITH_SYSTEM_COMPILER is set
> explicitly)
> 
> I'm curious about:
> 
> A) Why there is a bias to avoid the system compiler?

These are just the defaults, detected by the script that generates
src.conf.5.  The setting of MK_SYSTEM_COMPILER is actually dependent on
the host, so it's technically incorrect to have src.conf.5 mention that
it is off by default.


> and by contrast:
> 
> B) What sort of context justifies explicitly setting
>   WITH_SYSTEM_COMPILER when WITH_LLD_IS_LD is in use?

The settings are mostly orthogonal.  MK_SYSTEM_COMPILER was created to
avoid building a bootstrap compiler, if the system (host) compiler is
new enough.

At some point you could also image a MK_SYSTEM_LINKER setting, which
would avoid building the bootstrap linker, if the system linker is new
enough.

-Dimitry



signature.asc
Description: Message signed with OpenPGP