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
Message-ID: <3C9916AD.3090909@ece.gatech.edu>
Date: Wed, 20 Mar 2002 18:09:33 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Prentis Brooks <prentis AT aol DOT net>
CC: cygwin-apps AT cygwin DOT com
Subject: Re: tcp wrappers
References: <Pine DOT LNX DOT 4 DOT 44 DOT 0203201451040 DOT 2665-100000 AT magetower DOT office DOT aol DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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