[Fwd: libwrap.a and -fPIC]

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

(Forgot to CC this to debian-arm...)

This grew out of that ORBit bug report, the Debian maintainer just wrote
orbit-list about it a couple of days ago.

The relevance to debian arm: one suggested workaround to the ORBit
problem is to build libwrap.a with -fPIC.  How feasible is this?

Thanks...

--- Begin Message ---

• To: orbit-list@cuc.edu
• Subject: Re: libwrap.a and -fPIC
• From: Adam C Powell IV <hazelsct@mit.edu>
• Date: Tue, 26 Oct 1999 16:53:12 +0000
• Message-id: <3815DC78.AF2935B8@mit.edu>
• References: <Pine.LNX.4.10.9910241709560.6032-100000@lacrosse.corp.redhat.com> <874sfg788f.fsf@dsp.net> <3815D08E.B5B778F9@mit.edu>

D'oh!  I spoke too soon.

Adam C Powell IV wrote:

> But this is not an ORBit problem.  When libwrap.so is there, libtool will do
> the right thing.  (Right?)

Wrong...

> Hmm, maybe I'll get the ORBit source, uninstall netbase, install the
> tcp-wrappers stuff (including libwrap0), build ORBit, and then...  Oh, but
> the apps will want to link libwrap.so, which will only be there if I leave
> netbase uninstalled, which wouldn't be much fun. :-)

Just tried this, and libIIOP.so.0.4.0 still has the blasted R_ARM_PC24 symbols.
Trouble is, they include both libwrap and libc symbols, things like strlen and
strcasecmp as well as tcpd_warn and eval_hostname.  Maybe the libc stuff leaked
in via libwrap.a?  (This is pushing the limits of my meager understanding of
these things...)

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 and
include this as a dependency, and then resort to ripping the objects out of
libwrap.a only if it isn't there.  Why the bizarre make_libwrap_files kludge?

[Debian-ARM folks, how feasible would it be to build libwrap.a with -fPIC as a
workaround?]

Zeen,

-Adam P.

--- End Message ---