On Sat, 22 Mar 2008, Craig Silverstein wrote:
> I think there are two options going forward:
>
> 1) Conditionally comment out the alias code for mach-o systems, and
> just live with the fact there is an ABI break between pcre 7.4 and
> 7.6 for those systems; or
>
> 2) Roll back the change I made that broke the ABI in the first place.
> This would mean that the problem it fixed -- something to do with
> windows compilation, but only in certain compile modes -- would
> remain broken.
>
> I think that the change in question not only fixes a bug but is also
> cleaner, and I wish we had coded it that way originally (thus avoiding
> any ABI-regression issues as well...) But we didn't, so I'm not sure
> what the best way to go is. Philip, I guess the final word is yours.
I don't think we should back out the patch, because it did fix a bug
that was causing grief. So I would go for (1).
On Sat, 22 Mar 2008, Ian Lance Taylor wrote:
> I am not an expert on Mach-O, but my reading of the gcc source code is
> that aliases are supported, but they have to be weak.
Is that the same as Craig's suggestion below, which Daniel reports does
not work?
On Sat, 22 Mar 2008, Daniel Johnson wrote:
> > extern Arg no_arg __attribute__((weak, alias("_ZN7pcrecpp2RE6no_argE")));
>
> No, I already tried that. While running the tests I get:
>
> dyld: Symbol not found: __ZN7pcrecpp6no_argE
> Referenced from:
> /sw/src/fink.build/pcre-7.6-3/pcre-7.6/.libs/libpcrecpp.0.dylib
> Expected in: dynamic lookup
>
> The symbol __ZN7pcrecpp6no_argE gets created, but is marked undefined in the
> symbol table. But I guess that's kind of the point of weak symbols. :)
> Something has to actually define it at runtime. I don't really have another
> suggestion for you, I'm afraid. Linking issues aren't my speciality.
I'm afraid I know very little at all about linking.
Philip
--
Philip Hazel
