Historically-derived confusion in libtool manual

2007-11-16 Thread Reuben Thomas
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

2007-05-03 Thread Reuben Thomas

 `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

2007-01-08 Thread Reuben Thomas

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

2007-01-03 Thread Reuben Thomas
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