John Darrington wrote:
[ Cross posting to address@hidden and address@hidden ]
This was reported as a bug to address@hidden some weeks ago.
However,
the readline maintainer said that there was a reason for this:
http://lists.gnu.org/archive/html/bug-readline/2009-06/msg00000.html
I must admit, I didn't quite follow the logic. Perhaps somebody more
familiar with readline could explain how to resolve this.
Readline is GNU software, and, as such, uses xmalloc/xfree/xrealloc
to do
its memory allocation with the usual GNU semantics. Since those
functions
are global, they're exported by the library and available for
applications
using readline to use.
Traditional Unix linker semantics, even in the presence of shared
libraries, allow applications and other libraries to override (shadow)
symbol definitions. This allows, for example, bash to provide its own
implementation of getenv() that looks in the shell's table of exported
variables instead of the initial shell environment.
The basic idea is that the linker keeps a list of unresolved symbols
as it processes libraries, beginning to end as they're specified on
the command line, and doesn't link in already-resolved symbols from
libraries on a per-file basis.
It's often desirable, and in some cases required, that applications
unify
their memory allocation in one set of functions. To accommodate this,
Readline uses public functions to do its memory allocation, which,
using
the traditional Unix linker semantics, allows an application to
provide
its own definitions of xmalloc/xrealloc/xfree and have Readline use
them.
Readline provides its own definitions in case the application does
not.
It seems that Mac OS X, with its peculiar shared library semantics,
has
broken this. You might try linking against a static version of the
readline library, if you have one installed in /opt/local/lib.
Chet