normal ltdl linking suggestions?
Hi, the libtool info document has several suggestions how to link with libltdl. but they all imply to include the ltdl source in my projects source, and I don't want to do that. Also with most distributions shipping ltdl as a normal library with devel and runtime package, I see no reason for that, and would like to use libltdl simply like any other library. are there any suggestions how I should do that? my preferred choice - using pkg-config - is not available. it would be nice if libltdl could include a libltdl.pc file in the future! so far I used this in configure.in: dnl use ltdl AC_LIB_LINKFLAGS(ltdl) saved_LIBS="$LIBS" LIBS="$saved_LIBS $LIBLTDL" AC_CHECK_HEADER([ltdl.h], [AC_MSG_RESULT([yes])], [ AC_MSG_ERROR([ltdl.h not found, please install libltdl and/or libtool]) ]) LIBS="$saved_LIBS" but a co-developer found a problem with AC_LIB_LINKFLAGS which seem to come from gettext macro packages, and we don't want to add an unnecessary dependency on gettext only for using libltdl. Can you suggest a different way for finding and linking with ltdl? Thanks, Andreas ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: normal ltdl linking suggestions?
Hallo Andreas, On Jul 9, 2007, at 4:49 AM, Andreas Jellinghaus wrote: the libtool info document has several suggestions how to link with libltdl. but they all imply to include the ltdl source in my projects source, and I don't want to do that. Also with most distributions shipping ltdl as a normal library with devel and runtime package, I see no reason for that, and would like to use libltdl simply like any other library. All the world is not Linux. By not shipping libltdl at all, you're making life difficult for the users of hundreds of other platforms who will have to install their own libltdl just to build your package, which many will likely decide is too much effort. Compared to the megabyte or two of generated shell scripts and configure support files you're probably already shipping, shipping the libltdl sources too is not much of an overhead. are there any suggestions how I should do that? In the HEAD snapshots, the following is supposed to work: LT_WITH_LTDL([libltdl]) This still requires that you have a copy of libltdl in your package (in the subdirectory named by the argument), but allows the user to dynamically link against an installed libltdl if they prefer by calling: ./configure --without-included-ltdl I say "supposed" because that part of the tree is currently in flux as we work towards an alpha release from HEAD in the coming months. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912 PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Library order in gcc command
I am doing a test installation of GTK+ on top of DirectFB (instead of on X11). (I'm later going to cross compile this for an embedded system.) Now, GTK+ depends on Cairo, and Cairo in turn is compiled with support for either X11 or DirectFB as graphics backend. I'm installing everything to a separate directory (using ./configure --prefix=/home/install_dir), and that is where the DirectFB version of the Cairo libraries end up (in subdir lib/). I'm normally running X11 on this system, so an X11 version of the Cairo library is already installed in /usr/lib64. libtool is used by make to generate commands for building GTK+. libtool finds both versions of the Cairo library, but unfortunately it places the /usr/lib64 one first, and that makes the linker fail with undefined references. (If I run the command by hand, removing the /usr/lib64/libcairo.so reference, the command works fine, but there are many files to compile/link and I would like a better solution.) This is what is printed by make: /bin/sh ../libtool --mode=link gcc -DG_DISABLE_DEPRECATED -g -O2 -Wall -o gtk-query-immodules-2.0 queryimmodules.o libgtk-directfb-2.0.la ../gdk-pixbuf/libgdk_pixbuf-2.0.la ../gdk/libgdk-directfb-2.0.la gcc -DG_DISABLE_DEPRECATED -g -O2 -Wall -o .libs/gtk-query-immodules-2.0 queryimmodules.o ./.libs/libgtk-directfb-2.0.so -L/home/install_dir/usr/local//lib /home/install_dir/source/gtk+-2.10.13/gdk/.libs/libgdk-directfb-2.0.so -L/home/install_dir/usr/local/lib /home/install_dir/usr/local/lib/libatk-1.0.so ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so ../gdk/.libs/libgdk-directfb-2.0.so /home/install_dir/usr/local//lib/libpangocairo-1.0.so /usr/lib64/libcairo.so /usr/lib64/libglitz.so /usr/lib64/libXrender.so /usr/lib64/libX11.so /usr/lib64/libXau.so /usr/lib64/libXdmcp.so /home/install_dir/usr/local//lib/libpangoft2-1.0.so /home/install_dir/usr/local//lib/libpango-1.0.so /home/install_dir/usr/local//lib/libcairo.so /usr/lib64/libfontconfig.so /usr/lib64/libfreetype.so /usr/lib64/libxml2.so /home/install_dir/usr/local//lib/libdirectfb.so /home/install_dir/usr/local//lib/libfusion.so /home/install_dir/usr/local//lib/libdirect.so -lpthread /usr/lib64/libpng12.so -lz /home/install_di r/source/gtk+-2.10.13/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so /home/install_dir/usr/local//lib/libgmodule-2.0.so -ldl /home/install_dir/usr/local//lib/libgobject-2.0.so /home/install_dir/usr/local//lib/libglib-2.0.so -lm -Wl,--rpath -Wl,/home/install_dir/usr/local/lib -Wl,--rpath -Wl,/home/install_dir/usr/local//lib /home/install_dir/source/gtk+-2.10.13/gdk/.libs/libgdk-directfb-2.0.so: undefined reference to `cairo_directfb_surface_create' collect2: ld returned 1 exit status I have set LD_LIBRARY_PATH=/home/install_dir/lib - is this where libtool gets the path to the correct library? And most importantly, how do I get libtool to place the correct library before the /usr/lib64/libcairo.so one so that the link does not fail? Some system info: $ uname -a Linux shuttle 2.6.18-gentoo-r6 #3 Mon Jan 1 16:52:53 CET 2007 x86_64 AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux Thanks Arvid ___ http://lists.gnu.org/mailman/listinfo/libtool
building libtool in MinGW
Please cc me a copy of any replies as I am not on the list. Thank you. I downloaded the latest MinGW friday, and libtool's source today, both from stable: MinGW 5.1.3 installer libtool-1.9f I cannot get libtool to compile (I need it for OpenSSL I think), during the make process I get an error about not being able to find a .la file (libltdl/libdlloader.la, which has been created and is 911 bytes) [EMAIL PROTECTED] /c/Documents and Settings/stapleton.41/My Documents/apps/mingw/src/libtool-1.9f $ ls -lh libltdl/ | grep \.la -rw-r--r--1 stapleto Administ 911 Jul 9 10:29 libdlloader.la -rw-r--r--1 stapleto Administ 320 Jul 9 10:29 libltdl_la-lt_dlloader.lo -rw-r--r--1 stapleto Administ 12k Jul 9 10:29 libltdl_la-lt_dlloader.o -rw-r--r--1 stapleto Administ 299 Jul 9 10:29 libltdl_la-ltdl.lo -rw-r--r--1 stapleto Administ 60k Jul 9 10:29 libltdl_la-ltdl.o -rw-r--r--1 stapleto Administ 308 Jul 9 10:30 libltdl_la-preopen.lo -rw-r--r--1 stapleto Administ 15k Jul 9 10:30 libltdl_la-preopen.o To get make to work, I symlinked make.exe to mingw32-make $ ln -s /bin/mingw32-make.exe make.exe And my build command was: $ ./configure &> log.configure; make &> log.make The log files are at the end of the email. Thank you, -Jim Stapleton log.config ## ## ## Configuring libtool 1.9f ## ## ## checking for a BSD-compatible install... /mingw/bin/install -c checking whether build environment is sane... yes /c/Documents: /c/Documents: No such file or directory configure: WARNING: `missing' script is too old or missing checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking for a sed that does not truncate output... /mingw/bin/sed checking for egrep... grep -E checking for fgrep... grep -F checking for ld used by gcc... c:/MinGW/mingw32/bin/ld.exe checking if the linker (c:/MinGW/mingw32/bin/ld.exe) is GNU ld... yes checking for BSD-compatible nm... /mingw/bin/nm checking whether ln -s works... yes checking the maximum length of command line arguments... 8192 checking for c:/MinGW/mingw32/bin/ld.exe option to reload object files... -r checking how to recognise dependent libraries... file_magic file format pei*-i386(.*architecture: i386)? checking for ar... ar checking for strip... strip checking for ranlib... ranlib checking command to parse /mingw/bin/nm output from object... ok checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... no checking for as... as checking for dlltool... dlltool checking for objdump... objdump checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (c:/MinGW/mingw32/bin/ld.exe) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for an ANSI C-conforming const... yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking which extension is used for runtime loadable modules... .dll checking which variable specifies run-time module search path... PATH checking for the default library search path... /lib /usr/lib checking for dlopen in -ldl... no checking for dlopen in -lsvld... no checking for shl_load... no checking for shl_load in -ldld... no checking for dld_link in -ldld... no checking for _ prefix in compiled symbols... yes checking whether deplibs
Re: Library order in gcc command
On Mon, 2007-07-09 at 14:44 +0200, Arvid Brodin wrote: > I am doing a test installation of GTK+ on top of DirectFB (instead of on > X11). (I'm later going to cross compile this for an embedded system.) Now, > GTK+ depends on Cairo, and Cairo in turn is compiled with support for either > X11 or DirectFB as graphics backend. I'm installing everything to a separate > directory (using ./configure --prefix=/home/install_dir), and that is where > the DirectFB version of the Cairo libraries end up (in subdir lib/). I'm > normally running X11 on this system, so an X11 version of the Cairo library > is already installed in /usr/lib64. > > libtool is used by make to generate commands for building GTK+. libtool finds > both versions of the Cairo library, but unfortunately it places the > /usr/lib64 one first, and that makes the linker fail with undefined > references. (If I run the command by hand, removing the > /usr/lib64/libcairo.so reference, the command works fine, but there are many > files to compile/link and I would like a better solution.) > > > This is what is printed by make: > > /bin/sh ../libtool --mode=link gcc -DG_DISABLE_DEPRECATED -g -O2 -Wall -o > gtk-query-immodules-2.0 queryimmodules.o libgtk-directfb-2.0.la > ../gdk-pixbuf/libgdk_pixbuf-2.0.la ../gdk/libgdk-directfb-2.0.la > gcc -DG_DISABLE_DEPRECATED -g -O2 -Wall -o .libs/gtk-query-immodules-2.0 > queryimmodules.o ./.libs/libgtk-directfb-2.0.so > -L/home/install_dir/usr/local//lib > /home/install_dir/source/gtk+-2.10.13/gdk/.libs/libgdk-directfb-2.0.so > -L/home/install_dir/usr/local/lib > /home/install_dir/usr/local/lib/libatk-1.0.so > ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so ../gdk/.libs/libgdk-directfb-2.0.so > /home/install_dir/usr/local//lib/libpangocairo-1.0.so /usr/lib64/libcairo.so > /usr/lib64/libglitz.so /usr/lib64/libXrender.so /usr/lib64/libX11.so > /usr/lib64/libXau.so /usr/lib64/libXdmcp.so > /home/install_dir/usr/local//lib/libpangoft2-1.0.so > /home/install_dir/usr/local//lib/libpango-1.0.so > /home/install_dir/usr/local//lib/libcairo.so /usr/lib64/libfontconfig.so > /usr/lib64/libfreetype.so /usr/lib64/libxml2.so > /home/install_dir/usr/local//lib/libdirectfb.so > /home/install_dir/usr/local//lib/libfusion.so > /home/install_dir/usr/local//lib/libdirect.so -lpthread > /usr/lib64/libpng12.so -lz /home/install_di > r/source/gtk+-2.10.13/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so > /home/install_dir/usr/local//lib/libgmodule-2.0.so -ldl > /home/install_dir/usr/local//lib/libgobject-2.0.so > /home/install_dir/usr/local//lib/libglib-2.0.so -lm -Wl,--rpath > -Wl,/home/install_dir/usr/local/lib -Wl,--rpath > -Wl,/home/install_dir/usr/local//lib > /home/install_dir/source/gtk+-2.10.13/gdk/.libs/libgdk-directfb-2.0.so: > undefined reference to `cairo_directfb_surface_create' > collect2: ld returned 1 exit status > > I have set LD_LIBRARY_PATH=/home/install_dir/lib - is this where libtool gets > the path to the correct library? And most importantly, how do I get libtool > to place the correct library before the /usr/lib64/libcairo.so one so that > the link does not fail? check /home/install_dir/lib/*.la files for references to /usr/lib64 in dependency_libs. You may have to edit or remove them. Libtool is not great at building in a root like this. Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: building libtool in MinGW
On Mon, Jul 09, 2007 at 10:40:57AM -0400, S James S Stapleton wrote: > libtool-1.9f This alpha release is dated. However, current CVS is broken on MinGW. I would check out CVS from a month ago or use the latest 1.5 release. > [EMAIL PROTECTED] /c/Documents and Settings/stapleton.41/My > Documents/apps/mingw/src/libtool-1.9f Your srcdir/builddir name contains spaces. Use a directory with no spaces in the name; these cause problems: > /c/Documents: /c/Documents: No such file or directory > configure: WARNING: `missing' script is too old or missing > libtool: link: cannot find the library > `Documents/apps/mingw/src/libtool-1.9f/libltdl/libdlloader.la' ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: building libtool in MinGW
Thank you, -Jim Stapleton - Original Message - From: "Noah Misch" <[EMAIL PROTECTED]> To: "S James S Stapleton" <[EMAIL PROTECTED]> Cc: Sent: Monday, July 09, 2007 1:43 PM Subject: Re: building libtool in MinGW On Mon, Jul 09, 2007 at 10:40:57AM -0400, S James S Stapleton wrote: libtool-1.9f This alpha release is dated. However, current CVS is broken on MinGW. I would check out CVS from a month ago or use the latest 1.5 release. [EMAIL PROTECTED] /c/Documents and Settings/stapleton.41/My Documents/apps/mingw/src/libtool-1.9f Your srcdir/builddir name contains spaces. Use a directory with no spaces in the name; these cause problems: /c/Documents: /c/Documents: No such file or directory configure: WARNING: `missing' script is too old or missing libtool: link: cannot find the library `Documents/apps/mingw/src/libtool-1.9f/libltdl/libdlloader.la' ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: building libtool in MinGW
On Mon, 9 Jul 2007, Noah Misch wrote: On Mon, Jul 09, 2007 at 10:40:57AM -0400, S James S Stapleton wrote: libtool-1.9f This alpha release is dated. However, current CVS is broken on MinGW. I would check out CVS from a month ago or use the latest 1.5 release. This is the current breakage I see under MinGW: utilities/.libs/lt-gm.c: In function `main': utilities/.libs/lt-gm.c:245: `intptr_t' undeclared (first use in this function) utilities/.libs/lt-gm.c:245: (Each undeclared identifier is reported only once utilities/.libs/lt-gm.c:245: for each function it appears in.) utilities/.libs/lt-gm.c:245: parse error before "rval" utilities/.libs/lt-gm.c:331: `rval' undeclared (first use in this function) ./libtool: $func_ltwrapper_scriptname_result: ambiguous redirect but I think that otherwise it seems ok. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: normal ltdl linking suggestions?
Hi Gary, On Monday 09 July 2007 17:47:13 Gary V. Vaughan wrote: > All the world is not Linux. By not shipping libltdl at all, you're > making life difficult for the users of hundreds of other platforms who will > have to install their own libltdl just to build your package, which many > will likely decide is too much effort. well, my software works on linux, netbsd, freebsd, openbsd, dragonflybsd, debian/bsd debian/hurd, mac os X, solaris and windows, and i think I got success reports about aix and hpux, and embedded linux systems. I don't remember getting negative reports, so don't think the current situation without a copy of ltdl is bad. also at least two projects are libraries used by other applications, in one situation the library is actually an implemention of an ABI plugin standard. in those cases I may not link with my own copy of ltdl at all, but absolutely must use a shared copy of ltdl that can be used by both me and the application loading my "plugin". (I hope I'm understanding this correctly, but as far as I know having the same symbols in an application / the library it loads and a plugin / the shared libs that depends on) is a recipe for desaster or won't work at all on some plattforms.) so using a private copy of some library statically linked into my plugin could lead into problems (we had that necessity with openssl 0.9.6 and it was not pretty). also including a private copy of some code creates a maintenance nightmare for distribution. maybe you remember the zlib security issues a few years ago? the found dozends of copies in all kind of software that used a copy for convenience of the developers - and thus created extra maintenence work for the distributions. that won't happen very likely to ltdl, but still the lesson learned applies as general rule I think. > This still requires that you have a copy of libltdl in your package sorry, don't want to do that. distributions would need to change their spec files and rules files to add extra configure parameters, I don't want to create extra work for them. its not much work, but some maintain about 20k packages, so every small change counts. > I say "supposed" because that part of the tree is currently in flux > as we work towards an alpha release from HEAD in the coming months. ah, ok. thanks for the heads up. could you consider adding a pkg-config .pc file that is installed with the shared version of libltdl? that way people like me could use the normal macro package we use for every library, and wouldn't need to write special configure code or anything. pkg-config made configure script much more readable (compared to the spaghetti code I saw for years in way too many projects). Thanks for your help! though I'm still looking for a nice generic macro packages for finding ltdl, now that the latest version included in gettext is broken for me. maybe I should move to that mailing list and ask how I can use their macro package without the gettext dependency, as it was quite generic until recently. Regards, Andreas ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: normal ltdl linking suggestions?
On Mon, 9 Jul 2007, Andreas Jellinghaus wrote: Hi Gary, On Monday 09 July 2007 17:47:13 Gary V. Vaughan wrote: All the world is not Linux. By not shipping libltdl at all, you're making life difficult for the users of hundreds of other platforms who will have to install their own libltdl just to build your package, which many will likely decide is too much effort. well, my software works on linux, netbsd, freebsd, openbsd, dragonflybsd, debian/bsd debian/hurd, mac os X, solaris and windows, and i think I got success reports about aix and hpux, and embedded linux systems. I don't remember getting negative reports, so don't think the current situation without a copy of ltdl is bad. also at least two projects are libraries used by other applications, in one situation the library is actually an implemention of an ABI plugin standard. Your approach is outright heresy. With this approach, users would simply install a copy of GNU 'autobuild' prior to building all other packages. This would result in no need for embedded autoconf, automake, and libtool in all the packages. Shame on you for suggesting such an approach. Go stand in a corner. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: normal ltdl linking suggestions?
Hello, * Bob Friesenhahn wrote on Mon, Jul 09, 2007 at 10:54:34PM CEST: > On Mon, 9 Jul 2007, Andreas Jellinghaus wrote: > >On Monday 09 July 2007 17:47:13 Gary V. Vaughan wrote: > >>All the world is not Linux. By not shipping libltdl at all, you're > >>making life difficult for the users of hundreds of other platforms who > >>will have to install their own libltdl just to build your package, > >>which many will likely decide is too much effort. > > > >well, my software works on linux, netbsd, freebsd, openbsd, dragonflybsd, > >debian/bsd debian/hurd, mac os X, solaris and windows, and i think I got > >success reports about aix and hpux, and embedded linux systems. > >I don't remember getting negative reports, so don't think the current > >situation without a copy of ltdl is bad. also at least two projects are > >libraries used by other applications, in one situation the library is > >actually an implemention of an ABI plugin standard. > > Your approach is outright heresy. [...] FWIW, I don't agree with this notion. Let his users decide. (Also, there were some changes done to libltdl in the last year or so explicitly to allow using an installed library only. No outcry back then.) I don't think Libtool needs to provide a pkg-config file, but providing a macro to use an external libltdl, and having the macro set LTDLINCL and LIBLTDL (or other variables) correctly for use should work just fine. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
