Getting executable to link to libtool-built library
Hello, I have two related programs (tuxmath and tuxtype) that share a lot of code in a human-maintained, copy-and-past fashion. We have been working on moving the overlapping code into a separate library package, libt4kcommon. All the programs use Autoconf, Automake, and Gettext where needed. I have been able to build libt4kcommon using lib_LTLIBRARIES = libt4kcommon.la in the relevant Makefile.am. The library builds a tarball successfully with make distcheck, and installs under /usr/local/lib with make install. So far so good. I'm running into trouble, however, when I try to use the library in e.g. tuxmath. Since the library is being built separately from tuxmath, I believe I need to use AC_CHECK_LIB in tuxmath's configure.ac. However, the configure script fails to find it, even thought the library files are present. I also tried using LDADD = /usr/local/lib/libt4kcommon.la in tuxmath's Makefile.am, which fails with no rule to make libt4kcommon.la needed by tuxmath. However, I don't think LDADD is the correct approach here anyway. Anyone have any suggestions for the probably obvious step I'm missing? Thanks, David Bruce ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Getting executable to link to libtool-built library
Hello, On Mon, Dec 28, 2009 at 3:22 AM, Alberto Luaces alua...@udc.es wrote: David Bruce writes: Hello, I have two related programs (tuxmath and tuxtype) that share a lot of code in a human-maintained, copy-and-past fashion. We have been working on moving the overlapping code into a separate library package, libt4kcommon. All the programs use Autoconf, Automake, and Gettext where needed. Does anyone have any suggestions for the probably obvious step I'm missing? Can you try configure LDFLAGS=-L/usr/local/lib ? Also check that /usr/local/lib is present in your /etc/ld.so.conf or your LD_LIBRARY_PATH environment variable. OK, I can get it to work post-installation with either LD_LIBRARY_PATH or the ldconfig+/etc/ld.so.conf mechanism. What I want to learn is the right way to do this as a programmer/packager from an autotools perspective so that a user can do ./configure; make; sudo make install on my lib package (libt4kcommon)and on my executable package (tuxmath) and have it work. Ideally, I would like to be able build a tarball that has both the lib and executable for standalone installation, but have them be packagable separately for e.g. Debian. Perhaps this is where nested packages fit in? Maybe I should move this to the Autoconf list? Thanks, David Bruce ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Getting executable to link to libtool-built library
David Bruce writes: OK, I can get it to work post-installation with either LD_LIBRARY_PATH or the ldconfig+/etc/ld.so.conf mechanism. What I want to learn is the right way to do this as a programmer/packager from an autotools perspective so that a user can do ./configure; make; sudo make install on my lib package (libt4kcommon)and on my executable package (tuxmath) and have it work. This is user responsibility; if the user installs a library in some directory, the user has also to tell its system to look for libraries there. For example, in my Debian system, /usr/local/lib is included by default in the directories' list to be looked at when searching libs. Ideally, I would like to be able build a tarball that has both the lib and executable for standalone installation, but have them be packagable separately for e.g. Debian. Perhaps this is where nested packages fit in? Maybe I should move this to the Autoconf list? Debian packagers can split the tarball compilation results in as many packages as they wish, so I think only one tarball is fine unless the program or the library are going to have a wildly different rate of development. -- Alberto ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool 1.5.26: OpenBSD and -pthread
Hey, When passing -pthread to my_lib_LDFLAGS and my_lib_CFLAGS in Makefile.am, on OpenBSD (libtool 1.5.26), the linker does not have -lpthread, but just -pthread : gcc -shared -fPIC -DPIC -o .libs/libeina-ver-pre-svn-05.so.9.9 .libs/libeina_la-eina_error.o .libs/libeina_la-eina_log.o .libs/libeina_la-eina_hash.o .libs/libeina_la-eina_lalloc.o .libs/libeina_la-eina_inlist.o .libs/libeina_la-eina_file.o .libs/libeina_la-eina_mempool.o .libs/libeina_la-eina_list.o .libs/libeina_la-eina_matrixsparse.o .libs/libeina_la-eina_module.o .libs/libeina_la-eina_value.o .libs/libeina_la-eina_array.o .libs/libeina_la-eina_magic.o .libs/libeina_la-eina_main.o .libs/libeina_la-eina_counter.o .libs/libeina_la-eina_iterator.o .libs/libeina_la-eina_accessor.o .libs/libeina_la-eina_convert.o .libs/libeina_la-eina_fp.o .libs/libeina_la-eina_rbtree.o .libs/libeina_la-eina_benchmark.o .libs/libeina_la-eina_rectangle.o .libs/libeina_la-eina_stringshare.o .libs/libeina_la-eina_cpu.o .libs/libeina_la-eina_tiler.o .libs/libeina_la-eina_hamster.o .libs/libeina_la-eina_safety_checks.o -L/usr/local/lib -lintl -liconv -L/usr/X11R6/lib -L/lib -lm -march=prescott -msse -msse2 -msse3 -pthread -pthread Is there a known problem with OpenBSD and -pthread, using libtool 1.5.26 ? thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.26: OpenBSD and -pthread
On Mon, 28 Dec 2009, Vincent Torri wrote: When passing -pthread to my_lib_LDFLAGS and my_lib_CFLAGS in Makefile.am, on OpenBSD (libtool 1.5.26), the linker does not have -lpthread, but just -pthread : Is -pthread not sufficient to do everything needed? Notice that this is GCC and not just the linker. GCC is expected to respond to -pthread. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.26: OpenBSD and -pthread
On Mon, 28 Dec 2009, Bob Friesenhahn wrote: On Mon, 28 Dec 2009, Vincent Torri wrote: When passing -pthread to my_lib_LDFLAGS and my_lib_CFLAGS in Makefile.am, on OpenBSD (libtool 1.5.26), the linker does not have -lpthread, but just -pthread : Is -pthread not sufficient to do everything needed? Notice that this is GCC and not just the linker. GCC is expected to respond to -pthread. if we just pass -pthread, then a binary using the library gives, for example, the error: tig$ eet eet:/usr/local/lib/eina/mp/eina_chained_mempool.so: undefined symbol 'pthread_mutex_unlock' Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
