Geoff,
When building xplor with -shared-libgcc -whyload, I don't see any
explicit symbols being loaded from libgcc_s. However from
libxplorCmd.dylib, which has code called from xplor, I see...
/usr/lib/libgcc_s.1.dylib(unwind-dw2_s.o) loaded to resolve symbol:
__Unwind_Resume
/usr/lib/libgcc
On 31/05/2006, at 6:19 PM, Jack Howarth wrote:
If I take the link line generated for -shared-libgcc and substitute
the
the static libgcc, the resulting xplor binary doesn't abort on the
throw.
Also if I take the link line generated without -shared-libgcc and add
"-lgcc_s.10.4", the resultin
Geoff,
I should clarify my last comments. After looking at this some more it
appears that abort occurs unless I link in libgcc_s.10.4. That is both...
"/sw/lib/gcc4/libexec/gcc/powerpc-apple-darwin8/4.2.0/collect2" "-dynamic"
"-arch" "ppc" "-weak_reference_mismatches" "non-weak" "-o" "xplor"
Geoff,
I am seeing...
gcc-4 -### -o xplor xplor.o \
\
-L. -lxplorCmd -lxplor -L/Users/howarth/Desktop/xplor-nih-2.14/bin.Darwin_8/
-lfft -lintVar -lvmd -lpy -lswigpy-xplor -ltclXplor -lswigtcl8-xplor -lnmrPot
-lcommon -lmarvin \
-L/System/Library/Frameworks/Python.framework/Versions
On 31/05/2006, at 4:59 PM, Jack Howarth wrote:
Geoff,
Nice call. If I relink xplor with 'gcc -shared-libgcc', the
program
no longer aborts on the throw in the c++ code. As before, if I remove
the '-shared-libgcc' and link with gcc, I get the abort on the throw.
Anything else can provide
Geoff,
Nice call. If I relink xplor with 'gcc -shared-libgcc', the program
no longer aborts on the throw in the c++ code. As before, if I remove
the '-shared-libgcc' and link with gcc, I get the abort on the throw.
Anything else can provide to help pin this problem down? I did test
current gcc
On May 30, 2006, at 9:14 PM, Jack Howarth wrote:
I am able to suppress the aborts on the throw in xplor-nih when
built under gcc 4.2 if I link the main xplor program with g++ rather
than gcc. Should this be considered a regression from gcc 4.0/4.1?
Don't know, as we don't know what the bug is y
[EMAIL PROTECTED] (Jack Howarth) writes:
> Mike,
>Actually the problem appears unrelated to cxa_atexit as neither
> -fuse-cxa-atexit nor -fno-use-cxa-atexit eliminates the problem
> with the throw aborting the program.
>I do believe I have found a work-around to the problem which
> identi
Mike,
Actually the problem appears unrelated to cxa_atexit as neither
-fuse-cxa-atexit nor -fno-use-cxa-atexit eliminates the problem
with the throw aborting the program.
I do believe I have found a work-around to the problem which
identifies the nature of the issue as well. The xplor-nih pr
On May 30, 2006, at 3:25 PM, Jack Howarth wrote:
...and I get no hits suggesting it can't be a wrong visibility
problem.
I prefer the idea that it reduces the likelihood of such a problem. :-)
Is there some approach I can use to figure out if it is a throw across
a dylib or bundle boundary?
Mike,
I've checked all of the object files in xplor-nih with...
nm -m *.o | c++filt | grep info | grep -v external
...and I get no hits suggesting it can't be a wrong visibility problem.
Is there some approach I can use to figure out if it is a throw across
a dylib or bundle boundary? My initi
On May 29, 2006, at 1:17 PM, Jack Howarth wrote:
In building xplor-nih against the gcc trunk, I noticed that there
is a c++ related
regression
I'll let Andrew comment if it sounds like anything he's seen. I'd
recommend a binary search to narrow down the translation unit and the
compiler
12 matches
Mail list logo
