Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Subject: RE: [avail for test] readline-4.2-1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-class: urn:content-classes:message Date: Wed, 6 Jun 2001 14:50:38 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [avail for test] readline-4.2-1 Thread-Index: AcDuQx0oEZ84DwohTmuq84b2ZzW9PQAABQ+Q From: "Robert Collins" To: "Charles Wilson" Cc: "Jason Tishler" , "Cygwin Users" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id BAA19867 > -----Original Message----- > From: Charles Wilson [mailto:cwilson AT ece DOT gatech DOT edu] > Sent: Wednesday, June 06, 2001 2:55 PM > To: Robert Collins > Cc: Jason Tishler; Cygwin Users > Subject: Re: [avail for test] readline-4.2-1 > > > > > How autoconfiscated/libtoolised/automade is readline && > your patch? I'm > > doing a chunk of work now on libtool and will investigate taking on > > readline... > > There are two issues: my current patch, and possible libtool > improvements: > > 1) The patch has several parts: > My changes are not libtool-based at all. It seems, too, that > readline doesn't > use libtool to build on Linux, either. It appears that > readline is autoconf'ed, > but not libtool'ed. I grabbed the srcball and had a look-see. readline isn't libtool'ed. It also isn't Automade - do you know if Chet has any objection to this in principle? (It's easier to add libtool to automake projects than to non-automake projects). > 2) Rumor has it that newer libtools can create dll's. I have > not looked into > this issue at all. If you pursue this, the Makefiles will > probably change > w.r.t. the original in a differet way than I have changed > them in 1-b). Also, I > do not know if libtool can deal with the appropriate #defines > and macros as in > 1-a). libtool creates .dll's and has for a while. It's documented in the goat book. It's not documented clearly elsewhere unfortunately. Libtool issues -DDLL_EXPORT to gcc when compile source that will become part of a .DLL and doesn't when compiling static library source. Most of the onus on .dll library creation rests on the programmer today - using #defines like you have. I intend to change that, but not overnight!. So yes it will handle what you've done in 1-a, with minor or no changes. Some changes may make the source easier to grok, utilising the libtool capabilities. If you're interested I have a trivial helloworld sample with two libraries, one dependent on the other, that builds in both static and/or non-static mode with libtool 1.4. The point about it is that the code changes can be very localised and minor. (And this covers exported functions and variables accessible cross-dll) - rather like libpng and linbz2. Rob > --Chuck > -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple