Re: libtool 1.5.6 still not supporting make distcheck
Well, I finally solved the problem. After another person on our team reported that 1.5.6 started working for them again after some configure.ac changes to our project (even though it still failed for me), I went out and grabbed Mandrake's src.rpm package and started going through the 12 patches they added to libtool 1.5.6. It appears that the danger patch is: libtool-1.5.6-relink.patch, which contains. --- libtool-1.5.6/ltmain.in.relink 2004-05-02 23:02:14.052575000 +0800 +++ libtool-1.5.6/ltmain.in 2004-05-02 23:06:05.990315424 +0800 @@ -3662,15 +3662,23 @@ fi tmp_deplibs= + inst_prefix_arg= for test_deplib in $deplibs; do case $convenience in * $test_deplib *) ;; *) - tmp_deplibs=$tmp_deplibs $test_deplib + if test -n $inst_prefix_dir (echo $test_deplib | grep -- $inst_prefix_dir /dev/null); then + inst_prefix_arg=$test_deplib + else + tmp_deplibs=$tmp_deplibs $test_deplib + fi ;; esac done deplibs=$tmp_deplibs + if test -n $inst_prefix_arg; then + deplibs=$inst_prefix_arg $deplibs + fi if test -n $convenience; then if test -n $whole_archive_flag_spec; then After I removed that patch from the build, rebuilt the rpm, and installed, I can now get everything working with libtool. Sorry for the Red Herring here folks, as this wasn't a true libtool issue, but a vendor patch instead. I'm going to report the bug to Mandrake tomorrow, hopefully they'll remove this patch from any future libtool releases. -Sean -- __ Sean Dague Mid-Hudson Valley sean at dague dot netLinux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __ pgpl0NykcwE6i.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.6 still not supporting make distcheck
On Sat, Nov 20, 2004 at 04:48:47PM +0100, Ralf Wildenhues wrote: * Sean Dague wrote on Wed, Nov 17, 2004 at 06:07:55PM CET: On Tue, Nov 16, 2004 at 06:32:51PM -0800, Jacob Meuser wrote: snip curious also what's in ../utils/libopenhpiutils.la *snip* openhpi/openhpi-1.9.3/_build/utils/libopenhpiutils.la contains the following: Am thinking.. does the failure also happen if you apply this? Index: src/Makefile.am === RCS file: /cvsroot/openhpi/openhpi/src/Makefile.am,v retrieving revision 1.51 diff -u -r1.51 Makefile.am --- src/Makefile.am 16 Nov 2004 19:16:52 - 1.51 +++ src/Makefile.am 20 Nov 2004 15:46:46 - @@ -59,8 +59,8 @@ session.c \ oHpi.c -libopenhpi_la_LIBADD= @STATIC_PLUGIN_LIBS@ @STATIC_PLUGIN_EXTRA_LIBS@ $(top_builddir)/utils/libopenhpiutils.la -libopenhpi_la_LDFLAGS = -L$(top_builddir)/utils -version-info @HPI_LIB_VERSION@ -export-symbols $(top_srcdir)/src/hpi.sym +libopenhpi_la_LIBADD= @STATIC_PLUGIN_LIBS@ @STATIC_PLUGIN_EXTRA_LIBS@ ../utils/libopenhpiutils.la +libopenhpi_la_LDFLAGS = -version-info @HPI_LIB_VERSION@ -export-symbols $(top_srcdir)/src/hpi.sym libopenhpi_la_DEPENDENCIES = @STATIC_PLUGIN_LIBS@ $(top_srcdir)/src/hpi.sym $(top_builddir)/utils/libopenhpiutils.la: If it does not help, could you show the contents of the *uninstalled* .la files (both libopenhpi.la as well as ..utils.la)? Regards, Ralf That doesn't seem to change anything. Here is the requested info: dargo:~/openhpi-1.9.3-rc/openhpi-1.9.3/_build/src cat libopenhpi.la # libopenhpi.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libopenhpi.so.1' # Names of this library. library_names='libopenhpi.so.1.9.3 libopenhpi.so.1 libopenhpi.so' # The name of the static archive. old_library='libopenhpi.a' # Libraries that this one depends upon. dependency_libs=' /home/sdague/openhpi-1.9.3-rc/openhpi-1.9.3/_build/utils/libopenhpiutils.la /usr/lib/libltdl.la -ldl /usr/lib/libgthread-2.0.la /usr/lib/libglib-2.0.la -lm -lpthread ' # Version information for libopenhpi. current=10 age=9 revision=3 # Is this an already installed library? installed=no # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/home/sdague/openhpi-1.9.3-rc/openhpi-1.9.3/_inst/lib' relink_command=(cd /home/sdague/openhpi-1.9.3-rc/openhpi-1.9.3/_build/src; /bin/sh ../libtool --mode=relink gcc -g -O2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Wall -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wformat=2 -Wformat-security -Wformat-nonliteral -Wno-format-y2k -Wcast-qual -Wcast-align -Werror -D_GNU_SOURCE -D_REENTRANT -fexceptions -g -O2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Wall -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wformat=2 -Wformat-security -Wformat-nonliteral -Wno-format-y2k -Wcast-qual -Wcast-align -Werror -D_GNU_SOURCE -D_REENTRANT -fexceptions -o libopenhpi.la -rpath /home/sdague/openhpi-1.9.3-rc/openhpi-1.9.3/_inst/lib -version-info 10:3:9 -export-symbols ../../src/hpi.sym config.lo domain.lo event.lo alarm.lo hotswap.lo lock.lo plugin.lo plugin_static.lo init.lo safhpi.lo session.lo oHpi.lo ../utils/libopenhpiutils.la -lltdl -pthread -lgthread-2.0 -lglib-2.0 -lm -lpthread @inst_prefix_dir@) - dargo:~/openhpi-1.9.3-rc/openhpi-1.9.3/_build/utils cat libopenhpiutils.la # libopenhpiutils.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libopenhpiutils.so.1' # Names of this library. library_names='libopenhpiutils.so.1.9.3 libopenhpiutils.so.1 libopenhpiutils.so' # The name of the static archive. old_library='libopenhpiutils.a' # Libraries that this one depends upon. dependency_libs=' /usr/lib/libltdl.la -ldl /usr/lib/libgthread-2.0.la /usr/lib/libglib-2.0.la -lm -lpthread' # Version information for libopenhpiutils. current=10 age=9 revision=3 # Is this an already installed library? installed=no # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/home/sdague/openhpi-1.9.3-rc/openhpi-1.9.3/_inst/lib' Hope this helps spur any new thoughts. -Sean --
Re: libtool 1.5.6 still not supporting make distcheck
On Tue, Nov 16, 2004 at 06:32:51PM -0800, Jacob Meuser wrote: snip curious also what's in ../utils/libopenhpiutils.la probably installed=yes and libdir='/home/sdague/openhpi/openhpi-1.9.3/_inst/lib' but openhpi/openhpi-1.9.3/_build/utils/libopenhpiutils.la contains the following: ... # Is this an already installed library? installed=no # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/home/sdague/openhpi/openhpi-1.9.3/_inst/lib' /home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.so doesn't yet exist? Nothing exists in _inst except directories, as this phase of make distcheck is happening after it has done make uninstall on the _inst directory. If I scroll back through the logs a little I see the following: make[3]: Entering directory /home/sdague/openhpi/openhpi-1.9.3/_build/utils' make[4]: Entering directory /home/sdague/openhpi/openhpi-1.9.3/_build/utils' /bin/sh ../../mkinstalldirs /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib mkdir -p -- /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib /bin/sh ../libtool --mode=install /usr/bin/install -c libopenhpiutils.la /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.la /usr/bin/install -c .libs/libopenhpiutils.so.1.9.3 /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.so.1.9.3 (cd /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib rm -f libopenhpiutils.so.1 ln -s libopenhpiutils.so.1.9.3 libopenhpiutils.so.1) (cd /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib rm -f libopenhpiutils.so ln -s libopenhpiutils.so.1.9.3 libopenhpiutils.so) /usr/bin/install -c .libs/libopenhpiutils.lai /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.la /usr/bin/install -c .libs/libopenhpiutils.a /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.a ranlib /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.a chmod 644 /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.a libtool: install: warning: remember to run libtool --finish /home/sdague/openhpi/openhpi-1.9.3/_inst/lib' /bin/sh ../../mkinstalldirs /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/pkgconfig mkdir -p -- /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/pkgconfig /usr/bin/install -c -m 644 openhpiutils.pc /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/pkgconfig/openhpiutils.pc make[4]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build/utils' make[3]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build/utils' make[2]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build/utils' Which looks all well and good, *except*: dargo:~ find /home/sdague/tmp/am-dc-21193 find: /home/sdague/tmp/am-dc-21193: No such file or directory I don't see anything in the make output that should have removed this. maybe this patch helps? --- ltmain.in.origTue Aug 3 00:49:02 2004 +++ ltmain.in Sat Aug 7 17:00:56 2004 @@ -2611,7 +2611,7 @@ EOF add_dir= add= # Finalize command for both is simple: just hardcode it. - if test $hardcode_direct = yes; then + if test $hardcode_direct = yes test -f $libdir/$linklib; then add=$libdir/$linklib elif test $hardcode_minus_L = yes; then add_dir=-L$libdir I've applied this patch, but still no luck. :( Thanks for the attempt though. -Sean -- __ Sean Dague Mid-Hudson Valley sean at dague dot netLinux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __ pgpGaVSzxqDMK.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.6 still not supporting make distcheck
On Tue, Nov 16, 2004 at 09:49:46PM -0600, Bob Friesenhahn wrote: On Tue, 16 Nov 2004, Jacob Meuser wrote: curious also what's in ../utils/libopenhpiutils.la probably installed=yes and libdir='/home/sdague/openhpi/openhpi-1.9.3/_inst/lib' but /home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.so doesn't yet exist? If this is the case then this means that the lib_LTLIBRARIES specification is ordered incorrectly in Makefile.am. Unfortunately, Automake does not yet have a way to ensure that libraries are installed in the correct order. It becomes the developer's responsibility to ensure that lib_LTLIBRARIES is in the ideal order. ... AM_CFLAGS = @CFLAGS@ lib_LTLIBRARIES = libopenhpi.la libopenhpi_la_SOURCES = \ ... There is only one library being built in this directory, so there can't be an ordering issue here. The other library is built in a different directory which is listed well before in the SUBDIR order. To be extra safe I even added: $(top_builddir)/utils/libopenhpiutils.la: make -C $(top_builddir)/utils libopenhpiutils.la to the Makefile.am -Sean -- __ Sean Dague Mid-Hudson Valley sean at dague dot netLinux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __ pgpOojSMJVuCl.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.6 still not supporting make distcheck
On Wed, 17 Nov 2004, Sean Dague wrote: /home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.so doesn't yet exist? If this is the case then this means that the lib_LTLIBRARIES specification is ordered incorrectly in Makefile.am. Unfortunately, Automake does not yet have a way to ensure that libraries are installed in the correct order. It becomes the developer's responsibility to ensure that lib_LTLIBRARIES is in the ideal order. ... AM_CFLAGS = @CFLAGS@ lib_LTLIBRARIES = libopenhpi.la libopenhpi_la_SOURCES = \ ... There is only one library being built in this directory, so there can't be an ordering issue here. The other library is built in a different directory which is listed well before in the SUBDIR order. To be extra safe I even added: If the library fails to be found, that must mean that the Makefile in the other directory failed to install the library at the right time, or into the right location. There is also the possibility that a necessary -L option is missing so libtool fails to find the library in the installation directory. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.6 still not supporting make distcheck
On Mon, Nov 15, 2004 at 04:20:05PM +0100, Ralf Wildenhues wrote: * Sean Dague wrote on Thu, Nov 11, 2004 at 09:45:40PM CET: The issue I reported a couple weeks ago is still there. We have now tracked down based on a number of versions of libtool to figure out what works and what doesn't. libtool 1.4.x - all versions work that we've tried libtool 1.5.2 - works libtool 1.5.6 - doesn't work libtool 1.5.10 - doesn't work The end of the logs are included at the end of this email (on libtool 1.5.6): First: Your build is not VPATH clean, because you are doing a lot of symlinking by hand in several Makefile.am's. Yes, we are doing this because there is a need to build test cases which use our real code, and the symlink solution seemed to be the most workable. First, you should be using $(LN_S) together with AC_PROG_LN_S for symlinks Agreed, making that change now second you should link to $(srcdir)/relpath/$@ instead Also agreed, making that change now third you should probably instead just be using AC_CONFIG_LINKS and be happy that you don't have to care about this yourself. All explained in Autoconf docs. I'll look into that possibility as well, though wouldn't that require centralizing all linking code to configure.ac, instead of letting the Makefile.am deal with it locally? Apart from these changes, `make distuninstallcheck' is the first part of `make distcheck' to complain, and it complains about some files which `make uninstall' misses to remove. This is with the HEAD branch as well as branch-1-5 of libtool. So, can you try either the patch from http://lists.gnu.org/archive/html/bug-libtool/2004-10/msg00170.html and possibly branch-2-0 from CVS? Please tell us your findings. I will check it out and report my results. What is most interesting is that the /home/sdague/tmp/am-dc-21838//home/sdague/openhpi/openhpi-1.9.3/ directory doesn't exist at all on my system. That seems to be created very late in the make distcheck processing, but why it isn't there I'm not sure. I /think/ this has nothing to do with your problem (though I cannot be sure, as I haven't understood what went wrong), and is fine because `make distcheck' is attempting a DESTDIR install. BTW, you did not mention your system at all, neither whether you are doing a VPATH build or not. All of this would have been helpful (still is if the problem remains unsolved), also whether or not an installed version of your package exists on your system or not. Excuse my ignorance, but I'm not sure of what a VPATH build is. The system I am running on is Mandrake Linux 10.1 on x86 (we've seen the failure with FC3 as well). There is not and installed version of the libraries on my system. Thanks for your help, -Sean -- __ Sean Dague Mid-Hudson Valley sean at dague dot netLinux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __ pgpa3HXV9Yx0k.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.6 still not supporting make distcheck
[ slightly reordered your answers for ease of consistent answers ] * Sean Dague wrote on Tue, Nov 16, 2004 at 05:56:11PM CET: On Mon, Nov 15, 2004 at 04:20:05PM +0100, Ralf Wildenhues wrote: * Sean Dague wrote on Thu, Nov 11, 2004 at 09:45:40PM CET: The issue I reported a couple weeks ago is still there. We have now tracked down based on a number of versions of libtool to figure out what works and what doesn't. First: Your build is not VPATH clean, because you are doing a lot of symlinking by hand in several Makefile.am's. Yes, we are doing this because there is a need to build test cases which use our real code, and the symlink solution seemed to be the most workable. Sure, the idea seems fine to me. BTW, you did not mention your system at all, neither whether you are doing a VPATH build or not. All of this would have been helpful (still is if the problem remains unsolved), also whether or not an installed version of your package exists on your system or not. Excuse my ignorance, but I'm not sure of what a VPATH build is. Where the build tree is different from the source tree. (It's called that way because the necessary `make' feature has to do with the VPATH make variable). Example: Your source is in /tmp/openhpi/. I do: $ mkdir /tmp/build-openhpi cd /tmp/build-openhpi $ ../openhpi/configure -C $ make Actually, to find such and other dependency bugs quickly, I replaced the `make' with: $ make -j2 distcheck First, you should be using $(LN_S) together with AC_PROG_LN_S for symlinks Agreed, making that change now second you should link to $(srcdir)/relpath/$@ instead Also agreed, making that change now Watch out. You link to some built sources and some non-built sources. When trying your code, I replaced the link-setting snippets with something like $(REMOTE_LIB_SOURCES): if test ! -f $@ -a ! -L $@; then \ if test -f ../$@; then \ $(LN_S) ../$@ $@; \ else \ $(LN_S) $(srcdir)/../$@ $@; \ fi; \ fi so that they would still work regardless where the file-to-link-to was found. Also, note that this is safe only if $(REMOTE_LIB_SOURCES) contains only target names in the current directory (also explained in Autoconf docs). third you should probably instead just be using AC_CONFIG_LINKS and be happy that you don't have to care about this yourself. All explained in Autoconf docs. I'll look into that possibility as well, though wouldn't that require centralizing all linking code to configure.ac, instead of letting the Makefile.am deal with it locally? Yes. This is arguably a deficiency. However, first it replaces each snippet as above to one short line, second you probably could move it into a separate .m4 file where you define a macro which you then use in configure.ac. I don't know if the latter is worth the effort. Apart from these changes, `make distuninstallcheck' is the first part of `make distcheck' to complain, and it complains about some files which `make uninstall' misses to remove. This is with the HEAD branch as well as branch-1-5 of libtool. So, can you try either the patch from http://lists.gnu.org/archive/html/bug-libtool/2004-10/msg00170.html and possibly branch-2-0 from CVS? Please tell us your findings. I will check it out and report my results. Great! The system I am running on is Mandrake Linux 10.1 on x86 (we've seen the failure with FC3 as well). There is not and installed version of the libraries on my system. Good to know. If this thread gets more application-dependent and less libtool-dependent, we should probably move to some openhpi-related list (Cc: me then, please, as I don't read any of those). Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.6 still not supporting make distcheck
On Tue, Nov 16, 2004 at 06:24:21PM +0100, Ralf Wildenhues wrote: snip Agreed, making that change now second you should link to $(srcdir)/relpath/$@ instead Also agreed, making that change now Watch out. You link to some built sources and some non-built sources. When trying your code, I replaced the link-setting snippets with something like $(REMOTE_LIB_SOURCES): if test ! -f $@ -a ! -L $@; then \ if test -f ../$@; then \ $(LN_S) ../$@ $@; \ else \ $(LN_S) $(srcdir)/../$@ $@; \ fi; \ fi so that they would still work regardless where the file-to-link-to was found. Also, note that this is safe only if $(REMOTE_LIB_SOURCES) contains only target names in the current directory (also explained in Autoconf docs). Yes, we only link into the current directory, so this should be sane. I have now made all the changes to let a VPATH build cleanly for both make and make check (which included normalizing some of the includes). snip Apart from these changes, `make distuninstallcheck' is the first part of `make distcheck' to complain, and it complains about some files which `make uninstall' misses to remove. This is with the HEAD branch as well as branch-1-5 of libtool. So, can you try either the patch from http://lists.gnu.org/archive/html/bug-libtool/2004-10/msg00170.html and possibly branch-2-0 from CVS? Please tell us your findings. I will check it out and report my results. Great! I applied the patch to my local ltmain.sh, and the problem still persists as before (I can regenerate the output if you like, but the build errors out at the same place as before). I haven't tried branch-2-0 yet, will try a whack at this later on today. The system I am running on is Mandrake Linux 10.1 on x86 (we've seen the failure with FC3 as well). There is not and installed version of the libraries on my system. Good to know. If this thread gets more application-dependent and less libtool-dependent, we should probably move to some openhpi-related list (Cc: me then, please, as I don't read any of those). I think the problem is still with the build system, as all of our code worked on earlier versions. I'm not sure if libtool is the only culprit here, or if there is some bad interaction of autotools and gcc as well. Thanks for the help so far, any other thoughts on where I might look for a solution to this problem? -Sean -- __ Sean Dague Mid-Hudson Valley sean at dague dot netLinux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __ pgpaIlGrp8Sw6.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.6 still not supporting make distcheck
I just was able to get a debian system up to basically the same revision levels of autotools as my desktop system an it gets through make distcheck. Which means it isn't a libtool issue, but I'm still hoping someone might still be able to help me figure out what part of the toolchain is to blame. Here is the working system: Debian Testing gcc (GCC) 3.4.2 (Debian 3.4.2-2) autoconf (GNU Autoconf) 2.59 automake (GNU automake) 1.7.9 ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) Debian: 220 $ GNU ld version 2.15 Non working system: Mandrake 10.1 gcc-3.4.1 (GCC) 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk) autoconf (GNU Autoconf) 2.59 automake (GNU automake) 1.7.9 ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) GNU ld version 2.15.90.0.3 20040415 Could ld be to blame here? Thanks for the help so far. Any ideas here would be greatly appreciated. Please let me know if anything else in the toolchain might be suspect. -Sean -- __ Sean Dague Mid-Hudson Valley sean at dague dot netLinux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __ pgpwdrH7F9SK0.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.6 still not supporting make distcheck
Bob,
The following log is still valid for where the breakdown occurs:
http://dague.net/libtool.txt.
That is a complete build log, plus all versions of the software.
The problem comes at:
/bin/sh ../../mkinstalldirs
/home/sdague/tmp/am-dc-28498//home/sdague/openhpi/openhpi-1.9.3/_inst/lib
/bin/sh ../libtool --mode=install /usr/bin/install -c libopenhpi.la
/home/sdague/tmp/am-dc-28498//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpi.la
libtool: install: warning: relinking libopenhpi.la'
(cd /home/sdague/openhpi/openhpi-1.9.3/_build/src; /bin/sh ../libtool
--mode=relink gcc -g -O2 -pthread -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -Wall -Wmissing-prototypes
-Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wformat=2
-Wformat-security -Wformat-nonliteral -Wno-format-y2k -Wcast-qual
-Wcast-align -Werror -D_GNU_SOURCE -D_REENTRANT -fexceptions -g -O2 -pthread
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Wall
-Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
-Wpointer-arith -Wformat=2 -Wformat-security -Wformat-nonliteral
-Wno-format-y2k -Wcast-qual -Wcast-align -Werror -D_GNU_SOURCE -D_REENTRANT
-fexceptions -o libopenhpi.la -rpath
/home/sdague/openhpi/openhpi-1.9.3/_inst/lib -L../utils -version-info 10:3:9
-export-symbols ../../src/hpi.sym config.lo domain.lo event.lo alarm.lo
hotswap.lo lock.lo plugin.lo plugin_static.lo init.lo safhpi.lo session.lo
oHpi.lo ../utils/libopenhpiutils.la -lltdl -pthread -lgthread-2.0 -lglib-2.0
-lm -lpthread -inst-prefix-dir /home/sdague/tmp/am-dc-28498/)
echo { global: .libs/libopenhpi.ver
cat ../../src/hpi.sym | sed -e s/\(.*\)/\1;/ .libs/libopenhpi.ver
echo local: *; }; .libs/libopenhpi.ver
gcc -shared .libs/config.o .libs/domain.o .libs/event.o .libs/alarm.o
.libs/hotswap.o .libs/lock.o .libs/plugin.o .libs/plugin_static.o
.libs/init.o .libs/safhpi.o .libs/session.o .libs/oHpi.o
-L/home/sdague/tmp/am-dc-28498//usr/lib -Wl,--rpath
-Wl,/home/sdague/openhpi/openhpi-1.9.3/_inst/lib -L/usr/lib
-L/home/sdague/openhpi/openhpi-1.9.3/_build/utils
-L/home/sdague/openhpi/openhpi-1.9.3/_inst/lib -lopenhpiutils -lltdl
-pthread -lgthread-2.0 -lglib-2.0 -lm -lpthread -Wl,-soname
-Wl,libopenhpi.so.1 -Wl,-version-script -Wl,.libs/libopenhpi.ver -o
.libs/libopenhpi.so.1.9.3
/usr/bin/ld: cannot find -lopenhpiutils
collect2: ld returned 1 exit status
libtool: install: error: relink libopenhpi.la' with the above command before
installing it
make[4]: *** [install-libLTLIBRARIES] Error 1
make[4]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build/src'
make[3]: *** [install-am] Error 2
make[3]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build/src'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build/src'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build'
make: *** [distcheck] Error 1
-Sean
On Tue, Nov 16, 2004 at 05:38:20PM -0600, Bob Friesenhahn wrote:
I don't see where you supplied information regarding what step of
distcheck failed.
Tool versions are unlikely to be the cause of the problem. Most
distcheck problems are due to 'make check' tests failing, use of bad
paths, or files which fail to be cleaned up by 'make clean' or 'make
uninstall'.
Bob
On Tue, 16 Nov 2004, Sean Dague wrote:
I just was able to get a debian system up to basically the same revision
levels of autotools as my desktop system an it gets through make
distcheck. Which means it isn't a libtool issue, but I'm still hoping
someone might still be able to help me figure out what part of the
toolchain
is to blame.
Here is the working system:
Debian Testing
gcc (GCC) 3.4.2 (Debian 3.4.2-2)
autoconf (GNU Autoconf) 2.59
automake (GNU automake) 1.7.9
ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) Debian: 220
$
GNU ld version 2.15
Non working system:
Mandrake 10.1
gcc-3.4.1 (GCC) 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)
autoconf (GNU Autoconf) 2.59
automake (GNU automake) 1.7.9
ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42)
GNU ld version 2.15.90.0.3 20040415
Could ld be to blame here?
Thanks for the help so far. Any ideas here would be greatly appreciated.
Please let me know if anything else in the toolchain might be suspect.
-Sean
--
__
Sean Dague Mid-Hudson Valley
sean at dague dot netLinux Users Group
http://dague.net http://mhvlug.org
There is no silver bullet. Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__
==
Bob Friesenhahn
[EMAIL PROTECTED]
Re: libtool 1.5.6 still not supporting make distcheck
On Tue, Nov 16, 2004 at 08:59:08PM -0500, Sean Dague wrote:
Bob,
The following log is still valid for where the breakdown occurs:
http://dague.net/libtool.txt.
That is a complete build log, plus all versions of the software.
The problem comes at:
/bin/sh ../../mkinstalldirs
/home/sdague/tmp/am-dc-28498//home/sdague/openhpi/openhpi-1.9.3/_inst/lib
/bin/sh ../libtool --mode=install /usr/bin/install -c libopenhpi.la
/home/sdague/tmp/am-dc-28498//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpi.la
libtool: install: warning: relinking libopenhpi.la'
(cd /home/sdague/openhpi/openhpi-1.9.3/_build/src; /bin/sh ../libtool
--mode=relink gcc -g -O2 -pthread -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -Wall -Wmissing-prototypes
-Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wformat=2
-Wformat-security -Wformat-nonliteral -Wno-format-y2k -Wcast-qual
-Wcast-align -Werror -D_GNU_SOURCE -D_REENTRANT -fexceptions -g -O2 -pthread
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Wall
-Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
-Wpointer-arith -Wformat=2 -Wformat-security -Wformat-nonliteral
-Wno-format-y2k -Wcast-qual -Wcast-align -Werror -D_GNU_SOURCE -D_REENTRANT
-fexceptions -o libopenhpi.la -rpath
/home/sdague/openhpi/openhpi-1.9.3/_inst/lib -L../utils -version-info 10:3:9
-export-symbols ../../src/hpi.sym config.lo domain.lo event.lo alarm.lo
hotswap.lo lock.lo plugin.lo plugin_static.lo init.lo safhpi.lo session.lo
oHpi.lo ../utils/libopenhpiutils.la -lltdl -pthread -lgthread-2.0 -lglib-2.0
-lm -lpthread -inst-prefix-dir /home/sdague/tmp/am-dc-28498/)
echo { global: .libs/libopenhpi.ver
cat ../../src/hpi.sym | sed -e s/\(.*\)/\1;/ .libs/libopenhpi.ver
echo local: *; }; .libs/libopenhpi.ver
gcc -shared .libs/config.o .libs/domain.o .libs/event.o .libs/alarm.o
.libs/hotswap.o .libs/lock.o .libs/plugin.o .libs/plugin_static.o
.libs/init.o .libs/safhpi.o .libs/session.o .libs/oHpi.o
-L/home/sdague/tmp/am-dc-28498//usr/lib -Wl,--rpath
-Wl,/home/sdague/openhpi/openhpi-1.9.3/_inst/lib -L/usr/lib
-L/home/sdague/openhpi/openhpi-1.9.3/_build/utils
-L/home/sdague/openhpi/openhpi-1.9.3/_inst/lib -lopenhpiutils -lltdl
-pthread -lgthread-2.0 -lglib-2.0 -lm -lpthread -Wl,-soname
-Wl,libopenhpi.so.1 -Wl,-version-script -Wl,.libs/libopenhpi.ver -o
.libs/libopenhpi.so.1.9.3
/usr/bin/ld: cannot find -lopenhpiutils
collect2: ld returned 1 exit status
libtool: install: error: relink libopenhpi.la' with the above command before
installing it
make[4]: *** [install-libLTLIBRARIES] Error 1
make[4]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build/src'
make[3]: *** [install-am] Error 2
make[3]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build/src'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build/src'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build'
make: *** [distcheck] Error 1
curious also what's in ../utils/libopenhpiutils.la
probably
installed=yes
and
libdir='/home/sdague/openhpi/openhpi-1.9.3/_inst/lib'
but
/home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.so
doesn't yet exist?
maybe this patch helps?
--- ltmain.in.orig Tue Aug 3 00:49:02 2004
+++ ltmain.in Sat Aug 7 17:00:56 2004
@@ -2611,7 +2611,7 @@ EOF
add_dir=
add=
# Finalize command for both is simple: just hardcode it.
- if test $hardcode_direct = yes; then
+ if test $hardcode_direct = yes test -f $libdir/$linklib; then
add=$libdir/$linklib
elif test $hardcode_minus_L = yes; then
add_dir=-L$libdir
that's for libtool-1.5.10, shouldn't have trouble applying it to 1.5.6.
not sure how correct that is though.
--
[EMAIL PROTECTED]
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.6 still not supporting make distcheck
* Sean Dague wrote on Thu, Nov 11, 2004 at 09:45:40PM CET: The issue I reported a couple weeks ago is still there. We have now tracked down based on a number of versions of libtool to figure out what works and what doesn't. libtool 1.4.x - all versions work that we've tried libtool 1.5.2 - works libtool 1.5.6 - doesn't work libtool 1.5.10 - doesn't work The end of the logs are included at the end of this email (on libtool 1.5.6): First: Your build is not VPATH clean, because you are doing a lot of symlinking by hand in several Makefile.am's. First, you should be using $(LN_S) together with AC_PROG_LN_S for symlinks, second you should link to $(srcdir)/relpath/$@ instead, third you should probably instead just be using AC_CONFIG_LINKS and be happy that you don't have to care about this yourself. All explained in Autoconf docs. Apart from these changes, `make distuninstallcheck' is the first part of `make distcheck' to complain, and it complains about some files which `make uninstall' misses to remove. This is with the HEAD branch as well as branch-1-5 of libtool. So, can you try either the patch from http://lists.gnu.org/archive/html/bug-libtool/2004-10/msg00170.html and possibly branch-2-0 from CVS? Please tell us your findings. What is most interesting is that the /home/sdague/tmp/am-dc-21838//home/sdague/openhpi/openhpi-1.9.3/ directory doesn't exist at all on my system. That seems to be created very late in the make distcheck processing, but why it isn't there I'm not sure. I /think/ this has nothing to do with your problem (though I cannot be sure, as I haven't understood what went wrong), and is fine because `make distcheck' is attempting a DESTDIR install. BTW, you did not mention your system at all, neither whether you are doing a VPATH build or not. All of this would have been helpful (still is if the problem remains unsolved), also whether or not an installed version of your package exists on your system or not. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
