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

Re: readline, editline, sl and snprintf

>>>>> "Derrick" == Derrick J Brashear <shadow@dementia.org> writes:

    Derrick> you're honing in on vasprintf. you shouldn't be. it weas
    Derrick> just the first symbol in snprintf.o that i got an error
    Derrick> for.

Short version:
My guess is you have an earlier version of Heimdal, before libeditline
was converted to use libtool. This will cause a number of different
problems, like this one.

Long version:
There are three issues here:

1. Linking in libeditline like this:

-L../../lib/editline -leditline

looks very suspicious, libtool will assume that the library is
installed, and things may break on some platforms (for instance, I was
recently told that some platforms use -L to locate the library at
run-time as well as link time).  Instead you should use


which will produce a warning message that interdependencies aren't
properly supported, but this will get fixed in libtool 1.4

(this is fixed in my version of Heimdal)

2. libtool is trying to link the static version of libeditline into
libkrb5 (instead of creating a dependency between two shared
libraries). As explained above, this is bad because the libeditline.a
does not contain PIC code required for shared libraries.

I strongly suspect this is because the shared version of the
libeditline is not built, because libeditline is not managed by

3. You are trying to link libss based on snprintf.lo (PIC code) and
snprintf.o (from libeditline.a, non-PIC code).

(I am confused - I thought the linker would just use the first version
it finds - especially as libeditline.a is a static library - why

The linker is confused, and wants to know: do you want to use the PIC
code or the non-PIC code?

Compiling a shared library with non-PIC code causes serious problems,
IIRC, if you want to run multiple applications that use the library at
the same time, so this has to be avoided.

Hope this helps...
Brian May <bam@snoopy.apana.org.au>