Re: Go patch committed: Update Go library
On Wed, 2 Nov 2011, David Daney wrote: > On Linux you also have iopl and ioperm which are x86 only. ARM and Alpha appear to have them as well, though I don't know if anyone actually uses them on those targets. -- Joseph S. Myers jos...@codesourcery.com
Re: Go patch committed: Update Go library
On Wed, 2 Nov 2011, Ian Lance Taylor wrote:
> David Daney writes:
>
> > On MIPS we fail because of those. I was going to create a patch to
> > move those two to libcall_linux_{386,amd64}.go. An alternative would
> > be to remove them too.
>
> Moving them sounds good to me. libgo already has a framework for
> architecture specific system calls. It doesn't have a framework for
> glibc version.
autoconf detection of available functions (for functions that aren't
always available for a given target) would be better than basing things on
glibc version, anyway - and in libgo, just as in libstdc++, you can safely
assume target libc is available for running link tests. autoconf
detection will probably be required if anyone wants to build libgo with
uClibc, for example.
--
Joseph S. Myers
jos...@codesourcery.com
Re: Go patch committed: Update Go library
David Daney writes:
> On MIPS we fail because of those. I was going to create a patch to
> move those two to libcall_linux_{386,amd64}.go. An alternative would
> be to remove them too.
Moving them sounds good to me. libgo already has a framework for
architecture specific system calls. It doesn't have a framework for
glibc version.
Ian
Re: Go patch committed: Update Go library
Ian Lance Taylor writes: > I assume that CentOS 5.5 uses some version of glibc before version 2.6. Right: $ /lib/libc.so.6 GNU C Library stable release version 2.5, by Roland McGrath et al. > The three functions you mention are not supported in older versions of > glibc. Fortunately, they are not called anywhere else in the library, > so this patch takes the easy way out and simply removes them. > Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. > Committed to mainline. Fine, thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Go patch committed: Update Go library
On 11/02/2011 10:54 AM, Ian Lance Taylor wrote:
Rainer Orth writes:
All go and libgo execution tests are failing for me with this patch on
x86_64-unknown-linux-gnu (CentOS 5.5, I think):
output is:
/var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li
bgo/.libs/libgo.so: undefined reference to `inotify_init1'
/var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li
bgo/.libs/libgo.so: undefined reference to `fallocate'
/var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li
bgo/.libs/libgo.so: undefined reference to `sync_file_range'
collect2: error: ld returned 1 exit status
FAIL: go.go-torture/execute/array-1.go compilation, -O0
I assume that CentOS 5.5 uses some version of glibc before version 2.6.
The three functions you mention are not supported in older versions of
glibc. Fortunately, they are not called anywhere else in the library,
so this patch takes the easy way out and simply removes them.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
On Linux you also have iopl and ioperm which are x86 only.
On MIPS we fail because of those. I was going to create a patch to move
those two to libcall_linux_{386,amd64}.go. An alternative would be to
remove them too.
David Daney
Re: Go patch committed: Update Go library
Rainer Orth writes: > All go and libgo execution tests are failing for me with this patch on > x86_64-unknown-linux-gnu (CentOS 5.5, I think): > > output is: > /var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li > bgo/.libs/libgo.so: undefined reference to `inotify_init1' > /var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li > bgo/.libs/libgo.so: undefined reference to `fallocate' > /var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li > bgo/.libs/libgo.so: undefined reference to `sync_file_range' > collect2: error: ld returned 1 exit status > > FAIL: go.go-torture/execute/array-1.go compilation, -O0 I assume that CentOS 5.5 uses some version of glibc before version 2.6. The three functions you mention are not supported in older versions of glibc. Fortunately, they are not called anywhere else in the library, so this patch takes the easy way out and simply removes them. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian diff -r c0c039af2298 libgo/go/syscall/libcall_linux.go --- a/libgo/go/syscall/libcall_linux.go Wed Nov 02 09:48:33 2011 -0700 +++ b/libgo/go/syscall/libcall_linux.go Wed Nov 02 10:32:33 2011 -0700 @@ -186,8 +186,9 @@ //sys Faccessat(dirfd int, path string, mode uint32, flags int) (errno int) //faccessat(dirfd int, pathname *byte, mode int, flags int) int -//sys Fallocate(fd int, mode uint32, off int64, len int64) (errno int) -//fallocate(fd int, mode int, offset Offset_t, len Offset_t) int +// FIXME: Only in glibc 2.10 and later. +// //sys Fallocate(fd int, mode uint32, off int64, len int64) (errno int) +// //fallocate(fd int, mode int, offset Offset_t, len Offset_t) int //sys Fchmodat(dirfd int, path string, mode uint32, flags int) (errno int) //fchmodat(dirfd int, pathname *byte, mode Mode_t, flags int) int @@ -223,8 +224,9 @@ //sysnb InotifyInit() (fd int, errno int) //inotify_init() int -//sysnb InotifyInit1(flags int) (fd int, errno int) -//inotify_init1(flags int) int +// FIXME: Only in glibc 2.9 and later. +// //sysnb InotifyInit1(flags int) (fd int, errno int) +// //inotify_init1(flags int) int //sysnb InotifyRmWatch(fd int, watchdesc uint32) (success int, errno int) //inotify_rm_watch(fd int, wd uint32) int @@ -298,8 +300,9 @@ // //sys Statfs(path string, buf *Statfs_t) (errno int) // //statfs(path *byte, buf *Statfs_t) int -//sys SyncFileRange(fd int, off int64, n int64, flags int) (errno int) -//sync_file_range(fd int, off Offset_t, n Offset_t, flags uint) int +// FIXME: Only in glibc 2.6 and later. +// //sys SyncFileRange(fd int, off int64, n int64, flags int) (errno int) +// //sync_file_range(fd int, off Offset_t, n Offset_t, flags uint) int // FIXME: mksysinfo Sysinfo_t // //sysnb Sysinfo(info *Sysinfo_t) (errno int)
Re: Go patch committed: Update Go library
Ian Lance Taylor writes: > This patch updates the Go library to the most recent weekly release. I > think the only potential portability issues here are the use of the > ipv6_mreq struct. I'm not entirely sure the new exp/terminal package is > portable, but it might be. All go and libgo execution tests are failing for me with this patch on x86_64-unknown-linux-gnu (CentOS 5.5, I think): output is: /var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li bgo/.libs/libgo.so: undefined reference to `inotify_init1' /var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li bgo/.libs/libgo.so: undefined reference to `fallocate' /var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li bgo/.libs/libgo.so: undefined reference to `sync_file_range' collect2: error: ld returned 1 exit status FAIL: go.go-torture/execute/array-1.go compilation, -O0 Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Go patch committed: Update Go library
Matthias Klose writes: > I see a build failure with the last update, not yet sure what is going wrong. > > /bin/mkdir -p exp; files=`echo ../../../src/libgo/go/exp/ebnf/ebnf.go > ../../../src/libgo/go/exp/ebnf/parser.go go/scanner.gox go/token.gox os.gox > strconv.gox unicode.gox utf8.gox | sed -e 's/[^ ]*\.gox//g'`; /bin/bash > ./libtool --tag GO --mode=compile > /home/packages/gcc/snap/gcc-snapshot-2001/build/./gcc/gccgo > -B/home/packages/gcc/snap/gcc-snapshot-2001/build/./gcc/ > -B/usr/lib/gcc-snapshot/x86_64-linux-gnu/bin/ > -B/usr/lib/gcc-snapshot/x86_64-linux-gnu/lib/ -isystem > /usr/lib/gcc-snapshot/x86_64-linux-gnu/include -isystem > /usr/lib/gcc-snapshot/x86_64-linux-gnu/sys-include -minline-all-stringops > -O2 -g -I . -c -fgo-prefix="libgo_exp" -o exp/ebnf.lo $files > libtool: compile: > /home/packages/gcc/snap/gcc-snapshot-2001/build/./gcc/gccgo > -B/home/packages/gcc/snap/gcc-snapshot-2001/build/./gcc/ > -B/usr/lib/gcc-snapshot/x86_64-linux-gnu/bin/ > -B/usr/lib/gcc-snapshot/x86_64-linux-gnu/lib/ -isystem > /usr/lib/gcc-snapshot/x86_64-linux-gnu/include -isystem > /usr/lib/gcc-snapshot/x86_64-linux-gnu/sys-include -minline-all-stringops -O2 > -g > -I . -c -fgo-prefix=libgo_exp ../../../src/libgo/go/exp/ebnf/ebnf.go > ../../../src/libgo/go/exp/ebnf/parser.go -fPIC -o exp/.libs/ebnf.o > ../../../src/libgo/go/exp/ebnf/ebnf.go:28:9: error: import file 'scanner' not > found > ../../../src/libgo/go/exp/ebnf/ebnf.go:55:26: error: expected package > ../../../src/libgo/go/exp/ebnf/ebnf.go:66:16: error: expected package > ../../../src/libgo/go/exp/ebnf/ebnf.go:77:20: error: expected package > ../../../src/libgo/go/exp/ebnf/ebnf.go:83:20: error: expected package > ../../../src/libgo/go/exp/ebnf/ebnf.go:94:17: error: expected package > ../../../src/libgo/go/exp/ebnf/ebnf.go:100:17: error: expected package > ../../../src/libgo/go/exp/ebnf/ebnf.go:106:17: error: expected package > ../../../src/libgo/go/exp/ebnf/ebnf.go:118:17: error: expected package > ../../../src/libgo/go/exp/ebnf/ebnf.go:128:35: error: expected package > ../../../src/libgo/go/exp/ebnf/ebnf.go:128:45: error: expected ';' or newline > after top level declaration > ../../../src/libgo/go/exp/ebnf/ebnf.go:129:32: error: expected package > ../../../src/libgo/go/exp/ebnf/ebnf.go:129:45: error: expected ';' or newline > after top level declaration > ../../../src/libgo/go/exp/ebnf/ebnf.go:130:29: error: expected package I messed up a Makefile dependency. Fixed like so. Bootstrapped on x86_64-unknown-linux-gnu. Committed to mainline. Ian diff -r d884462fd93f libgo/Makefile.am --- a/libgo/Makefile.am Mon Oct 31 22:19:13 2011 -0700 +++ b/libgo/Makefile.am Wed Nov 02 08:57:56 2011 -0700 @@ -2639,7 +2639,7 @@ @$(CHECK) .PHONY: encoding/pem/check -exp/ebnf.lo: $(go_exp_ebnf_files) go/scanner.gox go/token.gox os.gox \ +exp/ebnf.lo: $(go_exp_ebnf_files) scanner.gox go/token.gox os.gox \ strconv.gox unicode.gox utf8.gox $(BUILDPACKAGE) exp/ebnf/check: $(CHECK_DEPS)
Re: Go patch committed: Update Go library
On Thu, Oct 27, 2011 at 6:42 PM, Uros Bizjak wrote:
>> This patch updates the Go library to the most recent weekly release. I
>> think the only potential portability issues here are the use of the
>> ipv6_mreq struct. I'm not entirely sure the new exp/terminal package is
>> portable, but it might be.
>
> There are still problems with EpollEvent definition on Alpha, please
> see [1] for the analysis.
>
> [1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00457.html
Thanks, the resulting epoll.go on Alpha reads as:
epoll.go
package syscall
type EpollEvent struct {
Events uint32
Pad [4]byte
Fd int32
Pad2 [4]byte
}
However, I am not able to finish compilation of libgo due to unrelated
problem (reported in [1]) with TC[GS]ETS define:
libtool: compile: /space/uros/gcc-build-go/./gcc/gccgo
-B/space/uros/gcc-build-go/./gcc/
-B/usr/local/alphaev68-unknown-linux-gnu/bin/
-B/usr/local/alphaev68-unknown-linux-gnu/lib/ -isystem
/usr/local/alphaev68-unknown-linux-gnu/include -isystem
/usr/local/alphaev68-unknown-linux-gnu/sys-include -O2 -g -mieee -I .
-c -fgo-prefix=libgo_bytes
../../../gcc-svn/trunk/libgo/go/bytes/buffer.go
../../../gcc-svn/trunk/libgo/go/bytes/bytes.go
../../../gcc-svn/trunk/libgo/go/bytes/bytes_decl.go -o bytes/bytes.o
>/dev/null 2>&1
../../../gcc-svn/trunk/libgo/go/exp/terminal/terminal.go:31:78: error:
reference to undefined identifier ‘syscall.TCGETS’
../../../gcc-svn/trunk/libgo/go/exp/terminal/terminal.go:40:81: error:
reference to undefined identifier ‘syscall.TCGETS’
../../../gcc-svn/trunk/libgo/go/exp/terminal/terminal.go:47:81: error:
reference to undefined identifier ‘syscall.TCSETS’
../../../gcc-svn/trunk/libgo/go/exp/terminal/terminal.go:57:78: error:
reference to undefined identifier ‘syscall.TCSETS’
../../../gcc-svn/trunk/libgo/go/exp/terminal/terminal.go:66:81: error:
reference to undefined identifier ‘syscall.TCGETS’
../../../gcc-svn/trunk/libgo/go/exp/terminal/terminal.go:72:81: error:
reference to undefined identifier ‘syscall.TCSETS’
../../../gcc-svn/trunk/libgo/go/exp/terminal/terminal.go:77:68: error:
reference to undefined identifier ‘syscall.TCSETS’
make[4]: *** [exp/terminal.lo] Error 1
[1] http://gcc.gnu.org/ml/gcc/2011-10/msg00488.html
Uros.
Re: Go patch committed: Update Go library
Rainer Orth writes:
> After this change, I'm seeing another issue: most 32-bit go execution
> tests fail like this on Solaris 11/x86:
>
> /vol/gcc/src/hg/trunk/local/libgo/runtime/malloc.goc:366: libgo assertion
> failure
> FAIL: go.go-torture/execute/array-1.go execution, -O0
>
> Running the test under truss, I find:
>
> 14261:mmap(0xFF00, 805306368, PROT_NONE, MAP_PRIVATE|MAP_ANON,
> -1, 0) Err#12 ENOMEM
>
> With truss -u (user function tracing), I see:
>
> 14285/1@1:-> libgo:runtime_mallocinit()
> 14285/1@1: -> libgo:runtime_InitSizes()
> 14285/1@1: <- libgo:runtime_InitSizes() = 2
> 14285/1@1: -> libgo:runtime_SysReserve()
> 14285/1: mmap(0xFF00, 805306368, PROT_NONE, MAP_PRIVATE|MAP_ANON,
> -1, 0) Err#12 ENOMEM
> 14285/1@1: <- libgo:runtime_SysReserve() = -1
> 14285/1@1: -> libgo:__go_assert_fail()
>
> If I remove the adjustment in runtime/malloc.goc (runtime_mallocinit),
> the test passes:
>
> 14445/1: mmap(0xFEF78114, 805306368, PROT_NONE, MAP_PRIVATE|MAP_ANON,
> -1, 0) = 0xCE00
>
> This stuff seems incredibly fragile, and I don't exactly understand
> why.
I don't understand why one case passes and the other fails. In an
attempt to make this work better, I committed the appended patch. It
will at least avoid asking for impossible situations, such as the one in
this example. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu (including the 32-bit tests, which I always run
anyhow). Committed to mainline.
Ian
diff -r 250b34075533 libgo/runtime/malloc.goc
--- a/libgo/runtime/malloc.goc Mon Oct 31 21:54:06 2011 -0700
+++ b/libgo/runtime/malloc.goc Mon Oct 31 22:18:21 2011 -0700
@@ -358,6 +358,8 @@
// away from the running binary image and then round up
// to a MB boundary.
want = (byte*)(((uintptr)end + (1<<18) + (1<<20) - 1)&~((1<<20)-1));
+ if(0x - (uintptr)want <= bitmap_size + arena_size)
+ want = 0;
p = runtime_SysReserve(want, bitmap_size + arena_size);
if(p == nil)
runtime_throw("runtime: cannot reserve arena virtual address space");
Re: Go patch committed: Update Go library
Rainer Orth writes:
> * The message points to the wrong line due to a broken test: malloc.goc
> has:
>
> p = runtime_SysReserve((void*)(0x00f8ULL<<32), bitmap_size +
> arena_size);
> if(p == nil)
> runtime_throw("runtime: cannot reserve arena virtual
> address space");
>
> On failure, p will be MAP_FAILED ((void *)-1), not nil, so the wrong
> assertion it thrown.
I fixed this particular issue as follows, copying the code from the
other Go library. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 1bc825e20b21 libgo/runtime/mem.c
--- a/libgo/runtime/mem.c Mon Oct 31 21:07:36 2011 -0700
+++ b/libgo/runtime/mem.c Mon Oct 31 21:53:12 2011 -0700
@@ -85,6 +85,7 @@
runtime_SysReserve(void *v, uintptr n)
{
int fd = -1;
+ void *p;
// On 64-bit, people with ulimit -v set complain if we reserve too
// much address space. Instead, assume that the reservation is okay
@@ -103,7 +104,11 @@
fd = dev_zero;
#endif
- return runtime_mmap(v, n, PROT_NONE, MAP_ANON|MAP_PRIVATE, fd, 0);
+ p = runtime_mmap(v, n, PROT_NONE, MAP_ANON|MAP_PRIVATE, fd, 0);
+ if((uintptr)p < 4096 || -(uintptr)p < 4096) {
+ return nil;
+ }
+ return p;
}
void
Re: Go patch committed: Update Go library
Rainer Orth writes:
> the only issue I've found on Solaris is the use of pthread_yield, which
> doesn't exist even on Solaris 11. The following patch checks for this,
> and falls back to thr_yield if available.
Rather than that patch, I changed the code to use sched_yield rather
than pthread_yield. I realized that libgo is already using sched_yield,
in runtime/go-sched.c. There shouldn't be any portability penalty to
also using it in yield.c.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 7135ea46b116 libgo/runtime/yield.c
--- a/libgo/runtime/yield.c Mon Oct 31 14:53:56 2011 -0700
+++ b/libgo/runtime/yield.c Mon Oct 31 14:58:19 2011 -0700
@@ -9,7 +9,7 @@
#include
#include
#include
-#include
+#include
#include
#ifdef HAVE_SYS_SELECT_H
@@ -38,7 +38,7 @@
void
runtime_osyield (void)
{
- pthread_yield ();
+ sched_yield ();
}
/* Sleep for some number of microseconds. */
Re: Go patch committed: Update Go library
Ian Lance Taylor writes:
> This patch updates the Go library to the most recent weekly release. I
> think the only potential portability issues here are the use of the
> ipv6_mreq struct. I'm not entirely sure the new exp/terminal package is
> portable, but it might be.
>
> I have not included the entire patch here, because it is too large and
> it's just copying changes anyhow. I've included all patches to files
> which are specific to the Go frontend version.
After this change, I'm seeing another issue: most 32-bit go execution
tests fail like this on Solaris 11/x86:
/vol/gcc/src/hg/trunk/local/libgo/runtime/malloc.goc:366: libgo assertion
failure
FAIL: go.go-torture/execute/array-1.go execution, -O0
Running the test under truss, I find:
14261: mmap(0xFF00, 805306368, PROT_NONE, MAP_PRIVATE|MAP_ANON, -1, 0)
Err#12 ENOMEM
With truss -u (user function tracing), I see:
14285/1@1: -> libgo:runtime_mallocinit()
14285/1@1:-> libgo:runtime_InitSizes()
14285/1@1:<- libgo:runtime_InitSizes() = 2
14285/1@1:-> libgo:runtime_SysReserve()
14285/1:mmap(0xFF00, 805306368, PROT_NONE, MAP_PRIVATE|MAP_ANON,
-1, 0) Err#12 ENOMEM
14285/1@1:<- libgo:runtime_SysReserve() = -1
14285/1@1:-> libgo:__go_assert_fail()
If I remove the adjustment in runtime/malloc.goc (runtime_mallocinit),
the test passes:
14445/1:mmap(0xFEF78114, 805306368, PROT_NONE, MAP_PRIVATE|MAP_ANON,
-1, 0) = 0xCE00
This stuff seems incredibly fragile, and I don't exactly understand
why. Besides, the assertion failure above is strange/wrong in two ways:
/vol/gcc/src/hg/trunk/local/libgo/runtime/malloc.goc:366: libgo assertion
failure
* I'd expect to see the message from runtime_throw() here, not just
`libgo assertion failure'.
* The message points to the wrong line due to a broken test: malloc.goc
has:
p = runtime_SysReserve((void*)(0x00f8ULL<<32), bitmap_size +
arena_size);
if(p == nil)
runtime_throw("runtime: cannot reserve arena virtual
address space");
On failure, p will be MAP_FAILED ((void *)-1), not nil, so the wrong
assertion it thrown.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Go patch committed: Update Go library
Ian Lance Taylor writes: > Thanks--but is sched_yield available? I realized that I misread the man > page; it looks like sched_yield is more portable than pthread_yield. It is, but before Solaris 11 it only lives in librt. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Go patch committed: Update Go library
Rainer Orth writes: > the only issue I've found on Solaris is the use of pthread_yield, which > doesn't exist even on Solaris 11. The following patch checks for this, > and falls back to thr_yield if available. Thanks--but is sched_yield available? I realized that I misread the man page; it looks like sched_yield is more portable than pthread_yield. Ian
Re: Go patch committed: Update Go library
Hello! > This patch updates the Go library to the most recent weekly release. I > think the only potential portability issues here are the use of the > ipv6_mreq struct. I'm not entirely sure the new exp/terminal package is > portable, but it might be. There are still problems with EpollEvent definition on Alpha, please see [1] for the analysis. [1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00457.html Uros.
Re: Go patch committed: Update Go library
Ian,
> This patch updates the Go library to the most recent weekly release. I
> think the only potential portability issues here are the use of the
> ipv6_mreq struct. I'm not entirely sure the new exp/terminal package is
> portable, but it might be.
the only issue I've found on Solaris is the use of pthread_yield, which
doesn't exist even on Solaris 11. The following patch checks for this,
and falls back to thr_yield if available.
It allowed i386-pc-solaris2.1[01] bootstraps to complete without
regressions.
Rainer
2011-10-27 Rainer Orth
* configure.ac: Check for .
Check for pthread_yield, thr_yield.
* configure: Regenerate.
* config.h.in: Regenerate.
* runtime/yield.c [HAVE_THREAD_H]: Include .
(runtime_osyield): Call thr_yield or pthread_yield if available.
diff --git a/libgo/configure.ac b/libgo/configure.ac
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -442,7 +442,7 @@ no)
;;
esac
-AC_CHECK_HEADERS(sys/mman.h syscall.h sys/epoll.h sys/ptrace.h sys/syscall.h sys/user.h sys/utsname.h sys/select.h sys/socket.h net/if.h)
+AC_CHECK_HEADERS(sys/mman.h syscall.h sys/epoll.h sys/ptrace.h sys/syscall.h sys/user.h sys/utsname.h sys/select.h sys/socket.h net/if.h thread.h)
AC_CHECK_HEADERS([linux/filter.h linux/netlink.h linux/rtnetlink.h], [], [],
[#ifdef HAVE_SYS_SOCKET_H
@@ -452,7 +452,7 @@ AC_CHECK_HEADERS([linux/filter.h linux/n
AM_CONDITIONAL(HAVE_SYS_MMAN_H, test "$ac_cv_header_sys_mman_h" = yes)
-AC_CHECK_FUNCS(srandom random strerror_r strsignal wait4 mincore setenv)
+AC_CHECK_FUNCS(srandom random strerror_r strsignal wait4 mincore setenv pthread_yield thr_yield)
AM_CONDITIONAL(HAVE_STRERROR_R, test "$ac_cv_func_strerror_r" = yes)
AM_CONDITIONAL(HAVE_WAIT4, test "$ac_cv_func_wait4" = yes)
diff --git a/libgo/runtime/yield.c b/libgo/runtime/yield.c
--- a/libgo/runtime/yield.c
+++ b/libgo/runtime/yield.c
@@ -9,6 +9,9 @@
#include
#include
#include
+#ifdef HAVE_THREAD_H
+#include
+#endif
#include
#include
@@ -38,7 +41,11 @@ runtime_procyield (uint32 cnt)
void
runtime_osyield (void)
{
+#ifdef HAVE_THR_YIELD
+ thr_yield ();
+#elif defined(HAVE_PTHREAD_YIELD)
pthread_yield ();
+#endif
}
/* Sleep for some number of microseconds. */
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
