Thanks to Andrew Haley who found out what the problem was we have been able to
resolve.  Here is Andrew's e-mail on the problem:

The problem is that you have linked frysk in such a way that it uses
part of libunwindand part of libgcc for exception handling .  So,
symbol resolution in FryskGui goes like this:

     4411:     binding file /lib/libc.so.6 [0] to /lib/libgcc_s.so.1 [0]: normal
symbol `_Unwind_Find_FDE' [GCC_3.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /usr/lib/libgcj.so.7
[0]: normal symbol `_ZN14_Jv_StackTrace13UnwindTraceFnEP15_Unwind_ContextPv'
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_Backtrace' [GCC_3.3]
     4411:     binding file /lib/libgcc_s.so.1 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_Find_FDE' [GCC_3.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_GetRegionStart' [GCC_3.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_GetIP' [GCC_3.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_RaiseException' [GCC_3.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_GetLanguageSpecificData' [GCC_3.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_GetIPInfo' [GCC_4.2.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_SetGR' [GCC_3.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]:
normal symbol `_Unwind_SetIP' [GCC_3.0]
     4411:     binding file /usr/lib/libgcj.so.7 [0] to
./frysk-gui/frysk/gui/FryskGui [0]: normal symbol `_Unwind_Resume' [GCC_3.0]

Note that all of libgcj's exception handling is linked to
libgcc_s.so.1 except for `_Unwind_Resume', which is linked to the
libunwind version of that symbol that is built into FryskGui.  As far
as I can see this can never work, because the context structure used
in `_Unwind_RaiseException' and `_Unwind_Resume' must be the same, and
they must be satisfied from the same library.

FryskGui exports just _one_ libunwind function, and as soon as it gets
called the program crashes.
-bash-3.1$ nm ./frysk-gui/frysk/gui/FryskGui | grep _Unwind_
083af4e0 T __libunwind_Unwind_Resume
083af4e0 T _Unwind_Resume


So, the way to fix frysk is to make sure that libgcc_s.so is in the
link path before libunwind.  This causes the libunwind version of
_Unwind_Resume not to be put into FryskGui.

I linked FryskGui like this:

...
mports/elfutils/libdw/:/home/aph/frysk-libunwind/build/frysk-gui/../frysk-imports/elfutils/libdwfl/:/home/aph/frysk-libunwind/build/frysk-gui/../frysk-imports/elfutils/libebl/:/home/aph/frysk-libunwind/build/frysk-gui/../frysk-imp\orts/elfutils/libelf/:/home/aph/frysk-libunwind/build/frysk-gui/../frysk-imports/libunwind/src/:/home/aph/frysk-libunwind/build/frysk-gui/../frysk-sys/:./elfutils/libdw
\
-Dgnu.gcj.runtime.NameFinder.demangle=false \
-Dgnu.gcj.runtime.NameFinder.use_addr2line=false \
-lgcc_s \
frysk/gui/FryskGui.o \
libfrysk-gui.a \
../frysk-gtk/libfrysk-gtk.a ...

This problem is really due to mixing dynamic and static libraries.  I
imagine -- but I haven't tried -- that if you used a dynamically
linked version of libunwind it would be OK.

Andrew.


P.S.  gcj on trunk doesn't call `_Unwind_Resume' at all; this is a 4.1 issue.



I resolved the problem for now by forcing the gcc library to be searched for
symbol resolution before libunwind by putting an "-lgcc_s" before the
libunwind.a in the link statement.  This lets us statically link libunwind.a.

Rick, where exactly is the offending symbol in libunwind (I've my doubts that
linking shared would fix it); and can it be renamed or removed locally?

From what I can tell from the conversations with Andrew Haley the offending
symbol is "_Unwind_Resume".  This symbol seems to be used by both libgcj and
libunwind.

I did try to link shared by replacing the libunwind.a with
-L../frysk-imports/libunwind/src and that did indeed fix the problem.  So, when
libunwind is linked in statically, that symbol gets resolved out of that library
at runtime and the shared stuff gets searched later it seems.  Linking in
libunwind shared, the symbol gets plucked out of the libgcj library first and
all is well.

I thought that we would prefer most libraries be linked statically, so I chose
to add the "-lgcc_s" line in the link before the libunwind.a lib so the symbol
would be resolved from the libgcj library and we could still link libunwind in
statically.