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
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
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 doe
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 ar
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/libg
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_in
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 execut
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 -
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 mig
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
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 v
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_yi
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
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 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 lo
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 d
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
17 matches
Mail list logo
