Ralf Wildenhues wrote:
Hello Charles,
Charles Wilson writes:

- It would help me greatly if someone could look into the Cygwin and
  MinGW mdemo* failures; and documentation updates if needed.

Solution in this case is to turn auto-export back on

Or to mark all symbols as to be exported, no?
(Or to mark all other symbols explicitly.  But let's not go that way.)

Yes, that should work, too.

I think the patch below should work, and be platform-agnostic.  WDYT?
OK for branch-1-5 and HEAD alike?  It fixes the similar failure there.

Hmm -- seems ok in principle. I don't know if the end behavior is exactly the same, between ld's --export-all-symbols and libtool's -export-symbols-regex ".*". I've attached the exports list from my cygmlib-0.dll (taken from the output of objdump -p). How does yours compare?

Do you think we should add some documentation bits a la "if you have the
same problem, consider this solution as well"?

Yes, I do.  Around line 3546 in libtool.texi, something like:

@emph{Win32 specific} When building a DLL on windows (MinGW,Cygwin) that uses @code{libltdl} as a convenience archive, there are some issues with symbol decoration that must be carefully managed. You must do one of the following, within the code and/or build machinery of your library:

@enumerate 1
@item explicitly mark as @code{declspec(dllexport)} all symbols in your library that should be exported when building your library's source code. However, these symbols should @emph{not} be marked @code{declspec(dllexport)} when building @emph{clients} of your library -- instead, the symbols should be marked @code{declspec(dllimport)}. This procedure will require careful macro design within your library's public header files. An example of this may be found in @file{zlib.h} from the zlib distribution @url{http://www.zlib.net/}.

@item use the (win32-specific) linker option @code{-Xlinker --export-all-symbols}. This will restore the expected "auto-export" behavior of the GNU linker on windows. However, the @code{--export-all-symbols} option is specific to the GNU linker's i386 PE target -- @code{ld} for other targets will not recognize the option. Therefore, using this option will require careful coding in your library's @file{Makefile.am} and @file{configure.ac}. For example:

case $host_os in
cygwin* | mingw* | pw32*)
  RESTORE_AUTOEXPORT="-Xlinker --export-all-symbols"
@end example

libmylibrary_la_LDFLAGS = -no-undefined $(RESTORE_AUTOEXPORT)
@end example

@item Use libtool facilities to mimic @code{--export-all-symbols}. Unlike the solution above, this solution has the advantage of requiring no platform-specific workarounds. Simply append @code{-export-symbols-regex ".*"} to the @code{_LDFLAGS} for your library:

libmylibrary_la_LDFLAGS = -no-undefined -export-symbols-regex ".*"
@end example
@end enumerate

(FWIW, on HEAD there are other mdemo test failures which I haven't looked
at yet.)
FWIW, it doesn't appear that libtool's -export-dynamic will do the right thing here. I thought about setting export_dynamic_flag_spec to '${wl}--export-all-symbols' for mingw/cygwin (currently, they inherit the generic '${wl}--export-dynamic' setting [3]), and then using '-export-dynamic' in libmlib_la_LDFLAGS for all platforms.

I don't think -export-dynamic is intended to have the semantics of

It seems to just delegate to ld's --export-dynamic, which from my reading of 'info ld' seems concerned mainly with the export of symbols from an executable. (kinda like --export-all-symbols, but .exe-specific, and doesn't really export ALL symbols, just most of them). You're right in that we should not "overload" its behavior on win32 -- that way lies madness.

I guess I should have written "the last 1.5.x release, unless serious
issues show up".  When writing, the intention was more of a "after this,
we work towards 2.0" then anything else.

Heck yeah. I don't want to slow THAT down!

Indeed.  I guess for branch-1-5
[ the blurb in mdemo/README concerning win32 ]
should be removed.  For HEAD and
eventual MSVC support, those would need to be added again.


[3] I'm not sure, but it looks like cygwin's ld simply ignores --export-dynamic. From a brief look at the bfd/ld source code, this ld option seems to be ELF-specific.

I guess.  I don't know what its effect on Cygwin should be though.
Not --export-all-symbols, that's not the right thing.

Ack. I think it should force a kind of --export-all-symbols, but only for .exe's. Current ld behavior for .exe's is to NOT export any symbols (e.g. no auto-export) -- unless (a) there are symbols in the exe which were explicitly marked declspec(dllexport), or (b) a .def file is used, or (c) --export-all-symbols is used on the link command.

But this is a HEAD issue, not a branch-1-5 issue.

      * mdemo/Makefile.am (libmlib_la_LDFLAGS): Add -export-symbols-regex
      ".*" because the convenience libltdl uses export markers and thus
      turns off autoexport on w32.  Fixes test failures for Cygwin and
      MinGW.  Bug analysis by Charles Wilson.

Seems OK, if there are no "important" differences between the actual exports in your cygmlib-0.dll and mine.

[Ordinal/Name Pointer] Table
        [   0] lt_dladderror
        [   1] lt_dladdsearchdir
        [   2] lt_dlcaller_get_data
        [   3] lt_dlcaller_register
        [   4] lt_dlcaller_set_data
        [   5] lt_dlclose
        [   6] lt_dlerror
        [   7] lt_dlexit
        [   8] lt_dlforeach
        [   9] lt_dlforeachfile
        [  10] lt_dlfree
        [  11] lt_dlgetinfo
        [  12] lt_dlgetsearchpath
        [  13] lt_dlhandle_next
        [  14] lt_dlinit
        [  15] lt_dlinsertsearchdir
        [  16] lt_dlisresident
        [  17] lt_dlloader_add
        [  18] lt_dlloader_data
        [  19] lt_dlloader_find
        [  20] lt_dlloader_name
        [  21] lt_dlloader_next
        [  22] lt_dlloader_remove
        [  23] lt_dlmakeresident
        [  24] lt_dlmalloc
        [  25] lt_dlmutex_register
        [  26] lt_dlopen
        [  27] lt_dlopenext
        [  28] lt_dlpreload
        [  29] lt_dlpreload_default
        [  30] lt_dlrealloc
        [  31] lt_dlseterror
        [  32] lt_dlsetsearchpath
        [  33] lt_dlsym
        [  34] mlib_func
        [  35] test_dl

Reply via email to