bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Simon Josefsson
Subject: [Bug-gnulib] Re: Multiple definitions of symbol _xalloc_die
Date: Fri, 15 Oct 2004 18:29:31 +0200
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

Bruno Haible <address@hidden> writes:

> Simon Josefsson wrote:
>> Do you know if there is a solution to this?
>
> You could avoid linking with ext.o.

Then libgss would use the xalloc_die inside libshishi, and that's bad
because they are slightly different.

> But probably it's better to think about the situation:
>   - Is libgss an application or a library? If it is a library, do the
>     application authors want their application to crash with a core dump
>     (after abort()) when memory is tight? (E.g. do you want your browser
>     or text editor to crash because of a problem in a library?)
>   - Is the desired memory allocation failure behaviour always the same
>     for all possible users of libshishi? Or does it depend on the application
>     that uses libshishi? In the latter case, what's the API through which
>     the application installs the error handler?
>   - Same question for libgss.

Sorry, I should have explained in more detail.  Both libgss and
libshishi are libraries.  Both should provide a hook back to the
application, to recover from memory errors.  They have, respectively:

void (*shishi_alloc_fail_function) (void) = 0;
void (*gss_alloc_fail_function) (void) = 0;

The application can set the variable to get a callback instead of a
crash.  I have not yet been convinced that handling malloc errors
explicitly (rather than crashing, or possible abort via a callback) is
worth the cost.

Both libgss and libshishi link with gnulib's xmalloc.c, and they
implement xalloc_die.  It would not be good to force applications to
implement xalloc_die, my libraries should be self contained.

Both libgss and libshishi uses gnulib-tool --import, i.e., there is a
libgnu.la that contain xmalloc.o etc and is linked into libgss.la and
libshishi.la.

The problem occurred when linking libgss, which uses libshishi, but
that is not important -- for example, I have libgsasl (which will also
use xalloc_die soon) that uses both libgss and libshishi directly.  I
would guess it will have the same problem.

It seems to me that the Mac OS X linker is too picky.  On all other
systems, the linker presumably just ignore the xalloc_die inside
libshishi when linking libgss.  I guess what I'd like to know if this
is a Mac OS X linker bug, or something I can solve in some clean way.

Thanks!





reply via email to

[Prev in Thread] Current Thread [Next in Thread]