------- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-01-15 19:08 ------- I've just run into this problem too.
In earlier versions of Aaron's shared libgcc patch, we extracted ctors.o and chkstk.o and placed them whole into the import lib. I'm not sure why he didn't do this in the committed version, but it has the effect that you have to link against the static libgcc as well as the shared one in order to let it fill out any missing references. I'm not sure I'm entirely comfortable with that, although I can't think of any obvious problem, but it seems wrong to link against such a duplicated body of code to me, and I think I'd prefer the import lib solution for cygwin's compiler. (We want -shared-libgcc as the default, for greater unixness). In a way, there's an impedance mismatch in the libgcc build system; you can add new functions per-target to the static library, by listing them in the target makefile fragment, but there's no similar target fragment to let you define extra exports in the libgcc mapfile/version script. I'm going to prepare a patch that revises shared libgcc building. I'll put it in the cygwin-specific fragment as an override of the defaults from the shared fragment, and it's probably going to do more than just fix chkstk/ctors, so it won't be suitable for mingw, but the mingw team might or might not want to consider doing the same. BTW someone who has admin powers should set confirm this bug, it's definitely real! :) cheers, DaveK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660