https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #38 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #37 from Ian Lance Taylor ---
> Search for this comment in the top-level configure.ac file.
>
> # Disable libgo for some systems where it is known to not work.
> # For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #37 from Ian Lance Taylor ---
Search for this comment in the top-level configure.ac file.
# Disable libgo for some systems where it is known to not work.
# For testing, you can easily override this with --enable-libgo.
That said if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
Rainer Orth changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #35 from Ian Lance Taylor ---
I don't know that anybody has looked at the BSD support recently.
Thanks for your efforts. I agree that this is work for a programmer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #34 from Curtis Hamilton ---
Do you know if anyone has actively worked on the BSD code recently?
I'm abandoning my effort go get this working on freebsd. I'm not a really a
programmer and this is beyond my meager abilities.
So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #33 from Ian Lance Taylor ---
> There are actually only 32 signals, however mksigtab.sh adds a signal at 0
> "SIGNONE: no trap", which makes 33 signals in sigtable. Freebsd sets _NSIG
> to 32 for 33 signals, counting from 0 vice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #32 from Curtis Hamilton ---
(In reply to Ian Lance Taylor from comment #31)
> > runtime: len(sigtable)=33 _NSIG=32
> > fatal error: bad sigtable len
>
> This error means that the sigtable generated by mksigtab.sh does not match
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #31 from Ian Lance Taylor ---
> runtime: len(sigtable)=33 _NSIG=32
> fatal error: bad sigtable len
This error means that the sigtable generated by mksigtab.sh does not match the
value of _NSIG in the file generated by mksysinfo.sh.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #30 from Curtis Hamilton ---
Ian,
I've made progress with building the frontend but I have an issue with
implementing Syscall9 needed by libgo/go/os/wait_wait6.go. I tried adding the
file "syscall_freebsd_ppc64.go" containing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #29 from Ian Lance Taylor ---
The runtime_sysinfo.go is manually generated by mkrsysinfo.sh. I don't know
where the _thread definition is coming from, but probably the simplest approach
is to remove it via the list of grep -v call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #28 from Curtis Hamilton ---
(In reply to Ian Lance Taylor from comment #27)
> What is the complete contents of your new file? You showed just a
> declaration; is there a function body there as well?
That's what I was missing. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #27 from Ian Lance Taylor ---
What is the complete contents of your new file? You showed just a declaration;
is there a function body there as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #26 from Curtis Hamilton ---
Ian,
I've made progress with building the frontend but I have an issue with
implementing Syscall9 needed by libgo/go/os/wait_wait6.go. I tried adding the
file "syscall_freebsd_ppc64.go" containing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #25 from Ian Lance Taylor ---
The code in os_freebsd.go is written for the gc toolchain. You'll need to look
at it and see whether it makes sense for gccgo.
That said, that call to sysctl does seem to make sense. You'll need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #24 from Curtis Hamilton ---
Okay, I modified the code and got pass that issue. But have run into another
issue that has me stumped. I'm getting the below error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #23 from Ian Lance Taylor ---
Look for _kern in runtime.inc. See what struct it is part of. The struct is
likely defined in the generated file runtime_sysinfo.go. You may need to
modify libgo/mkrsysinfo.sh to not add that struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #22 from Curtis Hamilton ---
I've made progress in getting the go frontend to build, but have run into the
following error:
In file included from
/usr/ports/lang/gcc7/work/gcc-7.4.0/libgo/runtime/runtime.h:113:0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #21 from Curtis Hamilton ---
Created attachment 46510
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46510=edit
FreeBSD/X86_64 GCC8 build log
GccGo doesn't build on FreeBSD X86 either. It has similar issues to those I
got on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #20 from Curtis Hamilton ---
(In reply to Ian Lance Taylor from comment #19)
> People build the gofrontend all the time on GNU/Linux systems. I don't know
> if anyone has successful built it on a FreeBSD system.
My bad! I was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #19 from Ian Lance Taylor ---
People build the gofrontend all the time on GNU/Linux systems. I don't know if
anyone has successful built it on a FreeBSD system.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #18 from Curtis Hamilton ---
Created attachment 46412
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46412=edit
Patch to fix undefined types in sysinfo.go and runtime_sysinfo.go
This patch resolves many of the undefines with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #17 from Piotr Kubaj ---
Since you mentioned libgo/runtime_sysinfo.go, I also had a look there and saw
that umtx_time is already present there:
type __umtx_time struct { _timeout timespec; _flags uint32; _clockid uint32; }
const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #16 from Piotr Kubaj ---
(In reply to Ian Lance Taylor from comment #15)
> I committed a patch that should fix the nanotime problem.
>
> Some of the other issues you describe will most likely require a fix in the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #15 from Ian Lance Taylor ---
I committed a patch that should fix the nanotime problem.
Some of the other issues you describe will most likely require a fix in the
libgo/mkrsysinfo.sh script, which generates the file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #14 from ian at gcc dot gnu.org ---
Author: ian
Date: Tue Feb 26 14:46:56 2019
New Revision: 269214
URL: https://gcc.gnu.org/viewcvs?rev=269214=gcc=rev
Log:
PR go/86535
runtime: always declare nanotime in Go
For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
Piotr Kubaj changed:
What|Removed |Added
CC||pkubaj at anongoth dot pl
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #12 from Curtis Hamilton ---
I wanted to see if the errors were version specific, so I attempted a build on
FreeBSD 10.2 and the results were the same. So I manually edited the
"runtime_sysinfo.go", as best as I could to get past
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #11 from Ian Lance Taylor ---
Sorry, you're right, it's -fdump-go-spec.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #10 from Curtis Hamilton ---
Is it -fgo-dump-spec or -fdump-go-spec? Below is an extract of my build log:
checking for hypotf... /usr/ports/lang/gcc7/work/.build/./gcc/xgcc
-B/usr/ports/lang/gcc7/work/.build/./gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #9 from Ian Lance Taylor ---
I haven't tried to recreate the problem on FreeBSD. I've just tried various
inputs to GCC 7 -fgo-dump-spec.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #8 from Curtis Hamilton ---
Based on you last comment, I attempted a build using FreeBSD 11.2 RC1 on the
same hardware (PowerMac G5 Quad) and got the same results.
Are you using native hardware or emulation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #7 from Ian Lance Taylor ---
Thanks. There seems to be something with -fgo-dump-spec on your system, such
that it fails if an incomplete typedef is seen before a complete typedef. I'm
not sure why that would be. I haven't been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #6 from Curtis Hamilton ---
Adding before solves the issue with "cmsghdr" but
not the other entries.
/usr/local/bin/gmkdir -p .; files=`echo
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/runtime/alg.go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #5 from Ian Lance Taylor ---
Thanks. Unfortunately I don't know why this is failing.
Does it help if you edit the file libgo/sysinfo.c to move
#include
ahead of
#include
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #4 from Curtis Hamilton ---
Here's the definition in sys/socket.h:
/*
* Header for ancillary data objects in msg_control buffer.
* Used for additional information with/about a datagram
* not expressible by flags. The format is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #3 from Ian Lance Taylor ---
Thanks for providing the gen-sysinfo.go file. I see that cmsghdr is defined in
that file. Several function declarations use it. It even has a size of 12
bytes. It's just missing a definition. So I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #2 from Curtis Hamilton ---
Created attachment 44402
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44402=edit
Requested generated file
I cannot find a definition for 'cmsghdr' in any header file. The only
reference I see in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #1 from Ian Lance Taylor ---
Can you attach a copy of the generated file gen-sysinfo.go?
What does the definition of, say, cmsghdr look like in (or some
header file included by that one)?
38 matches
Mail list logo
