Discussion:
Can't build Go support in gcc-4.8.1 on OpenBSD
niXman
2013-09-28 07:20:59 UTC
Permalink
Hi,

I successfully build gcc-4.8.1 with c,c++,fortran support on OpenBSD
pre-5.4 using patches from ports, but I can't build with Go support.
Also I successfully build gcc-4.6.x with c,c++,fortran,go support.
The problem is that OpenBSD has no ucontext.h header.

Error message:
In file included from ../../../../unpack/gcc-4.8.1/libgo/runtime/go-main.c:17:0:
../../../../unpack/gcc-4.8.1/libgo/runtime/runtime.h:18:22: fatal
error: ucontext.h: No such file or directory
#include <ucontext.h>
^
compilation terminated.
--
Regards,
niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingwbuilds/
___________________________________________________
Another online IDE: http://liveworkspace.org/
niXman
2013-09-28 18:39:12 UTC
Permalink
With gcc-4.7.x the same error.

Any ideas?
Post by niXman
Hi,
I successfully build gcc-4.8.1 with c,c++,fortran support on OpenBSD
pre-5.4 using patches from ports, but I can't build with Go support.
Also I successfully build gcc-4.6.x with c,c++,fortran,go support.
The problem is that OpenBSD has no ucontext.h header.
../../../../unpack/gcc-4.8.1/libgo/runtime/runtime.h:18:22: fatal
error: ucontext.h: No such file or directory
#include <ucontext.h>
^
compilation terminated.
--
Regards,
niXman
___________________________________________________
http://sourceforge.net/projects/mingwbuilds/
___________________________________________________
Another online IDE: http://liveworkspace.org/
--
Regards,
niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingwbuilds/
___________________________________________________
Another online IDE: http://liveworkspace.org/
Ian Lance Taylor
2013-09-28 19:27:17 UTC
Permalink
Post by niXman
I successfully build gcc-4.8.1 with c,c++,fortran support on OpenBSD
pre-5.4 using patches from ports, but I can't build with Go support.
Also I successfully build gcc-4.6.x with c,c++,fortran,go support.
The problem is that OpenBSD has no ucontext.h header.
../../../../unpack/gcc-4.8.1/libgo/runtime/runtime.h:18:22: fatal
error: ucontext.h: No such file or directory
#include <ucontext.h>
^
compilation terminated.
The current implementation of goroutines in gccgo requires the
makecontext, getcontext, and setcontext functions. Those functions
were standardized in POSIX-1.2001 but then removed in POSIX-1.2008
with no replacement. Most systems provide them for backward
compatibility. However, it is possible that OpenBSD does not. I
really don't know.

It's possible to fix this by writing processor-dependent functions
that would serve the same purpose as the *context functions, and in
fact that would be more efficient. But I have not actually done this.

Ian
Ian Lance Taylor
2013-09-28 20:19:15 UTC
Permalink
On Sat, Sep 28, 2013 at 1:09 PM, Jędrzej Dudkiewicz
Ian, how would you implement those macros? I'mnot asking for complete
implementation, just few pointers or hints.
* A header file that declares a struct to hold all the caller-saved
registers plus the stack pointer and PC.
* getcontext is assembler code that stores the registers into that
struct. This is pretty much the same as setjmp. In particular, it
returns multiple times. It should have the GCC returns_twice
attribute.
* setcontext is assembler code that restores the registers from that
struct. This is pretty much the same as longjmp. It should have
the GCC noreturn attribute.
* makecontext sets the saved PC to point to the function passed in and
initializes the stack to look like a call to that function. gccgo
does not require the ability to pass arguments to that function.

Probably for gccgo's purposes we can write a slightly cleaner
interface for what gccgo needs, and implement that interface in terms
of the *context functions when no processor-specific implementation is
available.

Ian
Post by Ian Lance Taylor
Post by niXman
I successfully build gcc-4.8.1 with c,c++,fortran support on OpenBSD
pre-5.4 using patches from ports, but I can't build with Go support.
Also I successfully build gcc-4.6.x with c,c++,fortran,go support.
The problem is that OpenBSD has no ucontext.h header.
In file included from
../../../../unpack/gcc-4.8.1/libgo/runtime/runtime.h:18:22: fatal
error: ucontext.h: No such file or directory
#include <ucontext.h>
^
compilation terminated.
The current implementation of goroutines in gccgo requires the
makecontext, getcontext, and setcontext functions. Those functions
were standardized in POSIX-1.2001 but then removed in POSIX-1.2008
with no replacement. Most systems provide them for backward
compatibility. However, it is possible that OpenBSD does not. I
really don't know.
It's possible to fix this by writing processor-dependent functions
that would serve the same purpose as the *context functions, and in
fact that would be more efficient. But I have not actually done this.
Ian
niXman
2013-09-28 20:32:53 UTC
Permalink
Post by Ian Lance Taylor
The current implementation of goroutines in gccgo requires the
makecontext, getcontext, and setcontext functions.
What do goroutines use in gcc-4.6.x instead of theese functions?
Post by Ian Lance Taylor
... But I have not actually done this.
Is libgo writen by you?
--
Regards,
niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingwbuilds/
___________________________________________________
Another online IDE: http://liveworkspace.org/
Ian Lance Taylor
2013-09-28 22:18:44 UTC
Permalink
Post by niXman
Post by Ian Lance Taylor
The current implementation of goroutines in gccgo requires the
makecontext, getcontext, and setcontext functions.
What do goroutines use in gcc-4.6.x instead of theese functions?
In GCC 4.6 libgo each goroutine is run in a separate thread, rather
than using the more efficient context switching functions.
Post by niXman
Post by Ian Lance Taylor
... But I have not actually done this.
Is libgo writen by you?
The vast majority of libgo is simply the same standard library that is
used by the gc compiler. I wrote the parts of it that are specific to
gccgo.

Ian

Loading...