[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: preparing for 1.5.24
From: |
Charles Wilson |
Subject: |
Re: preparing for 1.5.24 |
Date: |
Sun, 18 Feb 2007 14:06:21 -0500 |
User-agent: |
Thunderbird 1.5.0.9 (Windows/20061207) |
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