[Top][All Lists]
[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!
- [Bug-gnulib] Multiple definitions of symbol _xalloc_die, Simon Josefsson, 2004/10/15
- Re: [Bug-gnulib] Multiple definitions of symbol _xalloc_die, Bruno Haible, 2004/10/15
- [Bug-gnulib] Re: Multiple definitions of symbol _xalloc_die,
Simon Josefsson <=
- Re: [Bug-gnulib] Re: Multiple definitions of symbol _xalloc_die, Bruno Haible, 2004/10/15
- [Bug-gnulib] Re: Multiple definitions of symbol _xalloc_die, Simon Josefsson, 2004/10/15
- [Bug-gnulib] Re: Multiple definitions of symbol _xalloc_die, Bruno Haible, 2004/10/15
- [Bug-gnulib] Re: Multiple definitions of symbol _xalloc_die, Simon Josefsson, 2004/10/15
- Re: [Bug-gnulib] Re: Multiple definitions of symbol _xalloc_die, Bruno Haible, 2004/10/15
- [Bug-gnulib] Re: Multiple definitions of symbol _xalloc_die, Simon Josefsson, 2004/10/15
- Re: [Bug-gnulib] Re: Multiple definitions of symbol _xalloc_die, Bruno Haible, 2004/10/15