Libtool(?) frustrations
Hello, We're using the various auto tools for Apache Rivet (http://tcl.apache.org/rivet/), but things seem to have taken a turn for the worse... I'm able to compile and run everything just fine on Ubuntu, but there seem to be difficulties on other platforms. The code in question is here (it's a beta that we're trying to shake the problems out of): http://people.apache.org/~davidw/rivet-0.7.0.tar.gz With the SVN repository being available here: http://svn.apache.org/repos/asf/tcl/rivet/trunk In particular, this one seems to be something directly related to libtool: http://mail-archives.apache.org/mod_mbox/tcl-rivet-dev/200511.mbox/browser test -z "/usr/lib /usr/share/rivet0.7.0" || mkdir -p -- "/usr/lib /usr/share/rivet0.7.0" /bin/sh ../libtool --mode=install /usr/bin/install -c 'librivet.la' '/usr/lib /usr/share/rivet0.7.0/librivet.la' /usr/bin/install -c .libs/librivet.so /usr/lib /usr/share/rivet0.7.0/librivet.so /usr/bin/install: installing multiple files, but last argument, `/usr/share/rivet0.7.0/librivet.so' is not a directory Try `/usr/bin/install --help' for more information. /bin/sh ../libtool --mode=install /usr/bin/install -c 'librivetparser.la' '/usr/lib /usr/share/rivet0.7.0/librivetparser.la' /usr/bin/install -c .libs/librivetparser.so /usr/lib /usr/share/rivet0.7.0/librivetparser.so /usr/bin/install: installing multiple files, but last argument, `/usr/share/rivet0.7.0/librivetparser.so' is not a directory Try `/usr/bin/install --help' for more information. make[2]: *** [install-lib_libexecLTLIBRARIES] Error 1 make[2]: Leaving directory `/usr/local/src/rivet-0.7.0/src' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/usr/local/src/rivet-0.7.0/src' make: *** [install-recursive] Error 1 That comes from this Makefile.am line: lib_libexec_LTLIBRARIES = librivet.la librivetparser.la What might be the cause of this problem? Is there a better place to ask? Thanks for your help, -- David N. Welton - http://www.dedasys.com/davidw/ Linux, Open Source Consulting - http://www.dedasys.com/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool(?) frustrations
Hi David, * David N. Welton wrote on Mon, Nov 07, 2005 at 01:34:54PM CET: > > We're using the various auto tools for Apache Rivet > (http://tcl.apache.org/rivet/), but things seem to have taken a turn for > the worse... I'm able to compile and run everything just fine on Ubuntu, > but there seem to be difficulties on other platforms. > > The code in question is here (it's a beta that we're trying to shake the > problems out of): > > http://people.apache.org/~davidw/rivet-0.7.0.tar.gz That tarball contains libtool.m4 and ltmain.sh from Libtool-1.5.6. Numerous bugs have been fixed since, the current version is 1.5.20, and a 1.5.22 is due soon. While you're at it, Automake is at 1.9.6. Both upgrades do not contain known-to-me regressions wrt. the respective versions you are using now. > With the SVN repository being available here: > > http://svn.apache.org/repos/asf/tcl/rivet/trunk > > In particular, this one seems to be something directly related to libtool: > > http://mail-archives.apache.org/mod_mbox/tcl-rivet-dev/200511.mbox/browser This URL only gives me an overview of the mailing list, not a particular mail. Could you post a link from a "Message View"? Thanks. > test -z "/usr/lib /usr/share/rivet0.7.0" || mkdir -p -- "/usr/lib > /usr/share/rivet0.7.0" > /bin/sh ../libtool --mode=install /usr/bin/install -c 'librivet.la' > '/usr/lib /usr/share/rivet0.7.0/librivet.la' > /usr/bin/install -c .libs/librivet.so /usr/lib > /usr/share/rivet0.7.0/librivet.so > /usr/bin/install: installing multiple files, but last argument, > `/usr/share/rivet0.7.0/librivet.so' is not a directory > Try `/usr/bin/install --help' for more information. > /bin/sh ../libtool --mode=install /usr/bin/install -c > 'librivetparser.la' '/usr/lib /usr/share/rivet0.7.0/librivetparser.la' > /usr/bin/install -c .libs/librivetparser.so /usr/lib > /usr/share/rivet0.7.0/librivetparser.so > /usr/bin/install: installing multiple files, but last argument, > `/usr/share/rivet0.7.0/librivetparser.so' is not a directory *snip* > That comes from this Makefile.am line: > > lib_libexec_LTLIBRARIES = librivet.la librivetparser.la > > What might be the cause of this problem? Is there a better place to ask? Asking here is fine, although I believe the underlying issue is related to Automake. I have a guess about Automake recognizing several prefixes here, but am not sure. Could you try the patch below and report how it goes? I can't test because I have several prerequisites of your package missing. Cheers, Ralf --- src/Makefile.am 2005-11-03 15:58:40.0 +0100 +++ src/Makefile.am 2005-11-07 15:18:37.0 +0100 @@ -23,8 +23,8 @@ # ... and these two. We want to put the libs in the package path, # rather than the standard library location for the system. -lib_libexecdir = @TCL_PACKAGE_PATH@/[EMAIL PROTECTED]@ -lib_libexec_LTLIBRARIES = librivet.la librivetparser.la +liblibexecdir = @TCL_PACKAGE_PATH@/[EMAIL PROTECTED]@ +liblibexec_LTLIBRARIES = librivet.la librivetparser.la # # Apache Rivet Module, mod_rivet.so / mod_rivet.dll ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool(?) frustrations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David N. Welton wrote: | Hello, | | We're using the various auto tools for Apache Rivet | (http://tcl.apache.org/rivet/), but things seem to have taken a turn for | the worse... I'm able to compile and run everything just fine on Ubuntu, | but there seem to be difficulties on other platforms. | | The code in question is here (it's a beta that we're trying to shake the | problems out of): | | http://people.apache.org/~davidw/rivet-0.7.0.tar.gz | | With the SVN repository being available here: | | http://svn.apache.org/repos/asf/tcl/rivet/trunk | | In particular, this one seems to be something directly related to libtool: | | http://mail-archives.apache.org/mod_mbox/tcl-rivet-dev/200511.mbox/browser | | test -z "/usr/lib /usr/share/rivet0.7.0" || mkdir -p -- "/usr/lib The space here is the problem. Haven't looked to see how it got there yet though :) Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQ29mWLiDAg3OZTLPAQKZigP+IY7OtuyZjuYbxLem54hU4tO/WHKcFs8P 558RQfnaZABSB+IZ9CPPU154IYNGJcioEjBMZvX336+SdWi+OVpzffqh5Wl+zjrW +rSsWj95SCJ+/7WDrzmRuwON5ifX6cdEhChe9SAzU4mV13Dq/ywv/eESUG68AUuN hjX7M3LrIXg= =gTPV -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool(?) frustrations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David N. Welton wrote: | That comes from this Makefile.am line: | | lib_libexec_LTLIBRARIES = librivet.la librivetparser.la | | What might be the cause of this problem? Is there a better place to ask? | | Thanks for your help, # ... and these two. We want to put the libs in the package path, # rather than the standard library location for the system. lib_libexecdir = @TCL_PACKAGE_PATH@/[EMAIL PROTECTED]@ lib_libexec_LTLIBRARIES = librivet.la librivetparser.la Does TCL_PACKAGE_PATH have a space in it? Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQ29m27iDAg3OZTLPAQIHMwP/eTbQC87z7bpitBTv9wNWkz/oh516c44/ yJob9/5d0EMT9CoG8DnsSeVR6SwTWXS5BPIH+73XmrywRs9OpGV9P3LMsZZT7dKQ 9eNHtvZaZTARvqbJdH+LeDkQ/2HC3/9BbHmdpvVRCHeYTa1OnTOQlTjxOAC961eh kRdu8pv6pGA= =f7ef -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool(?) frustrations
Sorry for the self-reply. * Ralf Wildenhues wrote on Mon, Nov 07, 2005 at 03:22:55PM CET: > * David N. Welton wrote on Mon, Nov 07, 2005 at 01:34:54PM CET: > > > > In particular, this one seems to be something directly related to libtool: > > > > http://mail-archives.apache.org/mod_mbox/tcl-rivet-dev/200511.mbox/browser > > This URL only gives me an overview of the mailing list, not a particular > mail. Could you post a link from a "Message View"? Thanks. That would be http://mail-archives.apache.org/mod_mbox/tcl-rivet-dev/200511.mbox/[EMAIL PROTECTED] > > test -z "/usr/lib /usr/share/rivet0.7.0" || mkdir -p -- "/usr/lib > > /usr/share/rivet0.7.0" > > /bin/sh ../libtool --mode=install /usr/bin/install -c 'librivet.la' > > '/usr/lib /usr/share/rivet0.7.0/librivet.la' > > Asking here is fine, although I believe the underlying issue is > related to Automake. Nope. Nevermind my previous wrong conclusions. You have @TCL_PACKAGE_PATH@, which expands to more than one directory name in this case: /usr/lib /usr/share/rivet0.7.0 That would be a bug in whatever sets this variable (iff the expansion is supposed to be just one directory) or a bug in your Makefile.am: | lib_libexecdir = @TCL_PACKAGE_PATH@/[EMAIL PROTECTED]@ | lib_libexec_LTLIBRARIES = librivet.la librivetparser.la lib_libexecdir is supposed to point to _one_ directory only, but contains more than one name, after expansion. So, no bug in autotools, but I can't tell you who is at fault. ;-) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool(?) frustrations
Peter O'Gorman wrote: > David N. Welton wrote: > > | That comes from this Makefile.am line: > | > | lib_libexec_LTLIBRARIES = librivet.la librivetparser.la > | > | What might be the cause of this problem? Is there a better place to ask? > | > | Thanks for your help, > > # ... and these two. We want to put the libs in the package path, > # rather than the standard library location for the system. > lib_libexecdir = @TCL_PACKAGE_PATH@/[EMAIL PROTECTED]@ > lib_libexec_LTLIBRARIES = librivet.la librivetparser.la > > > Does TCL_PACKAGE_PATH have a space in it? Hrm, that might be it... on my system it doesn't - let me see what the user says. Thanks! -- David N. Welton - http://www.dedasys.com/davidw/ Linux, Open Source Consulting - http://www.dedasys.com/ ___ http://lists.gnu.org/mailman/listinfo/libtool
