Subject: RE: [avail for test] readline-4.2-1
From: "Robert Collins" <[email-masked]>
To: "Charles Wilson" <[email-masked]>
Cc: "Jason Tishler" <[email-masked]>, "Cygwin Users" <[email-masked]>
Date: Wed, 6 Jun 2001 14:50:38 +1000

> -----Original Message-----
> From: Charles Wilson [mailto:[email-masked]]
> 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: 
<snip>
> 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