Re: ltdl.c thinks it's psychic (another SEGFAULT bug).
>> > > what is any of this for in the first place? >> > >> >You mean why do we allos someone to define lt_dlmalloc, lt_dlrealloc, >> >and lt_dlfree? I don't know :) >> >> yes, thats precisely what i mean. what problem is this attempting to >> solve? some bizarre platform where ltdl.c can't call malloc()? > >Personally I consider this to be a good thing for libraries. It is useful >if you want to use a different (underlying) memory allocation API. >Imagine you want to pass part of a shared memory arena (IRIX uses such) >and libltdl.so tries to free() it with the standard libc call, this might >fail and crash the program. Also M$-Windows knows different >memory allocator APIs. i have no problem with that. the issue is: why is there any support for this on a per-library basis? i may have mentioned before that most of my programs use libhoard, which completely replaces malloc,free and realloc with ultra-fast-for-SMP-multithreaded equivalents. why on earth do i want to tell ltdl (or any other particular library) to be using a version of malloc/free/realloc that's any different from the one used by the rest of the libraries linked to my progam? replacing malloc() is often a good idea. but replacing malloc on a per-library basis? why? and besides, if you pass an acquired resource to an API, then you either have to specify that its not the API's job to release it, or provide the API with a way to do so. Since lt_dlmalloc() and lt_dlfree() are intended for use entirely *within* the library, they do not cover this condition, as far as i can see. --p ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: ltdl.c thinks it's psychic (another SEGFAULT bug).
>Because ltdl.h already states that libltdl relies on a featureful >realloc, let's just set lt_dlrealloc = realloc and test for a >featureful realloc in ltdl.m4. Let's recommend that if anyone changes >at least one of lt_dlmalloc, lt_dlrealloc, or lt_dlfree, then they >should also change them all. Let the client worry about malloc/free >and ltdl be somewhat stupid to the choices of the client. what is any of this for in the first place? --p ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: ltdl.c thinks it's psychic (another SEGFAULT bug).
>> what is any of this for in the first place? > >You mean why do we allos someone to define lt_dlmalloc, lt_dlrealloc, >and lt_dlfree? I don't know :) yes, thats precisely what i mean. what problem is this attempting to solve? some bizarre platform where ltdl.c can't call malloc()? --p ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: use of libtool for linking executables - rpath problem
>I can see six possible approaches: The 7th is to have the shared library use pkg-config, allowing other tools to find out about it without relying on the linker configuration. Its much cleaner than any of the other choices you mention, and thankfully, has nothing to do with libtool (phew!) --p ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: use of libtool for linking executables - rpath problem
>> The 7th is to have the shared library use pkg-config, allowing other
>> tools to find out about it without relying on the linker configuration.
>> Its much cleaner than any of the other choices you mention, and
>> thankfully, has nothing to do with libtool (phew!)
>
>Can you please elaborate more: How is this going to provide the
>platform and compiler specific rpath option?
do you know what pkgconfig is?
your library would start with a file that looked that this:
--
prefix=@prefix@
exec_prefix=@exec_prefix@
libdir=@libdir@
includedir=@includedir@/ardour
Name: libardour
Version: @VERSION@
Description: libardour, a library for building professional digital audio applications
Requires: libpbd, libmidi++, libaudioengine >= 1.6.0 , libxml-2.0 >= 2.4.6
Libs: -L${libdir} -lardour @NON_PKG_LIBS@
Cflags: -I${includedir} @NON_PKG_CFLAGS@
--
this would be processed by *its* configure script to look like:
--
prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include/ardour
Name: libardour
Version: 0.408.0
Description: libardour, a library for building professional digital audio applications
Requires: libpbd, libmidi++, libaudioengine >= 1.6.0 , libxml-2.0 >= 2.4.6
Libs: -L${libdir} -lardour -lsndfile -lgdbm -L/usr/local/lib -lsigc -lpthread
-L/usr/local/lib -lglib
Cflags: -I${includedir} -I/usr/local/lib/sigc++/include -I/usr/local/include
-I/usr/local/lib/glib/include -I/usr/local/include
--
"make install" will put that file where pkg-config can find it. after
that, its then possible to do:
1) from the shell:
pkg-config --libs libardour
pkg-config --cflags libardour
2) from another configure script:
PKG_CHECK_MODULES(ARDOUR,libardour >= someversion)
resulting in the setting of
ARDOUR_LIBS
ARDOUR_CFLAGS
to the output of pkg-config --libs libardour and
pkg-config --cflags libardour
thus allowing an application to discover precisely what it needs to
know in order to link to, in this case, libardour.
of course, its up to you decide if you want to specify -rpath info, or
rely on the user to set LD_LIBRARY_PATH and/or configure ld.so, but
pkg-config will reflect those choices faithfully.
go read about pkg-config. check google for a URL - i don't have one handy.
its the greatest thing since, well, definitely since all those silly
*.m4 files most of us writing libraries end up with.
--p
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: use of libtool for linking executables - rpath problem
>What is needed is a "database" which acts as a registry of installed >packages. This would be updatable by 'make install' as well as binary >packaging tools. all of GNOME is now using pkg-config for this purpose. > A tool would be provided to formulate the optimum >-I, -L, and -llibs options required to build using a set of libraries. pkg-config doesn't do that. its an almost impossible task unless you rely on the package authors to be reasonable and sensible; if you do that, then you don't need to do this anyway. >The database would need to be distributable across multiple prefixes >in order to handle the case where libraries are provided by the >system, installed to a common local directory, and installed in a >private directory. pkg-config not only handles this, but even handles using packages that are not yet even installed (merely built). --p ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: use of libtool for linking executables - rpath problem
>> pkg-config doesn't do that. its an almost impossible task unless you > >Are you talking about some new tool that I had not previously heard >about or are you talking about a script like the >'/usr/local/bin/gnome-config' I see on my system? its a replacement for *all* such scripts. its a C program that works with a great deal more intelligence than those scripts. its independent of GNOME and everything else, for that matter. >Unfortunately gtk standardized this type of script through >proliferation. The proliferation occured because no other option was >offered. It's mere popularity does not make it the right solution. absolutely. thats why i am so enthusiastic about pkg-config. unlike those silly scripts, pkg-config centralizes the information and at least in theory it offers a point at which the kind of rationalization and ordering problems discussed here can be solved. >The scripts options do not even align with Autoconf since Autoconf >distinguishes options with finer granularity than the *-config scripts >do: > > *-config Autoconf > == = > --libs LDFLAGS + LIBS > --cflags CPPFLAGS + CFLAGS > >The munging of LDFLAGS and LIBS to create the output from the --libs >option creates a bloody mess when you try to blend these options >together. Linker directory search order and library link order are >totally lost if a simple concatenation of options is used. Understood. As I mentioned before, this is an impossible task to automate in the general case. >The only proper solution is one based on a rules database in which the >dependency requirements for each package can be expressed so that the >dependencies can be reliabily satisified by the build environment. No, thats insufficient. Link order is not solely a function of dependency requirements. Its a complex interaction of user intent, system configuration and library contents. Since the user intent is the wild card, only some method by which the user can clearly express her intent will work. If I want to link libhoard in at an early stage, and libdmalloc later on, because i want free/malloc/realloc from hoard to be used by the earlier objects, but the ones from dmalloc to be used by the later ones ... there is no way that a dependency database can infer this. >Libtools .la files do not provide this database. Pkg-config scripts do >not provide this database. They do not, but they are closer to it, and form a much better starting point than the godawful mess that libtool has turned into. "libtool --gdb" for crying out loud! --p ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
