Re: [avail for test] readline-4.2-1

["Charles S. Wilson" <cwilson at ece dot gatech dot edu>]

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