Mailing-List:	contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender:	cygwin-apps-owner AT cygwin DOT com
List-Subscribe:	<mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin-apps/>
List-Post:	<mailto:cygwin-apps AT cygwin DOT com>
List-Help:	<mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To:	cygwin-apps AT cygwin DOT com
Delivered-To:	mailing list cygwin-apps AT cygwin DOT com
X-Authentication-Warning:	magetower.office.aol.com: prentis owned process doing -bs
Date:	Wed, 20 Mar 2002 21:19:59 -0500 (EST)
From:	Prentis Brooks <prentis AT aol DOT net>
To:	Charles Wilson <cwilson AT ece DOT gatech DOT edu>
cc:	cygwin-apps AT cygwin DOT com
Subject:	Re: tcp wrappers
In-Reply-To:	<3C9916AD.3090909@ece.gatech.edu>
Message-ID:	<Pine.LNX.4.44.0203202117420.3563-100000@magetower.office.aol.com>
MIME-Version:	1.0

Hrmmm.... I will look into it, I am sure there is some efficiency gained
from making it a DLL.  Would packages that are built against libwrap
automatically use the DLL if it is available, or would they need to be
tweaked as well (ie sshd is compiled such that if libwrap.a is available
it will use it to make use of host.allow files).

On Wed, 20 Mar 2002, Charles Wilson wrote:

> Prentis Brooks wrote:
> 
> 
> >>Hmm.  I wonder if it would be worthwhile to make the wrapper library a
> >>DLL.
> >>
> > 
> > I would rather we didn't, primarily because the modification to make tcp
> > wrappers work with Cygwin was simplistic.  In fact, at this point the
> > modification is only to the Makefile, plus a line in one another file.  
> > It is my understanding from Mumit Khan that the tcp wrappers author is
> > going to incorporate this patch into the next release of tcp wrap.
> > Taking that into consideration, wouldn't turning the libwrap into a DLL
> > cause a (kind of) branch?
> 
> 
> Not really.  re-libtoolizing the source dir (tcp is libtoolized, I 
> think) using our cygwinized devel version of libtool is a "builder" 
> issue, not really a source code issue.
> 
> (In the old days, making a DLL required intrusive and exhausting changes 
> to lots and lots of source files -- __declspec(dllexport) this, 
> __declspec(dllexport that)... -- but no longer.) With auto-import 
> binutils, and the libtool-devel package, you merely:
> 
> rm ldconfig.sh
> rm ltmain.sh
>    << edit configure.in and make sure that
>    it AC_PREREQ's 2.50 or greater >>
> libtoolize --force -c
> aclocal ( possibly need to add '-I some-subdir')
> automake --force -a
> autoconf
> 
> And then configure/make as usual -- an poof! DLL AND static lib.
> 
> Okay, maybe it's not QUITE that easy, but it's close.  You do need to 
> understand the autotools and maybe read a few man pages, but...
> 
> Still, this is a maintainer decision. If you don't want to DLLize, that 
> is your prerogative.  No complaints from me.
> 
> --Chuck
> 
> 
> 

-- 
Prentis Brooks	| prentis AT aol DOT net | 703-265-0914 | AIM: PrentisBrooks
Senior System Administrator - Web Infrastructure & Security

       A knight is sworn to valor.  His heart knows only virtue.  His blade
       defends the helpless.  His word speaks only truth.  His wrath undoes
       the wicked. - the old code of Bowen, last of the dragonslayers

- Raw text -