Subject: Re: [avail for test] readline-4.2-1
From: "Robert Collins" <[email-masked]>
To: "Charles S. Wilson" <[email-masked]>
Cc: "Jason Tishler" <[email-masked]>, "Cygwin Users" <[email-masked]>
Date: Thu, 7 Jun 2001 10:13:41 +1000

----- Original Message -----
From: "Charles S. Wilson" <[email-masked]>
To: "Robert Collins" <[email-masked]>
Cc: "Jason Tishler" <[email-masked]>; "Cygwin Users"
<[email-masked]>
Sent: Thursday, June 07, 2001 9:45 AM
Subject: Re: [avail for test] readline-4.2-1

> Robert Collins wrote:
<snip bash inclusion background>
> 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)

Yeah, weeeeell other folk have copied the source dir into their project,
and default to using their included readline. Header conflicts - their
headers are non-cygwin, so they cannot link to the dll - cause issues
for me on a regular basis.

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

nope. -DDLL_EXPORT -DLIBNCURSES_COMPILATION
  is building ncurses.dll.

this: -DDLL_EXPORT -DLIBREADLINE_COMPILATION -DLIBNCURSES_DLL_IMPORT
  is  building dll.  export READLINE symbols, but import NCURSES
   symbols

> <none = default>
>   building static lib or building an app that links to a static
>   lib.

yes

> -DLIBREADLINE_DLL_IMPORT
>   linking to dll.

yes.

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

It can be, but I think shouldn't be.
--> Any package from unix - say a non-modified readline, will only have
headers for static linking. Those headers are compatible with static
compiled libraries here. Making the default static will reduce those
conflicts, while libtool users, and users that port packages will be
able to link to .dll's.

> <snip>
>
> Ummm...okay. That went by a little fast.  I'll have to take a closer
> look at your examples.

the example I sent you doesn't show how external packages detect dll's,
look in configure.in, for two dnl'd lines: they show how an external
package can autodetect a libtool created dll library.

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

My turn... I *thought* that you needed to link to both?

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

I don't think that is an issue:
a) Present day: all the libtool created libraries are
cyglibfoo-version.dll. And they don't provide an ordinal .def file, so
all linked apps will be by name.
b) The libraries you are shipping are linked to by name if you use the
default headers, no? So again, that shouldn't be an issue.
c) Older libraries that folk have linked to by ordinal, may be an issue.
I doubt any will be around after the change from libfoo.dll to
cyglibfoo.dll.

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

Use gcc or MSVC :]. Quoting MS
===
Another advantage to using a .DEF file is that you can export functions
using the NONAME attribute, which places only the ordinal in the exports
table in the DLL. For DLLs with a large number of exported functions,
using the NONAME attribute can reduce the size of the DLL file. For
information about writing a module definition statement, see Rules for
Module-Definition Statements. For more information on ordinal export,
see Export Functions From a DLL By Ordinal Rather Than By Name.
===

and

===
The simplest way to export functions from your DLL is to export them by
name. This is what happens when you use __declspec(dllexport), for
instance. But you can instead export functions by ordinal. With this
technique, you must use a .DEF file instead of __declspec(dllexport). To
specify a function's ordinal value, append its ordinal to the function
name in the .DEF file. For information on specifying ordinals, see
Export from a DLL Using .DEF Files.
Tip   If you want to optimize your DLL's file size, use the NONAME
attribute on each exported function. With the NONAME attribute, the
ordinals are stored in the DLL's export table rather than the function
names. This can be a considerable savings if you are exporting many
functions.
===

I read the two combined as
"linking to ordinal occurs when NONAME is present on eeach function
export in the .def file"

Basically, ordinals are a optimisation, and the dll _creator_ controls
whether linking to ordinals is allowed. No .def file, and/or no ordinals
(they are optional) and it cannot happen.

'Course, testing is probably needed, or a quick mail to the binutils
list/search the binutils archives.

Rob

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