Re: readline, editline, sl and snprintf

[Derrick J Brashear <shadow@dementia.org>]

--On Friday, January 26, 2001 03:56:54 PM +1100 Brian May 
<bam@snoopy.apana.org.au> wrote:

>>>>>> "Derrick" == Derrick J Brashear <shadow@dementia.org> writes:
>
>     Derrick> and it's not relevant. linking an archive into a shared
>     Derrick> object is ok on several platforms, solaris and x86 linux
>     Derrick> included, because the linker does relocations. you can
>     Derrick> trivially prove this to yourself if you care.
>
> Sure Linux may support it (does the static archive need to contain PIC
> code, or does it somehow work even with non-PIC code?), but does the
> libtool version used support it?

the static archive contains static code; yes, that works. i build krb4 pam 
modules that way on Solaris deliberately to avoid a symbol conflict for the 
des they have in I think it's libnsl.

Yes, libtool deals correctly.

> I know 1.4 will, I can't comment on anything before that.
>
>     >> I strongly suspect this is because the shared version of the
>     >> libeditline is not built, because libeditline is not managed by
>     >> libtool.
>     >>
>     >>
>     >> 3. You are trying to link libss based on snprintf.lo (PIC code)
>     >> and snprintf.o (from libeditline.a, non-PIC code).
>
>     Derrick> i'm not, the current build is set up that way.
>
> I wasn't trying to blame you for the mistake, but rather point out
> "what the build process on your system was trying to do".
>
> Sorry if I didn't make this point clear.

well, i guess i didn't make mine clear either; basically this is "as 
distributed" and i just wanted to make sure you understood i'm trying to 
figure out what changes belong in the distribution, not that i had any 
particularly odd requirements or was providing anything unusual in the way 
of precursors.