Historically-derived confusion in libtool manual
Section 9.4 Unresolved dlopen problems is a bit confusing because in fact all the problems mentioned are solved by libltdl. Since libltdl is supplied with libtool, I'm not sure how it's useful to continue to describe these problems, at least in this way. There are some other historical knots in the documentation: On some platforms, whose dynamic linkers are too limited for a simple implementation of `libltdl' services, it requires GNU DLD, yet if you go to the GNU DLD page, it says it has been deprecated in favour of libtool. Also, in section 9.2 of the libtool manual, there are references to a type and variable which are declared in ltdl.h, before libltdl has even been mentioned. I wonder if it might be worth removing section 9 of the manual, incorporating whatever bits continue to be useful as technical footnotes to section 10? Then, programmers are encouraged to use the most high-level and advanced features of libtool (i.e. libltdl) first, rather than finding their way there via the older features; or at least reverse the order of these two sections, so that readers learn about libltdl first. -- http://rrt.sc3d.org/ | impossible, a. worth doing ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Typo in 1.5.22 manual, Libltdl interface section
`lt_dlforeachfile' returns value returned by the last call made to FUNC. missing the before value. -- http://rrt.sc3d.org/ | The yak is slow but the earth is patient (LucasArts) ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Problem with default builds on mingw32
On Mon, 8 Jan 2007, Ralf Wildenhues wrote: Hello Reuben, * Reuben Thomas wrote on Wed, Jan 03, 2007 at 12:04:37AM CET: libtool 1.5.22 contains the following (trivial) code and (non-trivial) comments: # It is impossible to link a dll without this setting, and # we shouldn't force the makefile maintainer to figure out # which system we are compiling for in order to pass an extra # flag for every libtool invocation. # allow_undefined=no # FIXME: Unfortunately, there are problems with the above when trying # to make a dll which has undefined symbols, in which case not # even a static library is built. For now, we need to specify # -no-undefined on the libtool link line when we can be certain # that all symbols are satisfied, otherwise we get a static library. allow_undefined=yes Unfortunately, this breaks the default case on mingw32/msys (tested with mingw 5.1.2, msys 1.0.10, i.e. current stable), because the objects are first built to go into a DLL, hence symbols have _imp_ prefixes, then the static library is made from the objects (because allow_undefined has been set to yes), then when the static library is linked the linker complains that it can't find any symbols in the library (because it's not expecting the _imp_ prefixes, as it's a static library). Uncommenting allow_undefined=no and commenting allow_undefined=yes in the above makes it work. Does that mean if you put -no-undefined into the link flags then things work? Yes. If yes, then please do that. But this means that mingw users need to do something special. libtool still needs fixing. The current behaviour never works; the previous behaviour works in some cases. It would seem that the obvious thing to do is fix libtool so that allow_undefined=yes works on mingw, i.e. if allow_undefined=yes then compile for static linking, not for dynamic linking. -- http://rrt.sc3d.org/ | Slow Pedestrian Crossing (Anon) ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Problem with default builds on mingw32
libtool 1.5.22 contains the following (trivial) code and (non-trivial) comments: # It is impossible to link a dll without this setting, and # we shouldn't force the makefile maintainer to figure out # which system we are compiling for in order to pass an extra # flag for every libtool invocation. # allow_undefined=no # FIXME: Unfortunately, there are problems with the above when trying # to make a dll which has undefined symbols, in which case not # even a static library is built. For now, we need to specify # -no-undefined on the libtool link line when we can be certain # that all symbols are satisfied, otherwise we get a static library. allow_undefined=yes Unfortunately, this breaks the default case on mingw32/msys (tested with mingw 5.1.2, msys 1.0.10, i.e. current stable), because the objects are first built to go into a DLL, hence symbols have _imp_ prefixes, then the static library is made from the objects (because allow_undefined has been set to yes), then when the static library is linked the linker complains that it can't find any symbols in the library (because it's not expecting the _imp_ prefixes, as it's a static library). Uncommenting allow_undefined=no and commenting allow_undefined=yes in the above makes it work. I'm guessing that the fix was made for some other platform which has a similar problem in the reverse direction; perhaps more platform-specific intelligence is required here? I was trying to build SoX (http://sox.sf.net/) from current CVS, with automake 1.9.6, libtool 1.5.22 and autoconf 2.61, but from what I can see the problem is not dependent on the source being built. I configured and attempted to build with ./configure make. -- http://rrt.sc3d.org/ | mediate, v.i. to butt in (Bierce) ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
