[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: readline, editline, sl and snprintf
--On Friday, January 26, 2001 03:56:54 PM +1100 Brian May
>>>>>> "Derrick" == Derrick J Brashear <firstname.lastname@example.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