lang/gcc fails on -current

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

lang/gcc fails on -current

Mark Patruck
Hi,

lang/gcc always fails with the following error on amd64 -current (~6 hours old)

------------------------
Check for missing set procedures in body
     OK

All tests completed successfully, no errors detected

raised ADA.IO_EXCEPTIONS.USE_ERROR : sinfo.h: No such file or directory
gmake[3]: *** [/tmp/pobj/gcc-8.3.0/gcc-8.3.0/gcc/ada/Make-generated.in:45: ada/s
info.h] Error 1
gmake[3]: *** Waiting for unfinished jobs....

raised ADA.IO_EXCEPTIONS.USE_ERROR : treeprs.ads: No such file or directory
gmake[3]: *** [/tmp/pobj/gcc-8.3.0/gcc-8.3.0/gcc/ada/Make-generated.in:31: ada/treeprs.ads] Error 1

raised ADA.IO_EXCEPTIONS.USE_ERROR : System.File_IO.Open: reopening shared file
gmake[3]: *** [/tmp/pobj/gcc-8.3.0/gcc-8.3.0/gcc/ada/Make-generated.in:53: ada/stamp-snames] Error 1
/bin/sh /tmp/pobj/gcc-8.3.0/gcc-8.3.0/gcc/../move-if-change tmp-optionlist optionlist
echo timestamp > s-options
gmake[3]: Leaving directory '/tmp/pobj/gcc-8.3.0/build-amd64/gcc'
gmake[2]: *** [Makefile:4609: all-stage1-gcc] Error 2
gmake[2]: Leaving directory '/tmp/pobj/gcc-8.3.0/build-amd64'
gmake[1]: *** [Makefile:21749: stage1-bubble] Error 2
gmake[1]: Leaving directory '/tmp/pobj/gcc-8.3.0/build-amd64'
gmake: *** [Makefile:21886: bootstrap2] Error 2
*** Error 2 in lang/gcc/8 (/usr/ports/infrastructure/mk/bsd.port.mk:2781 '/tmp/pobj/gcc-8.3.0/build-amd64/.build_done')
*** Error 1 in lang/gcc/8 (/usr/ports/infrastructure/mk/bsd.port.mk:2447 'build')
===> Exiting lang/gcc/8,,-libs with an error
*** Error 1 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:137 'build')
--------------------------

Anyone else seeing this?

--
Mark Patruck ( mark at wrapped.cx )
GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74  F644 0D3C F66F F286 5E51

http://www.wrapped.cx

Reply | Threaded
Open this post in threaded view
|

Re: lang/gcc fails on -current

Nigel Taylor-2
On 18/07/2019 19:10, Mark Patruck wrote:

> Hi,
>
> lang/gcc always fails with the following error on amd64 -current (~6 hours old)
>
> ------------------------
> Check for missing set procedures in body
>      OK
>
> All tests completed successfully, no errors detected
>
> raised ADA.IO_EXCEPTIONS.USE_ERROR : sinfo.h: No such file or directory
> gmake[3]: *** [/tmp/pobj/gcc-8.3.0/gcc-8.3.0/gcc/ada/Make-generated.in:45: ada/s
> info.h] Error 1
> gmake[3]: *** Waiting for unfinished jobs....
>
> raised ADA.IO_EXCEPTIONS.USE_ERROR : treeprs.ads: No such file or directory
> gmake[3]: *** [/tmp/pobj/gcc-8.3.0/gcc-8.3.0/gcc/ada/Make-generated.in:31: ada/treeprs.ads] Error 1
>
> raised ADA.IO_EXCEPTIONS.USE_ERROR : System.File_IO.Open: reopening shared file
> gmake[3]: *** [/tmp/pobj/gcc-8.3.0/gcc-8.3.0/gcc/ada/Make-generated.in:53: ada/stamp-snames] Error 1
> /bin/sh /tmp/pobj/gcc-8.3.0/gcc-8.3.0/gcc/../move-if-change tmp-optionlist optionlist
> echo timestamp > s-options
> gmake[3]: Leaving directory '/tmp/pobj/gcc-8.3.0/build-amd64/gcc'
> gmake[2]: *** [Makefile:4609: all-stage1-gcc] Error 2
> gmake[2]: Leaving directory '/tmp/pobj/gcc-8.3.0/build-amd64'
> gmake[1]: *** [Makefile:21749: stage1-bubble] Error 2
> gmake[1]: Leaving directory '/tmp/pobj/gcc-8.3.0/build-amd64'
> gmake: *** [Makefile:21886: bootstrap2] Error 2
> *** Error 2 in lang/gcc/8 (/usr/ports/infrastructure/mk/bsd.port.mk:2781 '/tmp/pobj/gcc-8.3.0/build-amd64/.build_done')
> *** Error 1 in lang/gcc/8 (/usr/ports/infrastructure/mk/bsd.port.mk:2447 'build')
> ===> Exiting lang/gcc/8,,-libs with an error
> *** Error 1 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:137 'build')
> --------------------------
>
> Anyone else seeing this?
>
Yes I see this, as a work around I built no_ada flavor. Just means I've
got no ada, and other things can be built.

