Re: [Bug-readline] please rename xmalloc

[Tom Tromey]

>>>>> "Chet" == Chet Ramey <address@hidden> writes:

>> Currently gdb provides its own xmalloc in the main executable.  This
>> overrides the readline xmalloc.  However, while experimenting with
>> removing gdb's copy in favor of the libiberty xmalloc, I tripped across
>> the readline copy.  Having gdb use libiberty's fails because then gdb
>> tries to link against two libraries that each provide their own xmalloc.

Chet> That's an interesting problem.  Traditional linker behavior would suggest
Chet> that the first library to provide the symbol wins.

Sorry, I was incomplete in my note.

I can dig a bit deeper but I suspect the issue is indeed that the
readline .o file is picked up by the link -- but then the libiberty .o
file is picked up as well, because it defines xcalloc, which is also
used by gdb.

gdb actually wants a bit more control over the semantics of xmalloc; in
particular it wants to control what happens on alloc failure.  libiberty
is easy to hack to let us do this, since it is part of our maintenance
domain.

Hmm, maybe for us the best thing really is to patch out the
xmalloc/xrealloc functions in the in-tree readline, for this reason.
That is, this approach would let us override the readline allocators,
too; whereas a rename to "rl_malloc" or whatever would require a new
function to do the same.

Chet> Which version of readline are you using?

6.2 is in the tree now.

Chet> Readline-6.1 provided `xfree' in the same file as xmalloc and
Chet> xrealloc, and doing so caused the linker to drag in readline's
Chet> xmalloc.o, resulting in multiple symbol definitions.

Yeah, this is the case in 6.2 as well.

Tom