| 1 |
On Thu, 27 May 2010 08:26:50 +0200 |
| 2 |
Fabian Groffen <grobian@g.o> wrote: |
| 3 |
|
| 4 |
> On 27-05-2010 09:23:30 +1000, Matt Michalowski wrote: |
| 5 |
> > Hi all - first, a little test program, test.cpp: |
| 6 |
> [snip] |
| 7 |
> > When I compile this with my XCode g++ (gcc version 4.2.1 (Apple Inc. |
| 8 |
> > build 5659)) , it works as expected: |
| 9 |
> > $ /usr/bin/g++ -o test test.cpp |
| 10 |
> > $ otool -L ./test |
| 11 |
> > ./test: |
| 12 |
> > /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, |
| 13 |
> > current version 7.9.0) |
| 14 |
> > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, |
| 15 |
> > current version 125.0.1) |
| 16 |
> > $ ./test |
| 17 |
> > Caught runtime_error: runtime_error |
| 18 |
> > |
| 19 |
> > However, with my gentoo-alt gcc-apple g++ (gcc version 4.2.1 (Gentoo |
| 20 |
> > 4.2.1_p5659, Apple Inc. build 5659): |
| 21 |
> > $ g++ -o test test.cpp |
| 22 |
> > $ otool -L ./test |
| 23 |
> > ./test: |
| 24 |
> > /Users/mattm/gentoo/usr/lib/gcc/x86_64-apple-darwin10/4.2.1/libstdc++.6.dylib |
| 25 |
> > (compatibility version 7.0.0, current version 7.9.0) |
| 26 |
> > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, |
| 27 |
> > current version 125.0.1) |
| 28 |
> > $ ./test |
| 29 |
> > terminate called after throwing an instance of 'std::runtime_error' |
| 30 |
> > Abort trap |
| 31 |
> > |
| 32 |
> > I've tried a few flags (-fexceptions, etc.), but I still can't get |
| 33 |
> > any C++ code compiled with the gentoo-alt gcc-apple to catch |
| 34 |
> > exceptions properly. Any ideas? |
| 35 |
> |
| 36 |
> Compare the sizes of both programs. We noticed this problem a while |
| 37 |
> ago, because the linker (ld) is crashing on Snow Leopard when it tries |
| 38 |
> to issue an error (it throws it). I don't recall the exact details |
| 39 |
> any more, but for some reason if you do a static link, it does work. |
| 40 |
> The responsible objects seem to be not working when invoked |
| 41 |
> dynamically or something. heiko_ actually dived into it, but we were |
| 42 |
> never able to solve the problem. (And it doesn't show up on Tiger |
| 43 |
> and Leopard.) |
| 44 |
> |
| 45 |
> |
| 46 |
|
| 47 |
Yeah, darwin10 changed the lookup of global program data (such as |
| 48 |
exceptions). Where keymgr was used before, it seems that libunwind |
| 49 |
(unfortunately closed) is used instead. The problem relies in removing |
| 50 |
those libunwind .eh_frame setup calls from our ld64 to make it compile. |
| 51 |
Thus we probably remove the proper setup for libSystem's lookup of |
| 52 |
exception data through a properly setup .eh_frame. |
| 53 |
|
| 54 |
__keymgr_initializer() in [1] is pretty nice commented: |
| 55 |
|
| 56 |
" /* On Mac OS X 10.6, unwinding is down by libunwind in |
| 57 |
libSystem.B.dylib */" |
| 58 |
|
| 59 |
and |
| 60 |
|
| 61 |
" /* On Mac OS X 10.6, libunwind in libSystem.dylib implements all |
| 62 |
unwinding functionality. */ /* libunwind does not use keymgr, so there |
| 63 |
is no need to maintain KEYMGR_GCC3_LIVE_IMAGE_LIST */ /* in sync with |
| 64 |
dyld's list of images. But there might be some i386 or ppc |
| 65 |
applications that */ /* carry around there own copy of the unwinder |
| 66 |
(from libgcc.a) and need KEYMGR_GCC3_LIVE_IMAGE_LIST. */" |
| 67 |
|
| 68 |
The second part regarding libgcc.a could probably also be what grobian |
| 69 |
described -- maybe static(-libgcc) programs have their own unwinder |
| 70 |
onboard and thus magically work. |
| 71 |
|
| 72 |
Looks like another open c-project of Apple moved to a (yet) closed |
| 73 |
c++-overkill project. |
| 74 |
|
| 75 |
I wonder if specifying "-static-libgcc" or "-mmacosx-version-min=older |
| 76 |
macos version" for the c++ program to be compiled would make things |
| 77 |
work for now? Testers welcome ;) |
| 78 |
|
| 79 |
|
| 80 |
-- Heiko |
| 81 |
|
| 82 |
|
| 83 |
[1] http://opensource.apple.com/source/keymgr/keymgr-22/keymgr.c |
Archives