I can get past the sinfo.h error, treeprs.ads and osnames errors, but
there are more afterwards. Too many errors to fix by hand.

The problem I think lies in opening files for writing when they don't
exist, it fails to create an empty file. So I manually touch sinfo.h to
create the empty file. Same for other missing files.

Add env FLAVOR=no_ada to the make or if using dpb lang/gcc/8,no_ada


Not sure where the error is could be with the ada bootstrap file, needs
regenerating.

Reply | Threaded
Open this post in threaded view
|

Re: lang/gcc fails on -current

Pavel Korovin-2
On 07/20, Nigel Taylor wrote:

> I can get past the sinfo.h error, treeprs.ads and osnames errors, but
> there are more afterwards. Too many errors to fix by hand.
>
> The problem I think lies in opening files for writing when they don't
> exist, it fails to create an empty file. So I manually touch sinfo.h to
> create the empty file. Same for other missing files.
>
> Add env FLAVOR=no_ada to the make or if using dpb lang/gcc/8,no_ada
>
>
> Not sure where the error is could be with the ada bootstrap file, needs
> regenerating.
The same problem here, please find the diff for gcc8 attached.

--
With best regards,
Pavel Korovin

gcc8.diff (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: lang/gcc fails on -current

Nigel Taylor-2
On 22/07/2019 06:36, Pavel Korovin wrote:

> On 07/20, Nigel Taylor wrote:
>> I can get past the sinfo.h error, treeprs.ads and osnames errors, but
>> there are more afterwards. Too many errors to fix by hand.
>>
>> The problem I think lies in opening files for writing when they don't
>> exist, it fails to create an empty file. So I manually touch sinfo.h to
>> create the empty file. Same for other missing files.
>>
>> Add env FLAVOR=no_ada to the make or if using dpb lang/gcc/8,no_ada
>>
>>
>> Not sure where the error is could be with the ada bootstrap file, needs
>> regenerating.
>
> The same problem here, please find the diff for gcc8 attached.
>
I've done much the same already, but the resulting gnat package is
broken. The diff gets around the problem of building, but not the fact
the runtime produced is then broken.

That is the ada Create fails to work when the file is missing

sinfo/xsinfo.adb:      Create (Ofile, Out_File, "sinfo.h");

As no other packages use ada, to build the my set of packages, the
no_ada flavor can be used. Building a non working gnat package only
helps others looking into the problem. Not for general release.

While the diff helps and thanks very much, just don't anyone put it into
CVS. Don't use unless you understand the gnat runtime package will still
be broken. The ada runtime/OpenBSD needs fixing for amd64, not the
building of the package. If the runtime needs fixing a new bootstrap
will be required.

Reply | Threaded
Open this post in threaded view
|

Re: lang/gcc fails on -current

Stuart Henderson
In reply to this post by Pavel Korovin-2
On 2019/07/22 08:36, Pavel Korovin wrote:

> On 07/20, Nigel Taylor wrote:
> > I can get past the sinfo.h error, treeprs.ads and osnames errors, but
> > there are more afterwards. Too many errors to fix by hand.
> >
> > The problem I think lies in opening files for writing when they don't
> > exist, it fails to create an empty file. So I manually touch sinfo.h to
> > create the empty file. Same for other missing files.
> >
> > Add env FLAVOR=no_ada to the make or if using dpb lang/gcc/8,no_ada
> >
> >
> > Not sure where the error is could be with the ada bootstrap file, needs
> > regenerating.
>
> The same problem here, please find the diff for gcc8 attached.

Yet the Makefiles are presumably OK on other systems, and are OK on i386.

Has anyone figured out what triggered this to start failing and what is
actually going on?

Wondering if there's an LP64 related problem. The only other 64-bit arch
building ada support in ports/lang/gcc/8 is mips64. Anyone know if that
still works?

The most obvious candidate to my eyes would be realpath, if there's some
problem with this it could impact many many ports. So I think we should
figure out what's really going on before committing workarounds to gcc
which take the whole thing off the radar.

Reply | Threaded
Open this post in threaded view
|

Re: lang/gcc fails on -current

Stuart Henderson
On 2019/07/22 12:21, Stuart Henderson wrote:

> On 2019/07/22 08:36, Pavel Korovin wrote:
> > On 07/20, Nigel Taylor wrote:
> > > I can get past the sinfo.h error, treeprs.ads and osnames errors, but
> > > there are more afterwards. Too many errors to fix by hand.
> > >
> > > The problem I think lies in opening files for writing when they don't
> > > exist, it fails to create an empty file. So I manually touch sinfo.h to
> > > create the empty file. Same for other missing files.
> > >
> > > Add env FLAVOR=no_ada to the make or if using dpb lang/gcc/8,no_ada
> > >
> > >
> > > Not sure where the error is could be with the ada bootstrap file, needs
> > > regenerating.
> >
> > The same problem here, please find the diff for gcc8 attached.
>
> Yet the Makefiles are presumably OK on other systems, and are OK on i386.

Oh, I spoke too soon.

: cp -p /usr/obj/ports/gcc-8.3.0/gcc-8.3.0/gcc/ada/snames.ads-tmpl /usr/obj/ports/gcc-8.3.0/gcc-8.3.0/gcc/ada/snames.adb-tmpl /usr/obj/ports/gcc-8.3.0/gcc-8.3.0/gcc/ada/snames.h-tmpl /usr/obj/ports/gcc-8.3.0/gcc-8.3.0/gcc/ada/xsnamest.adb /usr/obj/ports/gcc-8.3.0/gcc-8.3.0/gcc/ada/xutil.ads /usr/obj/ports/gcc-8.3.0/gcc-8.3.0/gcc/ada/xutil.adb ada/bldtools/snamest
: (cd ada/bldtools/snamest; gnatmake -q xsnamest ; ./xsnamest )
: /usr/obj/ports/gcc-8.3.0/bootstrap/lib/gcc/i386-unknown-openbsd6.4/8.2.0/adalib/libgnat.a(adaint.o): In function `__gnat_os_filename':
: /home/pascal/ports/pobj/gcc-8.2.0/build-i386/gcc/ada/rts/adaint.c:701: warning: strcpy() is almost always misused, please use strlcpy()
: /usr/obj/ports/gcc-8.3.0/bootstrap/lib/gcc/i386-unknown-openbsd6.4/8.2.0/adalib/libgnat.a(adaint.o): In function `__gnat_tmp_name':
: /home/pascal/ports/pobj/gcc-8.2.0/build-i386/gcc/ada/rts/adaint.c:1205: warning: sprintf() is often misused, please use snprintf()
: /usr/obj/ports/gcc-8.3.0/bootstrap/lib/gcc/i386-unknown-openbsd6.4/8.2.0/adalib/libgnat.a(adaint.o): In function `__gnat_readdir':
: /home/pascal/ports/pobj/gcc-8.2.0/build-i386/gcc/ada/rts/adaint.c:1300: warning: stpcpy() is dangerous; do not use it
:
: raised ADA.IO_EXCEPTIONS.USE_ERROR : treeprs.ads: No such file or directory

Started between these two:

OpenBSD 6.5-current (GENERIC.MP) #0: Wed Jul 17 10:20:06 MDT 2019
OpenBSD 6.5-current (GENERIC.MP) #0: Sat Jul 20 12:32:52 MDT 2019

Self built -current kernels; cvs checkout would have been about 4-5 hours
before the kernel timestamp.

> Has anyone figured out what triggered this to start failing and what is
> actually going on?
>
> Wondering if there's an LP64 related problem. The only other 64-bit arch
> building ada support in ports/lang/gcc/8 is mips64. Anyone know if that
> still works?
>
> The most obvious candidate to my eyes would be realpath, if there's some
> problem with this it could impact many many ports. So I think we should
> figure out what's really going on before committing workarounds to gcc
> which take the whole thing off the radar.
>

Reply | Threaded
Open this post in threaded view
|

Re: lang/gcc fails on -current

Nigel Taylor-2
In reply to this post by Stuart Henderson
On 22/07/2019 12:21, Stuart Henderson wrote:

> On 2019/07/22 08:36, Pavel Korovin wrote:
>> On 07/20, Nigel Taylor wrote:
>>> I can get past the sinfo.h error, treeprs.ads and osnames errors, but
>>> there are more afterwards. Too many errors to fix by hand.
>>>
>>> The problem I think lies in opening files for writing when they don't
>>> exist, it fails to create an empty file. So I manually touch sinfo.h to
>>> create the empty file. Same for other missing files.
>>>
>>> Add env FLAVOR=no_ada to the make or if using dpb lang/gcc/8,no_ada
>>>
>>>
>>> Not sure where the error is could be with the ada bootstrap file, needs
>>> regenerating.
>>
>> The same problem here, please find the diff for gcc8 attached.
>
> Yet the Makefiles are presumably OK on other systems, and are OK on i386.
>
> Has anyone figured out what triggered this to start failing and what is
> actually going on?
>
> Wondering if there's an LP64 related problem. The only other 64-bit arch
> building ada support in ports/lang/gcc/8 is mips64. Anyone know if that
> still works?
>
> The most obvious candidate to my eyes would be realpath, if there's some
> problem with this it could impact many many ports. So I think we should
> figure out what's really going on before committing workarounds to gcc
> which take the whole thing off the radar.
>
>

This is a ktrace/kdump side by side of grep CALL's one with and one
without sinfo.h present.

 70692 xsinfo   CALL  write(1,0x444b5f5cc1f,0x1)
                                                                   │
76912 xsinfo   CALL  write(1,0x97722da4c1f,0x1)
 70692 xsinfo   CALL  write(1,0x7f7ffffd8580,0x35)
                                                                   │
76912 xsinfo   CALL  write(1,0x7f7ffffa5ce0,0x35)
 70692 xsinfo   CALL  __realpath(0x7f7ffffee630,0x7f7ffffeddf0)
                                                                   │
76912 xsinfo   CALL  __realpath(0x7f7ffffbbd90,0x7f7ffffbb550)
 70692 xsinfo   CALL
open(0x7f7ffffee630,0x601<O_WRONLY|O_CREAT|O_TRUNC>,0666<S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH>)
          │ 76912 xsinfo   CALL  kbind(0x7f7ffffbb8a0,24,0x494ab4884a3e974f)
 70692 xsinfo   CALL  fstat(4,0x7f7ffffee150)
                                                                   │
76912 xsinfo   CALL  kbind(0x7f7ffffbb7f0,24,0x494ab4884a3e974f)
 70692 xsinfo   CALL  __realpath(0x7f7ffffee630,0x7f7ffffeddf0)
                                                                   │
76912 xsinfo   CALL  kbind(0x7f7ffffbb7f0,24,0x494ab4884a3e974f)
 70692 xsinfo   CALL  open(0x7f7ffffee630,0<O_RDONLY>)
                                                                   │
76912 xsinfo   CALL
mmap(0,0x4000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 70692 xsinfo   CALL  fstat(5,0x7f7ffffee150)
                                                                   │
76912 xsinfo   CALL
mmap(0,0x4000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)

Only when the file exists after the __realpath call is open called,
suggesting __realpath is returning an error for the missing file,
causing the open to be skipped. Could be realpath returning wrong error
in this case or runtime looking for the wrong error or not expecting an
error.

As a quick check I reverted back to a kernel I built 15 July, with that
kernel xsinfo works when sinfo.h is missing.


Which looks, this change might be the cause of problems. but only
guessing. But doesn't seem to tie up with your later email.

 cvs -R -q diff -uNp -r 1.321 vfs_syscalls.c
Index: vfs_syscalls.c
===================================================================
RCS file: /home/cvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.321
retrieving revision 1.323
diff -u -p -r1.321 -r1.323
--- vfs_syscalls.c      12 Jul 2019 13:56:27 -0000      1.321
+++ vfs_syscalls.c      15 Jul 2019 15:05:21 -0000      1.323
@@ -1,4 +1,4 @@
-/*     $OpenBSD: vfs_syscalls.c,v 1.321 2019/07/12 13:56:27 solene Exp
$       */
+/*     $OpenBSD: vfs_syscalls.c,v 1.323 2019/07/15 15:05:21 beck Exp $ */
 /*     $NetBSD: vfs_syscalls.c,v 1.71 1996/04/23 10:29:02 mycroft Exp $
       */

 /*
@@ -928,7 +928,7 @@ sys___realpath(struct proc *p, void *v,
                NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF | SAVENAME | REALPATH,
                    UIO_SYSSPACE, pathname, p);
        else
-               NDINIT(&nd, CREATE, FOLLOW | LOCKLEAF | LOCKPARENT |
SAVENAME |
+               NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF | LOCKPARENT |
SAVENAME |
                    REALPATH, UIO_SYSSPACE, pathname, p);

        nd.ni_cnd.cn_rpbuf = rpbuf;


I'll look at building kernel with this reverted. Not saying the change
isn't right, but may have exposed error checking which is wrong.

Reply | Threaded
Open this post in threaded view
|

Re: lang/gcc fails on -current

Stuart Henderson
On 2019/07/22 13:36, Nigel Taylor wrote:

> On 22/07/2019 12:21, Stuart Henderson wrote:
> > On 2019/07/22 08:36, Pavel Korovin wrote:
> >> On 07/20, Nigel Taylor wrote:
> >>> I can get past the sinfo.h error, treeprs.ads and osnames errors, but
> >>> there are more afterwards. Too many errors to fix by hand.
> >>>
> >>> The problem I think lies in opening files for writing when they don't
> >>> exist, it fails to create an empty file. So I manually touch sinfo.h to
> >>> create the empty file. Same for other missing files.
> >>>
> >>> Add env FLAVOR=no_ada to the make or if using dpb lang/gcc/8,no_ada
> >>>
> >>>
> >>> Not sure where the error is could be with the ada bootstrap file, needs
> >>> regenerating.
> >>
> >> The same problem here, please find the diff for gcc8 attached.
> >
> > Yet the Makefiles are presumably OK on other systems, and are OK on i386.
> >
> > Has anyone figured out what triggered this to start failing and what is
> > actually going on?
> >
> > Wondering if there's an LP64 related problem. The only other 64-bit arch
> > building ada support in ports/lang/gcc/8 is mips64. Anyone know if that
> > still works?
> >
> > The most obvious candidate to my eyes would be realpath, if there's some
> > problem with this it could impact many many ports. So I think we should
> > figure out what's really going on before committing workarounds to gcc
> > which take the whole thing off the radar.
> >
> >
>
> This is a ktrace/kdump side by side of grep CALL's one with and one
> without sinfo.h present.
>
>  70692 xsinfo   CALL  write(1,0x444b5f5cc1f,0x1)
>                                                                    │
> 76912 xsinfo   CALL  write(1,0x97722da4c1f,0x1)
>  70692 xsinfo   CALL  write(1,0x7f7ffffd8580,0x35)
>                                                                    │
> 76912 xsinfo   CALL  write(1,0x7f7ffffa5ce0,0x35)
>  70692 xsinfo   CALL  __realpath(0x7f7ffffee630,0x7f7ffffeddf0)
>                                                                    │
> 76912 xsinfo   CALL  __realpath(0x7f7ffffbbd90,0x7f7ffffbb550)
>  70692 xsinfo   CALL
> open(0x7f7ffffee630,0x601<O_WRONLY|O_CREAT|O_TRUNC>,0666<S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH>)
>           │ 76912 xsinfo   CALL  kbind(0x7f7ffffbb8a0,24,0x494ab4884a3e974f)
>  70692 xsinfo   CALL  fstat(4,0x7f7ffffee150)
>                                                                    │
> 76912 xsinfo   CALL  kbind(0x7f7ffffbb7f0,24,0x494ab4884a3e974f)
>  70692 xsinfo   CALL  __realpath(0x7f7ffffee630,0x7f7ffffeddf0)
>                                                                    │
> 76912 xsinfo   CALL  kbind(0x7f7ffffbb7f0,24,0x494ab4884a3e974f)
>  70692 xsinfo   CALL  open(0x7f7ffffee630,0<O_RDONLY>)
>                                                                    │
> 76912 xsinfo   CALL
> mmap(0,0x4000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
>  70692 xsinfo   CALL  fstat(5,0x7f7ffffee150)
>                                                                    │
> 76912 xsinfo   CALL
> mmap(0,0x4000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
>
> Only when the file exists after the __realpath call is open called,
> suggesting __realpath is returning an error for the missing file,
> causing the open to be skipped. Could be realpath returning wrong error
> in this case or runtime looking for the wrong error or not expecting an
> error.
>
> As a quick check I reverted back to a kernel I built 15 July, with that
> kernel xsinfo works when sinfo.h is missing.
>
>
> Which looks, this change might be the cause of problems. but only
> guessing. But doesn't seem to tie up with your later email.
>
>  cvs -R -q diff -uNp -r 1.321 vfs_syscalls.c
> Index: vfs_syscalls.c
> ===================================================================
> RCS file: /home/cvs/src/sys/kern/vfs_syscalls.c,v
> retrieving revision 1.321
> retrieving revision 1.323
> diff -u -p -r1.321 -r1.323
> --- vfs_syscalls.c      12 Jul 2019 13:56:27 -0000      1.321
> +++ vfs_syscalls.c      15 Jul 2019 15:05:21 -0000      1.323
> @@ -1,4 +1,4 @@
> -/*     $OpenBSD: vfs_syscalls.c,v 1.321 2019/07/12 13:56:27 solene Exp
> $       */
> +/*     $OpenBSD: vfs_syscalls.c,v 1.323 2019/07/15 15:05:21 beck Exp $ */
>  /*     $NetBSD: vfs_syscalls.c,v 1.71 1996/04/23 10:29:02 mycroft Exp $
>        */
>
>  /*
> @@ -928,7 +928,7 @@ sys___realpath(struct proc *p, void *v,
>                 NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF | SAVENAME | REALPATH,
>                     UIO_SYSSPACE, pathname, p);
>         else
> -               NDINIT(&nd, CREATE, FOLLOW | LOCKLEAF | LOCKPARENT |
> SAVENAME |
> +               NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF | LOCKPARENT |
> SAVENAME |
>                     REALPATH, UIO_SYSSPACE, pathname, p);
>
>         nd.ni_cnd.cn_rpbuf = rpbuf;
>
>
> I'll look at building kernel with this reverted. Not saying the change
> isn't right, but may have exposed error checking which is wrong.
>

Hmm. Well based on the ktrace it's likely that this will avoid the problem. *ponders*

We've already seen different codepaths taken in other ports (augeas) due to
autoconf detecting realpath differently.

ENOTIME right now but maybe worth trying to build a new adastrap after having
applied pvk's patch, then switch to the new adastrap, pull the patch out again,
and see if it can then build without it.


Reply | Threaded
Open this post in threaded view
|

Re: lang/gcc fails on -current

Nigel J Taylor
On 22/07/2019 14:06, Stuart Henderson wrote:

> On 2019/07/22 13:36, Nigel Taylor wrote:
>> On 22/07/2019 12:21, Stuart Henderson wrote:
>>> On 2019/07/22 08:36, Pavel Korovin wrote:
>>>> On 07/20, Nigel Taylor wrote:
>>>>> I can get past the sinfo.h error, treeprs.ads and osnames errors, but
>>>>> there are more afterwards. Too many errors to fix by hand.
>>>>>
>>>>> The problem I think lies in opening files for writing when they don't
>>>>> exist, it fails to create an empty file. So I manually touch sinfo.h to
>>>>> create the empty file. Same for other missing files.
>>>>>
>>>>> Add env FLAVOR=no_ada to the make or if using dpb lang/gcc/8,no_ada
>>>>>
>>>>>
>>>>> Not sure where the error is could be with the ada bootstrap file, needs
>>>>> regenerating.
>>>>
>>>> The same problem here, please find the diff for gcc8 attached.
>>>
>>> Yet the Makefiles are presumably OK on other systems, and are OK on i386.
>>>
>>> Has anyone figured out what triggered this to start failing and what is
>>> actually going on?
>>>
>>> Wondering if there's an LP64 related problem. The only other 64-bit arch
>>> building ada support in ports/lang/gcc/8 is mips64. Anyone know if that
>>> still works?
>>>
>>> The most obvious candidate to my eyes would be realpath, if there's some
>>> problem with this it could impact many many ports. So I think we should
>>> figure out what's really going on before committing workarounds to gcc
>>> which take the whole thing off the radar.
>>>
>>>
>>
>> This is a ktrace/kdump side by side of grep CALL's one with and one
>> without sinfo.h present.
>>
>>  70692 xsinfo   CALL  write(1,0x444b5f5cc1f,0x1)
>>                                                                    │
>> 76912 xsinfo   CALL  write(1,0x97722da4c1f,0x1)
>>  70692 xsinfo   CALL  write(1,0x7f7ffffd8580,0x35)
>>                                                                    │
>> 76912 xsinfo   CALL  write(1,0x7f7ffffa5ce0,0x35)
>>  70692 xsinfo   CALL  __realpath(0x7f7ffffee630,0x7f7ffffeddf0)
>>                                                                    │
>> 76912 xsinfo   CALL  __realpath(0x7f7ffffbbd90,0x7f7ffffbb550)
>>  70692 xsinfo   CALL
>> open(0x7f7ffffee630,0x601<O_WRONLY|O_CREAT|O_TRUNC>,0666<S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH>)
>>           │ 76912 xsinfo   CALL  kbind(0x7f7ffffbb8a0,24,0x494ab4884a3e974f)
>>  70692 xsinfo   CALL  fstat(4,0x7f7ffffee150)
>>                                                                    │
>> 76912 xsinfo   CALL  kbind(0x7f7ffffbb7f0,24,0x494ab4884a3e974f)
>>  70692 xsinfo   CALL  __realpath(0x7f7ffffee630,0x7f7ffffeddf0)
>>                                                                    │
>> 76912 xsinfo   CALL  kbind(0x7f7ffffbb7f0,24,0x494ab4884a3e974f)
>>  70692 xsinfo   CALL  open(0x7f7ffffee630,0<O_RDONLY>)
>>                                                                    │
>> 76912 xsinfo   CALL
>> mmap(0,0x4000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
>>  70692 xsinfo   CALL  fstat(5,0x7f7ffffee150)
>>                                                                    │
>> 76912 xsinfo   CALL
>> mmap(0,0x4000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
>>
>> Only when the file exists after the __realpath call is open called,
>> suggesting __realpath is returning an error for the missing file,
>> causing the open to be skipped. Could be realpath returning wrong error
>> in this case or runtime looking for the wrong error or not expecting an
>> error.
>>
>> As a quick check I reverted back to a kernel I built 15 July, with that
>> kernel xsinfo works when sinfo.h is missing.
>>
>>
>> Which looks, this change might be the cause of problems. but only
>> guessing. But doesn't seem to tie up with your later email.
>>
>>  cvs -R -q diff -uNp -r 1.321 vfs_syscalls.c
>> Index: vfs_syscalls.c
>> ===================================================================
>> RCS file: /home/cvs/src/sys/kern/vfs_syscalls.c,v
>> retrieving revision 1.321
>> retrieving revision 1.323
>> diff -u -p -r1.321 -r1.323
>> --- vfs_syscalls.c      12 Jul 2019 13:56:27 -0000      1.321
>> +++ vfs_syscalls.c      15 Jul 2019 15:05:21 -0000      1.323
>> @@ -1,4 +1,4 @@
>> -/*     $OpenBSD: vfs_syscalls.c,v 1.321 2019/07/12 13:56:27 solene Exp
>> $       */
>> +/*     $OpenBSD: vfs_syscalls.c,v 1.323 2019/07/15 15:05:21 beck Exp $ */
>>  /*     $NetBSD: vfs_syscalls.c,v 1.71 1996/04/23 10:29:02 mycroft Exp $
>>        */
>>
>>  /*
>> @@ -928,7 +928,7 @@ sys___realpath(struct proc *p, void *v,
>>                 NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF | SAVENAME | REALPATH,
>>                     UIO_SYSSPACE, pathname, p);
>>         else
>> -               NDINIT(&nd, CREATE, FOLLOW | LOCKLEAF | LOCKPARENT |
>> SAVENAME |
>> +               NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF | LOCKPARENT |
>> SAVENAME |
>>                     REALPATH, UIO_SYSSPACE, pathname, p);
>>
>>         nd.ni_cnd.cn_rpbuf = rpbuf;
>>
>>
>> I'll look at building kernel with this reverted. Not saying the change
>> isn't right, but may have exposed error checking which is wrong.
>>
>
> Hmm. Well based on the ktrace it's likely that this will avoid the problem. *ponders*
>
> We've already seen different codepaths taken in other ports (augeas) due to
> autoconf detecting realpath differently.
>
> ENOTIME right now but maybe worth trying to build a new adastrap after having
> applied pvk's patch, then switch to the new adastrap, pull the patch out again,
> and see if it can then build without it.
>
>
>
Little chance of that working, but only my view, and I don't know how to
build a new adastrap. Having built gnat and using the installed gnat to
build xsinfo and run which still fails, and the fact reverting to old
kernel make the same work. It's either revert the kernel or some fix in
the ada libraries. Just I'm only guessing where to start looking.


I updated from cvs /usr/src/sys, rebuilt kernel and installed under /
Then reverted vfs_syscalls.c rebuilt kernel and install under /

booted kernel, and check xsinfo with missing file failed as expected.
booted reverted kernel check xsinfo with missing file, was successful.

That gives a possible temporary fix. Now to look for how ada libraries /
Create works

Reply | Threaded
Open this post in threaded view
|

Re: lang/gcc fails on -current

Christian Weisgerber
In reply to this post by Mark Patruck
Mark Patruck:

> lang/gcc always fails with the following error on amd64 -current (~6 hours old)
>
> ------------------------
> Check for missing set procedures in body
>      OK
>
> All tests completed successfully, no errors detected
>
> raised ADA.IO_EXCEPTIONS.USE_ERROR : sinfo.h: No such file or directory

The problem is in libgnat and triggered by the recent change to
make realpath() POSIX-ly correct.

In libgnat/s-fileio.adb, the System.File_IO Open function calls
full_name() on all pathnames, including when creating files that
don't exist yet.

full_name() maps to __gnat_full_name().

In cstreams.c, __gnat_full_name() calls realpath().

Upstream doesn't notice because...

  /* Use realpath function which resolves links and references to . and ..
     on those Unix systems that support it. Note that GNU/Linux provides it but
     cannot handle more than 5 symbolic links in a full name, so we use the
     getcwd approach instead. */

... Linux uses a different code path.

The trivial patch below makes us use that same codepath.  Unfortunately,
it also requires building a new adastrap (on a system without the
realpath change).

With the new adastrap, gcc/8 will then build fine on -current.


Index: patches/patch-gcc_ada_cstreams_c
===================================================================
RCS file: patches/patch-gcc_ada_cstreams_c
diff -N patches/patch-gcc_ada_cstreams_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-gcc_ada_cstreams_c 22 Jul 2019 19:58:35 -0000
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+System.File_IO.Open calls full_name() for Create.  Use getcwd() approach
+instead of realpath() since the latter fails if the file doesn't exist.
+
+Index: gcc/ada/cstreams.c
+--- gcc/ada/cstreams.c.orig
++++ gcc/ada/cstreams.c
+@@ -190,7 +190,7 @@ __gnat_full_name (char *nam, char *buffer)
+  *p = '\\';
+     }
+
+-#elif defined (__FreeBSD__) || defined (__DragonFly__) || defined (__OpenBSD__)
++#elif defined (__FreeBSD__) || defined (__DragonFly__)
+
+   /* Use realpath function which resolves links and references to . and ..
+      on those Unix systems that support it. Note that GNU/Linux provides it but
--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lang/gcc fails on -current

Stuart Henderson
On 2019/07/22 22:05, Christian Weisgerber wrote:

> Mark Patruck:
>
> > lang/gcc always fails with the following error on amd64 -current (~6 hours old)
> >
> > ------------------------
> > Check for missing set procedures in body
> >      OK
> >
> > All tests completed successfully, no errors detected
> >
> > raised ADA.IO_EXCEPTIONS.USE_ERROR : sinfo.h: No such file or directory
>
> The problem is in libgnat and triggered by the recent change to
> make realpath() POSIX-ly correct.
>
> In libgnat/s-fileio.adb, the System.File_IO Open function calls
> full_name() on all pathnames, including when creating files that
> don't exist yet.
>
> full_name() maps to __gnat_full_name().
>
> In cstreams.c, __gnat_full_name() calls realpath().
>
> Upstream doesn't notice because...
>
>   /* Use realpath function which resolves links and references to . and ..
>      on those Unix systems that support it. Note that GNU/Linux provides it but
>      cannot handle more than 5 symbolic links in a full name, so we use the
>      getcwd approach instead. */
>
> ... Linux uses a different code path.
>
> The trivial patch below makes us use that same codepath.  Unfortunately,
> it also requires building a new adastrap (on a system without the
> realpath change).
>
> With the new adastrap, gcc/8 will then build fine on -current.

BTW I am building a new adastrap with this on i386. Will also need
hppa/mips64/macppc.

It might be worth adding a comment to the Makefile explaining what's
needed in case someone wants to work on updating arches currently
stuck with adastrap from old GCC versions later (building on 6.5
will be easiest, I guess)

> RCS file: patches/patch-gcc_ada_cstreams_c
> diff -N patches/patch-gcc_ada_cstreams_c
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-gcc_ada_cstreams_c 22 Jul 2019 19:58:35 -0000
> @@ -0,0 +1,17 @@
> +$OpenBSD$
> +
> +System.File_IO.Open calls full_name() for Create.  Use getcwd() approach
> +instead of realpath() since the latter fails if the file doesn't exist.
> +
> +Index: gcc/ada/cstreams.c
> +--- gcc/ada/cstreams.c.orig
> ++++ gcc/ada/cstreams.c
> +@@ -190,7 +190,7 @@ __gnat_full_name (char *nam, char *buffer)
> +  *p = '\\';
> +     }
> +
> +-#elif defined (__FreeBSD__) || defined (__DragonFly__) || defined (__OpenBSD__)
> ++#elif defined (__FreeBSD__) || defined (__DragonFly__)
> +
> +   /* Use realpath function which resolves links and references to . and ..
> +      on those Unix systems that support it. Note that GNU/Linux provides it but
> --
> Christian "naddy" Weisgerber                          [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

Re: lang/gcc fails on -current

Pascal Stumpf-2
On Mon, 22 Jul 2019 21:44:06 +0100, Stuart Henderson wrote:

> On 2019/07/22 22:05, Christian Weisgerber wrote:
> > Mark Patruck:
> >
> > > lang/gcc always fails with the following error on amd64 -current (~6 hours old)
> > >
> > > ------------------------
> > > Check for missing set procedures in body
> > >      OK
> > >
> > > All tests completed successfully, no errors detected
> > >
> > > raised ADA.IO_EXCEPTIONS.USE_ERROR : sinfo.h: No such file or directory
> >
> > The problem is in libgnat and triggered by the recent change to
> > make realpath() POSIX-ly correct.
> >
> > In libgnat/s-fileio.adb, the System.File_IO Open function calls
> > full_name() on all pathnames, including when creating files that
> > don't exist yet.
> >
> > full_name() maps to __gnat_full_name().
> >
> > In cstreams.c, __gnat_full_name() calls realpath().
> >
> > Upstream doesn't notice because...
> >
> >   /* Use realpath function which resolves links and references to . and ..
> >      on those Unix systems that support it. Note that GNU/Linux provides it but
> >      cannot handle more than 5 symbolic links in a full name, so we use the
> >      getcwd approach instead. */
> >
> > ... Linux uses a different code path.
> >
> > The trivial patch below makes us use that same codepath.  Unfortunately,
> > it also requires building a new adastrap (on a system without the
> > realpath change).
> >
> > With the new adastrap, gcc/8 will then build fine on -current.
>
> BTW I am building a new adastrap with this on i386. Will also need
> hppa/mips64/macppc.

I still have these machines before the realpath switch, I can do those.

> It might be worth adding a comment to the Makefile explaining what's
> needed in case someone wants to work on updating arches currently
> stuck with adastrap from old GCC versions later (building on 6.5
> will be easiest, I guess)
>
> > RCS file: patches/patch-gcc_ada_cstreams_c
> > diff -N patches/patch-gcc_ada_cstreams_c
> > --- /dev/null 1 Jan 1970 00:00:00 -0000
> > +++ patches/patch-gcc_ada_cstreams_c 22 Jul 2019 19:58:35 -0000
> > @@ -0,0 +1,17 @@
> > +$OpenBSD$
> > +
> > +System.File_IO.Open calls full_name() for Create.  Use getcwd() approach
> > +instead of realpath() since the latter fails if the file doesn't exist.
> > +
> > +Index: gcc/ada/cstreams.c
> > +--- gcc/ada/cstreams.c.orig
> > ++++ gcc/ada/cstreams.c
> > +@@ -190,7 +190,7 @@ __gnat_full_name (char *nam, char *buffer)
> > +  *p = '\\';
> > +     }
> > +
> > +-#elif defined (__FreeBSD__) || defined (__DragonFly__) || defined (__OpenBSD__)
> > ++#elif defined (__FreeBSD__) || defined (__DragonFly__)
> > +
> > +   /* Use realpath function which resolves links and references to . and ..
> > +      on those Unix systems that support it. Note that GNU/Linux provides it but
> > --
> > Christian "naddy" Weisgerber                          [hidden email]
> >

Reply | Threaded
Open this post in threaded view
|

Re: lang/gcc fails on -current

Stuart Henderson
In reply to this post by Christian Weisgerber
On 2019/07/22 22:05, Christian Weisgerber wrote:

> Mark Patruck:
>
> > lang/gcc always fails with the following error on amd64 -current (~6 hours old)
> >
> > ------------------------
> > Check for missing set procedures in body
> >      OK
> >
> > All tests completed successfully, no errors detected
> >
> > raised ADA.IO_EXCEPTIONS.USE_ERROR : sinfo.h: No such file or directory
>
> The problem is in libgnat and triggered by the recent change to
> make realpath() POSIX-ly correct.
>
> In libgnat/s-fileio.adb, the System.File_IO Open function calls
> full_name() on all pathnames, including when creating files that
> don't exist yet.
>
> full_name() maps to __gnat_full_name().
>
> In cstreams.c, __gnat_full_name() calls realpath().
>
> Upstream doesn't notice because...
>
>   /* Use realpath function which resolves links and references to . and ..
>      on those Unix systems that support it. Note that GNU/Linux provides it but
>      cannot handle more than 5 symbolic links in a full name, so we use the
>      getcwd approach instead. */
>
> ... Linux uses a different code path.
>
> The trivial patch below makes us use that same codepath.  Unfortunately,
> it also requires building a new adastrap (on a system without the
> realpath change).
>
> With the new adastrap, gcc/8 will then build fine on -current.

OK sthen@ to add this and bump REVISION-ada.

I've copied out the i386 bootstrap to
https://spacehopper.org/mirrors/adastrap-i386-8.3.0-0.tar.xz which is
already in MASTER_SITES0.

ADASTRAP_LIBC-i386 = 95.1
ADASTRAP_LIBM-i386 = 10.1
ADASTRAP-i386 = adastrap-i386-$V-0.tar.xz