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: <00f001c0eeda$1da0e9e0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
Cc: "Jason Tishler" <Jason DOT Tishler AT dothill DOT com>,
        "Cygwin Users" <cygwin AT cygwin DOT com>
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF08F043 AT itdomain002 DOT itdomain DOT net DOT au> <3B1E3D55 DOT AAF8E728 AT ece DOT gatech DOT edu>
Subject: Re: [avail for test] readline-4.2-1
Date: Thu, 7 Jun 2001 08:43:32 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 06 Jun 2001 22:34:34.0328 (UTC) FILETIME=[DC550580:01C0EED8]

----- Original Message -----
From: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
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>
Sent: Thursday, June 07, 2001 12:25 AM
Subject: Re: [avail for test] readline-4.2-1


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

Bash and OpenSp and ... there are a lot of GPL projects that have that
requirement. Definately part of the testing!

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

I think it was 1.3 that can do .dll's. I'm sure on the genesis. The key
issue has been _knowing about it_.

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

As I said - most of the logic handling is on the programmer today.
1) -DDLL_EXPORT is defined. Also I recommend
definingin -DLIBFOO_COMPILATION, to allow importing headers from other
libraries without them getting the wrong decoration. I have sent a
proof-of-concept patch to automake that automates that definition for
all sources in a library, even if the source file is reused across
multiple libraries.
2) Nothing is _automatically_ defined. -DLIBFOO_DLL_IMPORT is the
"documented" define to use to indicate you will be linking that source
file to a dll library. This should be automatically passed to gcc, but
at this point libtool doesn't know what libraries a given object file
will be linked to. (This problem affects more than libtool. It also
affects gnome modules and similar efforts. There has been some
discussion about good solutions, but nothing concrete yet).
   A Configure.in recipe is provided by Gary Vaughn for automatically
setting -DLIBFOO_DLL_IMPORT for libraries at configure time. If you are
building both static and shared .exe's, then automake's If functionality
comes in handy.
3) is the default behaviour (treated as non-PIC code).

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

The indicators are distinct except for -DDLL_EXPORT.
The -DLIBFOO_COMPILATION which automake can add automatically (with my
patch) or manually via libfoo_la_CFLAGS is distinct.
And arbitrary combinations can be ade as well.
(ie build libpng dll source linking to libbz2 dll)
-DDLL_EXPORT -DLIBPNG_COMPILATION -DLIBBZ2_DLL_IMPORT
( vs build libpng dll source linking to libbz2.a)
-DDLL_EXPORT -DLIBPNG_COMPILATION

and at the program level say - png2gif
-DLIBBZ2_DLL_IMPORT -DLIBPNG_DLL_IMPORT - link to libbz2.dll and
libpng.dll
-DLIBBZ2_DLL_IMPORT - link to libbz2.dll and libpng.a

(There are likely symbol issues with doing mix's like that when the
dependent libraries are not of the same type - ie if you build
libbz2.dll linked statically to libpng.a, I suspect that the application
may need to link statically to libpng.a, but I haven't tested so...)

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

Possibly. The nice thing about what libtool does is that all the symbols
are available without functions needing decoration, and without an
external file needing updating. Rather like unix really :]

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

I'll set some time aside for that.

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

Emailed privately (150kb). I didn't put a licence on it - its a derived
work from the Goat book so... if there's an issue there let me know.

Rob

> --Chuck
>


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