dylib linking

[Peter O'Gorman]

On 06/26/2010 06:42 PM, Jordan K. Hubbard wrote:
> I'll bet if you flattened the dyld namespace in this particular scenario, this problem would go away.  -flat_namespace is generally not a first recommendation, but if you know what you're doing it has its place.
>
> - Jordan
>
> On Jun 25, 2010, at 10:05 PM, Jeremy Lavergne wrote:
>
>> If you're well-versed in linking, feel free to check out the rest
>> of
the email and maybe look at the source code from the pspp-devel port.
>>


Hmm, Mac OS X has a getopt_long and optarg, why are libggl and libpspp 
using a replacement?

Anyway, these libraries are both defining a global rpl_optarg symbol, on 
Linux you won't get the symbol, it should use the one in glibc, so no 
problem, everywhere else - problem.

Having multiple definitions of the same symbol in the same process has 
not been known to lead to peace and happiness. If either library is 
under your control, use the GNU libtool option to limit exported 
symbols, or check that whatever is providing the rpl_optarg is doing it 
right (likely the fault is autoconf or gnulib).

Peter


>>
>> We just fixed a fairly major upstream bug when building PSPP on Mac
>> OS X, but I'm curious if there isn't a pair of knowledgeable eyes
>> that could point out why it happened: the Mac appears to be acting
>> exceptional in this case. I feel it's likely a case of doing it
>> wrong but my insight on linking is limited.
>>
>> Thanks for your input!
>>
>> Begin forwarded message:
>>
>>> Both libpspp.la and libpspp-core.la linked directly against
>>> libgl.la, and the UI linked against both libpspp.la and
>>> libpspp-core.la.  This works fine on ELF systems, but with Mach-O
>>> on Mac OS X it silently causes duplicate symbols at runtime.  In
>>> particular there are two different copies of rpl_optarg from
>>> libgl.la.  Different code sees different copies of these, which
>>> causes a segfault at runtime whenever anyone invokes pspp with an
>>> option that takes an argument.
>>>
>>> Reported by Jeremy Lavergne<jeremy at lavergne.gotdns.org>, with
>>> debugging assistance by Jeremy and by John Darrington. ---