Jack Howarth <howa...@bromo.med.uc.edu> writes: > The current gccgo branch (at r166931) fails to bootstrap on > x86_64-apple-darwin10 > using...
Thanks for trying it. If you fix that problem, you're going to have other problems too. Specifically, I know that it's going to fail to create a .go_export section because the assembler is going to complain about bad syntax. Although one nice consequence of my simple_object work is that if we can get the section created correctly we might be able to read it at import time without further work. I don't know what will fail after that problem is fixed. I would certainly like gccgo to work on Darwin, and, for that matter anywhere other than GNU/Linux and RTEMS. But I can not commit to fixing anything other than GNU/Linux myself. I'm going to have to rely on other people for that. Sorry to be blunt, but I'm just one person, and there is no feasible alternative. I am not going to let this issue hold up the merge. Go will not be enabled by default, so the merge will not break any builds which do not explicitly enable Go. > ../../../gccgo/libgo/runtime/go-go.c:379:29: error: ‘SIGRTMIN’ undeclared > (first use in this function) The issue here is that in the current implementation the garbage collector requires two signals: one to tell a thread that a garbage collection is starting and one to tell a thread that it is complete. The current code does this: #define GO_SIG_START (SIGRTMIN + 1) #define GO_SIG_STOP (SIGRTMIN + 2) because I can be reasonably confident that no Go program expects to do anything with those signals (a Go program which links with a C library which uses those signals in some other way is going to fail, yes; suggestions welcome). I'm a little surprised to hear that Darwin doesn't have real time signals. I think they've been in POSIX for about 15 years now. Perhaps some preprocessor define makes them available? If not, then somebody familiar with Darwin is going to have to pick two other signals for Darwin. The Go code does not actually need the special properties of real-time signals; any unused signal should suffice. Ian
