On Fri, Nov 19, 2010 at 12:16:43PM -0800, Ian Lance Taylor wrote: > 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, Actually, darwin doesn't use the boehm-gc/pthread_stop_world.c containing the SIGRTMIN code. There is an entirely separate boehm-gc/darwin_stop_world.c for the thread handling on darwin. While boehm-gc/pthread_stop_world.c is compiled on darwin, the code in it is skipped because of the... #if defined(GC_PTHREADS) && !defined(GC_SOLARIS_THREADS) \ && !defined(GC_WIN32_THREADS) && !defined(GC_DARWIN_THREADS) ...wrapper. Jack > > Ian