Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3B1E3D55.AAF8E728@ece.gatech.edu>
Date: Wed, 06 Jun 2001 10:25:25 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: Jason Tishler <Jason DOT Tishler AT dothill DOT com>,
        Cygwin Users <cygwin AT cygwin DOT com>
Subject: Re: [avail for test] readline-4.2-1
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF08F043 AT itdomain002 DOT itdomain DOT net DOT au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Robert Collins wrote:
> 
> 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).

I don't think he would mind -- supposedly, all GNU projects *should* be automade
and libtoolized.  However, readline is included within the bash source dist
(unchanged), so you'd need to test your changes in the standalone readline dist,
and then:

get bash, rip out its included bash/readline/* stuff, replace it with your new
readline, and test BASH.  I think this is perhaps another reason why Chet was
reluctant to accept my patch...

> > 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.

Well, libtool 1.4 has only been out for six months or so.
 
> Libtool issues -DDLL_EXPORT to gcc when compile source that will become
> part of a .DLL and doesn't when compiling static library source.

That's cool, but isn't enough.  There are *three* cases, not just two -- binary
math tells us that requires two variables.  (1) build DLL ==>
__declspec(dllexport)  (2) link to DLL ==> __declspec(dllimport)  (3) build or
link to static lib ==> <no decoration>.  Libtool should handle not only building
DLL's and static libs, but also building apps that link to those libs.  How is
that handled?  Also, the binary indicator variables should be distinct, not
global IMO -- what if I wanted to link to zlib statically, but wanted to link to
ncurses dynamically?  Since libtool presumably uses the same indicator variables
(e.g. "LINK_STATIC" instead of "ZLIB_STATIC and NCURSES_STATIC", you can't do
that.  (Gary Vaughn and I had this discussion about eight months ago...)  I
think the indicator variable names could be stored in the .la files, but Gary
didn't want to add a new record in that "database".

Also, I believe libtool creates DLL's by doing '-Wl,--export-all-symbols' and
doesn't use the .def file, even when one is supplied.  This is an oversight, I
believe.

> 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!. 

Please give Paul Sokolovsky's "auto-imports" patch to binutils a try. 
Currently, the __declspec() decorators are NOT necessary for function exports,
and are only necessary for DATA exports.  I use the decorators for both
functions and variables.  Paul's patch supposedly allows you to build DLL's and
link to them successfully *WITHOUT* using decorators at all.  He claims you
don't need them in your DLL source code nor headers nor client code.

If that is true, and IF that is included within the man binutils dist, and IF
the official cygwin ld.exe eventually contains that functionality, THEN it will
make life a LOT easier...but I haven't been able to test it.  According to cgf,
Paul's patch has been languishing because nobody (other than Paul himself) has
tested it.

> 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.

Actually, yes -- I'll put it at cygutils next to dllhelpers-0.2.6 and we can
refer the curious to both examples.

--Chuck

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple