Re: libwrap.a and -fPIC

[Adam C Powell IV <hazelsct@mit.edu>]

Elliot Lee wrote:

> On Tue, 26 Oct 1999, Adam C Powell IV wrote:
>
> > Looking at the Makefile in src/IIOP, I see LIBWRAP_PATH=/usr/lib/libwrap.a.
> > This is because the toplevel configure.in looks only for libwrap.a.  It seems
> > more intelligent to just use the usual autoconf check for the libwrap.so
>
> There is no way to check specifically for a .so vs. a .a without doing
> special tests. 'AC_CHECK_LIB(wrap, main)' will find either libwrap.so or
> libwrap.a, since when linking it justs uses -lwrap.

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)?  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.  If the shared lib is there, libtool would get -lwrap, and just
put that in the dependencies line of the .la file.  Of course, this wouldn't solve
any problems unless it defaulted to building static libs with -fPIC...

> > Why the bizarre make_libwrap_files kludge?
>
> 'make -j'
>
> (Not so bizarre, and necessary.)

Sorry, I meant "why the bizarre kludge to unpack objects in libwrap.a?"  This is a
funky workaround for something that seems like it should be automatically done by
autoconf/libtool...

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?

Thanks for the rapid reply!

-Adam P.