Re: preparing for 1.5.24
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.)
It'd be nice to be able to say whenever libltdl is used as a convenience
library to build a DLL, on windows libtool should automatically turn on
--export-all-symbols. But that isn't true: if the target DLL is already
doing explicit declspec(dllexport), then (1) the target library would
work, today, without any changes, and (2) we don't want to override that
target DLL's explicit export settings by saying, no, I'm going to export
everything.
ACK.
So, I'm not sure how to solve this, in a way that is platform-agnostic.
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.
Do you think we should add some documentation bits a la if you have the
same problem, consider this solution as well?
(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.
But I'm nervous about changing the definition of export_dynamic_flag_spec
-- because that would have wide-ranging effects. Esepcially in a release
candidate, and especially especially in the RC for the last-ever 1.5.x
libtool.
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.
[1] mdemo README:
Note that on Windows, for the purposes of illustrating ltdl, the
libraries *are* built as dll's, but do not have the __declspec
machinery to make them suitable for loading at link time. This is
only for clarity inside this example, look at the example in ../demo
to see how the __declspec macros should be set up.
[2] BTW, ../demo does not set up any __declspec macros. I believe the
readme snippet above is really old, and pre-dates auto-export/auto-import
functionality. At best, this snippet is now specific only to non-gcc on
Windows, which is at present only barely supported in libtool-1.5.x
anyway. Notwithstanding my reference to this snippet in the context of
libltdl-as-convenience-lib, I think this snippet should be deleted
entirely.
Indeed. I guess for branch-1-5 it 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.
Cheers, and thank you,
Ralf
* 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.
Index: mdemo/Makefile.am
===
RCS file: /sources/libtool/libtool/mdemo/Attic/Makefile.am,v
retrieving revision 1.46.2.2
diff -u -r1.46.2.2 Makefile.am
--- mdemo/Makefile.am 3 Feb 2006 09:37:34 - 1.46.2.2
+++ mdemo/Makefile.am 18 Feb 2007 12:07:21 -
@@ -19,9 +19,12 @@
libsub_la_SOURCES = sub.c
libsub_la_LDFLAGS = -no-undefined
+## Use -export-symbols-regex here explicitly because libltdl marks
+## its exported symbols, and we use libltdl as a convenience archive.
+## Thus, on w32, auto-exporting is turned off.
libmlib_la_SOURCES = mlib.c
libmlib_la_LIBADD = @LIBLTDL@ -dlopen foo1.la -dlopen libfoo2.la
-libmlib_la_LDFLAGS = -no-undefined
+libmlib_la_LDFLAGS = -no-undefined -export-symbols-regex .*
libmlib_la_DEPENDENCIES = @LIBLTDL@ libsub.la foo1.la libfoo2.la
noinst_HEADERS = foo.h
FYI: HEAD: fix static.at glitch
D'oh! The good libraries were named liba[123]*, the bad ones lib[123]*.
Fixed as below.
I found out why the test fails on w32, too. First, as hardcoding fails,
we need to adjust $PATH to find the non-libtool library. Then, the
moving around of libraries also needs to take into account the
../bin/$dll thingy. Still working on a nice and clean way for that.
Cheers,
Ralf
2007-02-18 Ralf Wildenhues [EMAIL PROTECTED]
* tests/static.at: Use the right names for the broken libs.
Index: tests/static.at
===
RCS file: /cvsroot/libtool/libtool/tests/static.at,v
retrieving revision 1.2
diff -u -r1.2 static.at
--- tests/static.at 12 Feb 2007 22:29:05 - 1.2
+++ tests/static.at 18 Feb 2007 15:03:21 -
@@ -1,5 +1,5 @@
# Hand crafted tests for GNU Libtool. -*- Autotest -*-
-# Copyright 2006 Free Software Foundation, Inc.
+# Copyright 2006, 2007 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -93,8 +93,8 @@
echo 'int this_should_not_be_linked_against() { return 0; }' a.c
$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c a.c
for i in 1 1dep 2 2dep 3 3dep; do
-$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o lib$i.la a.lo -rpath
$libdir_broken
-$LIBTOOL --mode=install cp lib$i.la $libdir_broken/lib$i.la
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba$i.la a.lo -rpath
$libdir_broken
+$LIBTOOL --mode=install cp liba$i.la $libdir_broken/liba$i.la
done
)
Link order of deplibs test (was: FYI: lt_dlexit.at test needs 'libtool --mode=execute')
Hello Peter,
* Ralf Wildenhues wrote on Wed, Feb 14, 2007 at 12:13:51AM CET:
* Peter O'Gorman wrote on Tue, Feb 13, 2007 at 03:15:19PM CET:
On Feb 13, 2007, at 4:54 AM, Ralf Wildenhues wrote:
This fixes lt_dlexit.at test on some systems (e.g., Darwin), where a
main program without uninstalled library dependencies doesn't get a
shell wrapper.
Thanks, was wondering what was up with this. Still unexpectedly
failing two tests on darwin though - 16 and 49. I haven't looked
closely, should I?
I think I'll rewrite link-order2.at (16) to not use libm, that fails
just about everywhere. 49 is just failing on Darwin because it reruns
test 16. You could look into it if it still fails afterwards. ;-)
Here's a rewrite of the test. I think it still fails on Darwin (with
duplicate symbols IIRC; I only tested an earlier version of this) and
AIX without runtimelinking. Could you look into the issue on Darwin?
(Of course I'd also appreciate a review of the proposed patch. ;-)
Cheers, and thanks,
Ralf
2007-02-18 Ralf Wildenhues [EMAIL PROTECTED]
* tests/link-order2.at: Rewrite completely. Do not use `sin'
from the math library, there are too many problems with this.
Instead, use a self-written library, install it without the
Libtool library file, to emulate a native library in a system
directory, and adjust $shlibpat_var. Try overriding its symbol.
Further, also try an installed `wrong' binary.
Avoid failing test bits on AIX without runtimelinking, SKIP at
the end in this case.
Index: tests/link-order2.at
===
RCS file: /cvsroot/libtool/libtool/tests/link-order2.at,v
retrieving revision 1.4
diff -u -r1.4 link-order2.at
--- tests/link-order2.at14 Dec 2006 20:59:26 - 1.4
+++ tests/link-order2.at18 Feb 2007 15:37:40 -
@@ -1,5 +1,5 @@
# Hand crafted tests for GNU Libtool. -*- Autotest -*-
-# Copyright 2006 Free Software Foundation, Inc.
+# Copyright 2006, 2007 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -18,86 +18,119 @@
# link-order2.test: make sure that depdepls are added right after
# the libs that pull them in: necessary at least for static linking
-# and on systems where libraries do not link against other libraries,
-# in order to do this: override a commonly used symbol in a commonly
-# used library.
+# and on systems where libraries do not link against other libraries.
+#
+# We test by overriding one symbol from a depdepl library.
+# Test both a libtool library and a non-libtool library (simulated
+# by removing the .la file, and setting $shlibpath_var so it is
+# found at runtime). In order to ensure that the depdepl is
+# actually loaded in each case, we also use an unrelated symbol
+# from it directly in the main program. We test for failure by
+# reversing the link order.
+# We test both static and shared: it should work in both cases.
+# But for the static case to work, the two symbols in the depdepl
+# need to be in separate object files, otherwise duplicate symbol
+# definitions can happen.
+
+# The shared case fails on AIX without runtimelinking and on Darwin.
AT_SETUP([Link order of deplibs.])
AT_KEYWORDS([libtool])
-# g++ reorders `-lm' on the command line. :-(
-AT_DATA([t.c], [[
-#if defined(__cplusplus) defined(__GNUC__)
-choke me
-#endif
-int t = 42;
-]])
-AT_CHECK([$CC $CPPFLAGS $CFLAGS -c t.c || exit 77], [], [ignore], [ignore])
+eval `$LIBTOOL --config | $EGREP '^shlibpath_var='`
+
+shared_fails=no
+case $host_os,$LDFLAGS in
+aix*,*-brtl*) ;;
+aix*) shared_fails=yes ;;
+esac
-LDFLAGS=$LDFLAGS -no-undefined
+deflibdir=`pwd`/lib
+defbindir=`pwd`/lib
libdir=`pwd`/inst/lib
bindir=`pwd`/inst/bin
-mkdir inst inst/bin inst/lib
+mkdir bin lib inst inst/bin inst/lib
+LDFLAGS=$LDFLAGS -no-undefined -L$deflibdir
+
+cat a0.c \EOF
+int a0 (void) { return 0; }
+EOF
-cat a.c \EOF
-/* pretend we have a better sine function */
-#ifdef __cplusplus
-extern C
-#endif
-double sin (double x) { return 0.0; }
+cat a1.c \EOF
+int a (void) { return 1; }
+EOF
+
+cat a2.c \EOF
+int a (void) { return 0; }
EOF
cat b.c \EOF
-#ifdef __cplusplus
-extern C
-#endif
-double sin (double);
-double b (double x) { return sin (x); }
+int a (void);
+int b (void) { return a (); }
EOF
cat main.c \EOF
-#include math.h
#include stdlib.h
-extern double b (double);
-extern double four;
-double four = 4.0;
+extern int a0 (void);
+extern int b (void);
int main (void)
{
- /* The function b should call our sin (that returns 0) and not libm's
- * (in the latter case, b returns approximately 1)
- * the sqrt is to force linking against libm
- * the variable four is to prevent most compiler optimizations
- */
- int status = EXIT_FAILURE;
- if (fabs (b (3.1415 /
Re: preparing for 1.5.24
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
Re: template.at on Darwin
On Feb 19, 2007, at 3:33 AM, Ralf Wildenhues wrote:
Hello Peter, all,
HEAD's test/template.at excludes some tests for Darwin, without any
sort of explanation. Do you have resources to look into this, so
that we can either document why things do not work, or, even better,
fix it? Otherwise I can give it a try eventually.
Hi Ralf,
I filed this as rdar://problem/4135857 (in case any apple people are
reading) in June 2005, it was closed as expected behavior, reopened
after I complained and has recently been retitled as a documentation
bug (they are going to document this behavior).
The problem arises because of Apple's flat namespace and two level
namespace objects. Executables are being built with no namespace
flag, so they are two level namespace by default. Two level namespace
output causes the static linker to not look for definitions for
symbols that are undefined in a flat namespace library:
Please know that ld no longer looks for symbols in places that were
not specified. This behavior lead to incorrect symbol resolution.
If I recall correctly, this test will pass if you export
MACOSX_DEPLOYMENT_TARGET=10.3 before building libtool and running the
testsuite, setting MACOSX_DEPLOYMENT_TARGET to 10.3 or later causes
libtool to default to building two level namespace shared libraries.
Peter
Thanks,
Ralf
../../libtool-2.1a/tests/template.at:222: ./sub/main; lt_status=$?;
if test $lt_status -eq 0; then :;
elif test X$host != X$build \
{ test -x ./sub/main || test -x ./sub/
main$EXEEXT; }
then (exit 77); else (exit $lt_status); fi
Not enabling shell tracing (command contains an embedded newline)
--- /dev/null 2007-02-18 13:35:29.0 -0500
+++ /tmp/build/tests/testsuite.dir/at-stderr 2007-02-18
13:32:20.0 -0500
@@ -0,0 +1,9 @@
+dyld: lazy symbol binding failed: Symbol not found: __Z2a2c
+ Referenced from: /tmp/build/tests/testsuite.dir/44/obj/
lib2/.libs/libb.0.dylib
+ Expected in: flat namespace
+
+dyld: Symbol not found: __Z2a2c
+ Referenced from: /tmp/build/tests/testsuite.dir/44/obj/
lib2/.libs/libb.0.dylib
+ Expected in: flat namespace
+
+/tmp/libtool-2.1a/tests/testsuite: line 19168: 5946 Trace/BPT
trap ./sub/main
