------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=664
Daniel Johnson <daniel@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |daniel@???
--- Comment #11 from Daniel Johnson <daniel@???> 2008-03-22 00:29:50 ---
(In reply to comment #10)
> } Symbol-munging is not guaranteed to be stable between different
> } compiler versions. It appears that the patch relies on this specific
> } munge for "any gcc major-version >= 3", which is at best fairly
> } fragile. For example, I know C++ code compiled by gcc3.1 is not
> } compatible with that compiled by gcc3.3 on OS X.
>
> That's true, but if the ABI changes between compiler versions, you
> won't be able to use an old library anyway. The whole point of this
> munged symbol is to allow exactly that kind of backwards
> compatibility. In other words, if you're compiling pcre with gcc3.3
> on OS X, you won't be able to use it with binaries compiler with
> gcc3.1 in any case -- as you say, the ABI has changed -- so the fact
> this symbol might break (which, in fact, it doesn't in that particular
> case) doesn't matter.
>
> I talked with folks on the gnu compiler tools team, and was assured
> this solution is as robust as any.
Unfortunately, this patch doesn't work on OS X. I get:
/bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -g -Os
-c -o pcrecpp.lo pcrecpp.cc
g++ -DHAVE_CONFIG_H -I. -g -Os -c pcrecpp.cc -fno-common -DPIC -o
.libs/pcrecpp.o
pcrecpp.cc:65: error: only weak aliases are supported in this configuration
But a weak alias doesn't help since the symbol is still undefined. This is with
Apple's gcc 4.0.1
Daniel
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
