On 09/06/2006, at 7:24 AM, Jack Howarth wrote:
Geoff, I don't seem to have access to read... <rdar://problem/4428696> a strong symbol in a dylib should not override a weak private extern symbol Does the radar report describe any workarounds?
As far as I know, there are no workarounds other than to avoid the problem (by linking against the shared libgcc).
Does this mean the problem is actually in cctools?
Probably.
Also, the problem doesn't happen with gcc 4.1.1 (but only with 4.2). At this point, I am considering sampling the snapshots for 4.2 and see if I can identify which snapshot caused the breakage in xplor-nih.
I believe when I looked at this, some routines from the newer libgcc.a were being used and some from the older libgcc_s.1.dylib, but internal libgcc data structures had changed causing the problem.
smime.p7s
Description: S/MIME cryptographic signature
