Mail Archives: cygwin/2001/06/06/19:44:46
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!
Umm...I *thought* only bash actually included the readline source within
its own source distribution. Other projects just link to the
preexisting "system" readline library, right? (I know bash *can*
USE_SYSTEM_READLINE as well, tho)
<snip>
> 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).
Okay, so here's my pattern:
READLINE_DLL
building dll. causes READLINE_EXPORT(type, symbol) to be
defined as "__declspec(dllexport) type __cdecl symbol"
READLINE_STATIC
building static lib or building an app that links to a static
lib. READLINE_EXPORT(type, symbol) is defined as
"type __cdecl symbol"
<none = default>
linking to dll. causes READLINE_EXPORT(type, symbol) to
be defined as "__declspec(dllimport) type __cdecl symbol"
To harmonize with libtool, "importing" behavior should be
turned on by LIBREADLINE_COMPILATION.
Here's the (new) libtool pattern:
-DDLL_EXPORT -DLIBNCURSES_COMPILATION
building dll. export READLINE symbols, but import NCURSES
symbols
<none = default>
building static lib or building an app that links to a static
lib.
-DLIBREADLINE_DLL_IMPORT
linking to dll.
So, my recipe makes the default behavior "I'm building an app and I want
to link to this library dynamically". The libtool default behavior is
"I'm building an app and I want to link to this library statically -- or
I'm building the static lib itself".
Can this be reconciled -- either by clever use of #defines and AC
macros, or by changing libtool? I really think dll-import should be the
default.
<snip>
>
> 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
Ummm...okay. That went by a little fast. I'll have to take a closer
look at your examples.
> 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
Ditto.
> (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...)
Ummm...why would you do this? libbz2.dll contains the same symbols as
libpng.a...
> > 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 :]
Except that unix so's ALWAYS "export by name". Windows does both
"export by name" and "export by ordinal". Linking to dll's is sometimes
done "by name" and sometimes "by ordinal" -- I have yet to figure out
which and when. In any case, IF you are unlucky enough to "link by
ordinal" to a dll, and then you replace the dll with another that
exports the same symbols but with additions so that the ordinal numbers
are different from the original dll (--export-all-symbols will
alphabetical sort the names when assigning ordingals) -- then boom! The
old .exe must be relinked or it won't work.
THAT's why .def files are used -- so that you can keep the ordinal
numbers the same from version to version. If you can figure out how to
ALWAYS force link-by-name, then this is unnecessary.
> > > 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!.
<snip discussion of Paul's binutils patch>
> > 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.
Thanks,
Chuck
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -