[Bug-gnulib] Re: Multiple definitions of symbol _xalloc_die

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

> Simon Josefsson wrote:
>> I guess I want the linker to resolve the xalloc_die
>> symbol "internally" within libshishi.
>
> Although it's possible to do so, I wouldn't recommend that because
>   1) It doesn't work when you link statically,
>   2) Reducing the visibility of a symbol in platform dependent (different on
>      ELF, AIX, Woe32; I don't even know whether it's supported on MacOS X),
>      and libtool doesn't support this functionality. So by using this
>      feature you're bound to become a libtool pioneer :-)

Right, I have been avoiding the -export-symbols stuff for similar
reasons.

>> It would help me understand this better, if you could explain why the
>> same doesn't apply to, say, xmalloc which is also in both libgss and
>> libshishi (via gnulib)?  Why isn't the linker complaining that xmalloc
>> is defined both in libgnulib and libshishi, when creating libgss?
>
> No idea.(*) But sure, you have to use the -D trick for xmalloc as well since
> you want to have semantically different copies in each library.

Actually, I don't care about overriding xmalloc.  Being able to
override it might even be useful for someone.

All this (i.e., having a gnulib copy inside two different libraries)
seem like a potentially large problem.  However, because I have never
encountered any problems with this approach, before the xalloc_die
problem, that suggest I'm missing some other clue that would explain
the xalloc_die problem.

If the linker compare object code, it sounds inevitable that linking a
program with two of my libraries that use gnulib will fail.  Library X
may use gnulib version from date X', but library Y use gnulib from
date Y', so the code could differ.  So if the linker compare object
code, and refuse to link the library when there is a collision, things
will be bad.

But '-Dxalloc_die=$PROJECT_xalloc_die' sounds like a simple solution
to the symptom I'm seeing now.

Thanks.