Re: libwrap.a and -fPIC
Elliot Lee wrote:
> On Tue, 26 Oct 1999, Adam C Powell IV wrote:
>
> > Really? Last time I tried to check a static lib in autoconf it
> > couldn't find it, I assumed that was because it was static and not
> > shared. But I must have been doing something else wrong, or maybe
> > autoconf has changed...
> >
> > Could this be considered a bug in autoconf/libtool? That is, wouldn't it be
> > better if they just detected the shared/static lib, and automatically did the
> > right thing (as I had assumed)?
>
> No, because the "right thing" depends on the the specific situation.
Okay, I'll trust you on this one and move on...
> > It seems like this is a generic problem, and ORBit isn't the only
> > project which could benefit from this being done right.
> >
> > Suggested behavior: if the static lib is there and not the shared version,
> > autoconf could pass the full path to the .a file as the "flag" instead of -lwrap,
>
> > and then libtool -mode=link would see this, unpack the .a, and repack the objects
>
> > into the new lib.
>
> You're expecting libtool to be bright. :) libtool is really aweful to use
> for everything except the basic 80% of cases. Its feature set is basically
> the lowest common denominator of the available features on all supported
> platforms.
And I thought it was *supposed to* be bright. :-) Is any of what I've proposed not
available on supported platforms? Anyway, just wanted to run this behavior by this
group, as it would result in much cleaner configuration files for ORBit, before
passing it on to the libtool list (when I get a chance...).
But there was another question in my post, specific to the short-term fix for ORBit,
which got skipped in your reply:
Adam C Powell IV wrote:
> But unless/until that is done right, the "right thing to do" in ORBit configure.in
> would be to look for the shared lib first, and if it's there, then just include it
> in libIIOP's libtool dependencies, and if not then do the kludge. Right?
Do we agree here? If so, I'll put together a patch for configure.in and
src/IIOP/Makefile.am. If not, what do you propose?
According to Phillip Blundell, building libwrap.a with -fPIC "would work, and it's
feasible, but it's ugly and I don't think it should be necessary." It would require
a change to the tcp-wrappers Debian source package which would then get built into
all of the platforms. But this wouldn't solve the problem because of the libc
symbols in there, so we'd have to rebuild libc.a with -fPIC on all platforms, and all
this to fix ORBit! A wasteful kludge with needless duplication of symbols,
considering that libwrap.so is available (well, will be when netbase is fixed).
An equally draconian but better "fix" is just to require that all platforms have
libwrap.so (better because it saves memory and gets rid of the ugly kludge). If this
is unacceptable, requiring -fPIC for libwrap.a should be at least as much so.
Until this is resolved, ORBit and apps which link it are broken on Debian-ARM, and it
sounds like Debian-Sparc too...
Thanks again for the rapid feedback,
-Adam P.
Reply to: