Comment 1:

Debian GNU/kFreeBSD is a somewhat hybrid system, i.e. FreeBSD kernel but glibc.
Because we inherently tie libc to kernel, so if we want to support Debian GNU/kFreeBSD,
we might need to add kFreeBSD to the GOOS (but this will duplicate some code).
BTW, one of the patch is unnecessary if we support detecting dynamic linker
automatically.

Comment 2:

Hi,
[Debian tracking bug for this: http://bugs.debian.org/668794]
I had a comment from our KFreeBSD porter which is very relevant to this issue:
On Mon, Apr 16, 2012 at 00:04, Robert Millan <rmh@d.o> wrote:
> Hi Ondřej,
>
> I notice you disabled the golang testsuite because it hangs on
> GNU/kFreeBSD.  However, the problem is still present, and chances are
> it makes golang unusable on that platform.
>
> I gave the source a look, and it seems that on GNU/kFreeBSD golang is
> playing with thread primitives, bypassing libc.  For example it
> invokes thr_new() kernel call directly, and also calls sigprocmask()
> to reset the signal mask in code that is clearly multithreaded [1].
>
> This means that either golang intends to completely replace
> libpthread, or it intends to play along with existing libpthread.  I'm
> not sure which one applies here, but in both cases there is a problem
> that needs to be fixed in golang.
>
> So please don't disable the testsuite.  If golang can't be built on
> GNU/kFreeBSD, unless you know it's a bug in the system libraries the
> problem needs to be fixed in golang.  If nobody can spend the time to
> fix it here, then you should consider not providing the package for
> kfreebsd-*.
>
> [1] On multithreaded programs, use of sigprocmask() is reserved to
> system libraries.
>
> --
> Robert Millan

Comment 3:

On Mon, Apr 16, 2012 at 00:04, Robert Millan <rmh@d.o> wrote:
> I gave the source a look, and it seems that on GNU/kFreeBSD golang is
> playing with thread primitives, bypassing libc.  For example it
Yes.
> invokes thr_new() kernel call directly, and also calls sigprocmask()
> to reset the signal mask in code that is clearly multithreaded [1].
>
> This means that either golang intends to completely replace
> libpthread, or it intends to play along with existing libpthread.  I'm
Yes, when cgo isn't used, the go runtime intentionally bypasses libc and
libpthread, as we manage threads and memory ourselves.
> not sure which one applies here, but in both cases there is a problem
> that needs to be fixed in golang.
In a word, we tie libc/kernel combination to the OS, so AFAIK, we don't
support GNU/kFreeBSD now.

Comment 4:

Ok, in that case, I am going to drop GNU/KFreeBSD packages from Debian at this moment.
That would be probably best course of action to not leave user with broken Go at that
platform.

Comment 5:

Should we add GNU/kFreeBSD as a new GOOS?

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

Comment 6:

Does the build succeed if you export CGO_ENABLED=0 first?

Comment 7:

> Does the build succeed if you export CGO_ENABLED=0 first?
The build did succeed, it's the tests which hang and are killed.
Or are you also asking if the tests not hang with CGO_ENABLED=0? I can certainly try
that (tomorrow)...

Comment 8:

:: Or are you also asking if the tests not hang with CGO_ENABLED=0?
yes

Comment 9:

I installed a Debian GNU/kFreeBSD 6.0 amd64 (with FreeBSD kernel 8.1.1) on a VM, and
tested that with just 
this patch:
http://anonscm.debian.org/gitweb/?p=pkg-google/golang.git;a=blob;f=debian/patches/011-__FreeBSD_kernel__.patch;h=45be34f1229c2ac40875ad3241f1d367d726173f;hb=a90cb12bf263a06fbe2e08978a6010138b672260
CGO_ENABLED=0 could pass all the tests, so at least go can be packaged for GNU/kFreeBSD
amd64
(albeit without support for cgo).
I'm willing to help do the cgo port, but I must know the answer to this question:
should kfreebsd be a new GOOS, or we treat it as variant of FreeBSD and distinguish it
from FreeBSD
by 'defined(__FreeBSD_kernel__)' only when necessary?
(my guess is that, if we don't want to merge the port, the second option is better)

Comment 10:

I've made CL 6086043 to address the hardcoded dynamic linker problem,
if it's merged, you can drop patch: 007-use_native_dynamic_linker_on_kfreebsd.patch

Comment 11:

I'm afraid, the only remaining option is treat kfreebsd a new GOOS.
because we have a pkg/runtime/cgo/freebsd.c, which is only for FreeBSD's libc,
as it is compiled by 8c/6c, we can't use 'defined(__FreeBSD_kernel__)' trick.

Comment 12:

the cgo port must wait until glibc kfreebsd has saner libpthread implementation,
or we use libpthread's synchronization primitives instead of umtx_op when using cgo.

Labels changed: added priority-someday, removed priority-later.

Comment 13:

Labels changed: added repo-main.

Comment 14:

Adding Release=None to all Priority=Someday bugs.

Labels changed: added release-none.