[avail for test] readline-4.2-1
Wed Jun 6 15:43:00 GMT 2001
----- Original Message -----
From: "Charles Wilson" <email@example.com>
To: "Robert Collins" <firstname.lastname@example.org>
Cc: "Jason Tishler" <Jason.Tishler@dothill.com>; "Cygwin Users"
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
> readline, and test BASH. I think this is perhaps another reason why
> 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
> > 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
> > 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)
> link to static lib ==> <no decoration>. Libtool should handle not
> DLL's and static libs, but also building apps that link to those libs.
> 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
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
> (e.g. "LINK_STATIC" instead of "ZLIB_STATIC and NCURSES_STATIC", you
> that. (Gary Vaughn and I had this discussion about eight months
> think the indicator variable names could be stored in the .la files,
> 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)
and at the program level say - png2gif
-DLIBBZ2_DLL_IMPORT -DLIBPNG_DLL_IMPORT - link to libbz2.dll and
-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
> doesn't use the .def file, even when one is supplied. This is an
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
> > - 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
> and are only necessary for DATA exports. I use the decorators for
> functions and variables. Paul's patch supposedly allows you to build
> link to them successfully *WITHOUT* using decorators at all. He
> 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,
> 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
> 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
> 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.
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin