Re: preparing for 1.5.24

[Charles Wilson]

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:

configure.ac:
@example
...
case $host_os in
cygwin* | mingw* | pw32*)
  RESTORE_AUTOEXPORT="-Xlinker --export-all-symbols"
  ;;
*)
  RESTORE_AUTOEXPORT=
  ;;
esac
AC_SUBST(RESTORE_AUTOEXPORT)
...
@end example

Makefile.am
@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:

Makefile.am
@example
...
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
> --export-all-symbols.

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.

Right.

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

--
Chuck

[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