This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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

IMO that's a bug in their project.  They *ought* to gracefully allow
using the system readline -- and if they blindly update their included
copy of the "official" readline sources and it breaks their app -- it's
the external app developer's fault. 

The ONLY reason I'm concerned about bash as an exception to that rule,
is because Chet maintains BOTH bash AND readline.  Because he cares, I
care.
 
> > <snip>
<more snippage>

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

Ah.  Got it.

> > <none = default>
> >   building static lib or building an app that links to a static
> >   lib.
> 
> yes
> 
> > -DLIBREADLINE_DLL_IMPORT
> >   linking to dll.
> 
> yes.

<snip comparison of default behaviors>

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

I disagree.  If someone uses a non-ported version of a library, they're
asking for trouble -- ESPECIALLY if that library has ALREADY been
officially ported and is supported by someone on the cygwin mailing
list.  (If it *hasn't* been ported then there is most likely no problem
-- it will only build as a static lib, and its headers will not
decorate.  No conflict.)

On unix, ld links to shared libs (.so) in preference to static libs
(.a).  On cygwin, ld links to shared-lib-import-libraries (.dll.a) in
preference to static libs (.a).  Therefore,
gcc/autoconf/automake/whatnot should cooperate with ld, and make things
'just work' for dynamic linking by default.  Or the headers should be
manually munged -- in a way compatible and understandable to
libtool/autoconf/etc -- so that external apps will link dynamically to
our library by default.

Now, you can argue that ld is wrong, and we should revert to static
linking by default for cygwin-binutils.  That's a whole 'nother
discussion, and should be its own (flamebait) thread on cygwin-apps. 
However, right NOW, dynamic linking is the default as far as ld is
concerned, and IMO autoconf/etc should accomodate that.

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

Oops. I misread.  libbz2.dll != libPNG.a.  Sorry.  You were right in
that you'd have to link both to libbz2.dll (actually, libbz2.dll.a) and
to libpng.a, unless libbz2.dll{.a} re-exported all the symbols in
libpng.a (not likely).

<snip ordinal vs. name discussion>

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

I *think* so.  There was a problem around libpng-1.0.9/1.0.11 where
missing functions changed the autoassigned ordinals...and stuff broke. 
I created a .def file to maintain the <old> ordinal numbers -- but the
.def does not specify NONAME, so the names should be exported.

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

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

What happens when you strip a dll?  (All dlls are shipped stripped by
default).  nm -a on a stripped dll shows "no symbols" -- but objdump -p
indicates that the symbol export table is still there.  However, you're
actually linking with the import lib, which is (of course) not stripped,
and so contains all of the symbol names.

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

testing.  The problem is, I really don't know how to look at a given
executable, say foo.exe, which depends on bar.dll and baz.dll, and say:
  Ah, yes, foo is linked by name to bar.dll, but its linked by ordinal
to baz.dll.
So, how can you test anything if you don't know how to 'evaluate' the
results?

--Chuck

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]