From: Dave K. <dav...@ar...> - 2008-06-04 12:20:32
|
Danny Smith wrote on 29 May 2008 23:24: > The startup code for shared libgcc in 4.2.1 and in 4.3.0 is very buggy. > In 4.3.0 I suspect that EH registration functionality in your test case > is using "weak" static libgcc symbols, which effectively means that EH > code is not linked in. For shared libgcc, I thought those -u options in the specs were supposed to take care of it? And anyway, the startup code does a dynamic lookup, so if anything at all has brought the dll in, it ought to find the register/deregister frame functions, no? Perhaps also related: http://gcc.gnu.org/ml/gcc/2008-05/msg00381.html plus attached patch. I've been experimenting with fully static libgcc, fully shared libgcc, and a hybrid combination of shared-libgcc-with-static-libgcc_eh, and found I had to work round an optimisation bug to get it to work all three ways. cheers, DaveK -- Can't think of a witty .sigline today.... |