Re: -soname passed directly to the compiler
Hi, sorry for the slow response. Ralf Wildenhues writes: > * tom fogal wrote on Sun, Feb 13, 2011 at 10:23:30PM CET: > > A package we're converting to the autotools is having an issue > > building a library; it seems to think gcc supports a -soname > > option. > > > > /bin/sh ../libtool --tag=CC --mode=link mpicc -I/home/tfogal/sw/includ > e > > -L/home/tfogal/sw/lib -o libH5Part.la -rpath > > /home/tfogal/dev/install-h5part/lib H5Part.lo H5PartAttrib.lo H5Block.lo > > H5BlockReadWrite.lo H5MultiBlock.lo H5MultiBlockReadWrite.lo -lhdf5 > > mpicc -shared .libs/H5Part.o .libs/H5PartAttrib.o .libs/H5Block.o > > .libs/H5BlockReadWrite.o .libs/H5MultiBlock.o .libs/H5MultiBlockReadWrite > .o > > -L/home/tfogal/sw/lib /home/tfogal/shigeru/lib/libhdf5.a -lc -soname > > libH5Part.so.0 -o .libs/libH5Part.so.0.0.0 > > gcc: libH5Part.so.0: No such file or directory > > gcc: unrecognized option '-soname' > > > ltmain.sh (GNU libtool) 1.5.26 Debian 1.5.26-4+lenny1 (1.1220.2.493 2008/02 > /01 > > 16:58:18) > > Hmm, even libtool 1.5.26 should be detecting mpicc as gcc but > apparently it isn't. You could look in config.log to find out why. > I'd really really suggest using a newer Libtool though [. . .] Just wanted to follow up for the archives. I upgraded libtool but hit lots of strange issues. Ended up upgrading both autoconf and automake too, which of course were also a few years old. I was still hitting issues, now with libtool trying to execute "X--gcc" or something like that; it seemed to be a common problem, from google searches, yet nobody had a concrete answer. I'm afraid I don't either: my solution was to stash my current changes and `git clean -df'. I don't version control configure, aclocal.m4, config.* etc., and so this got me a virgin tree. At that point 'libtoolize --copy --force && autoreconf -vi' got me a working build system. There must have been some sort of state which was not getting overwritten from the above w/o cleaning out the whole tree, but I do not know what it was, exactly. HTH someone finding this thread, -tom ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -soname passed directly to the compiler
* tom fogal wrote on Tue, Feb 15, 2011 at 06:34:44PM CET: > Hi, sorry for the slow response. No worries. > Ralf Wildenhues writes: > > Hmm, even libtool 1.5.26 should be detecting mpicc as gcc but > > apparently it isn't. You could look in config.log to find out why. > > I'd really really suggest using a newer Libtool though [. . .] > > Just wanted to follow up for the archives. I upgraded libtool but hit > lots of strange issues. Ended up upgrading both autoconf and automake > too, which of course were also a few years old. > > I was still hitting issues, now with libtool trying to execute "X--gcc" > or something like that; it seemed to be a common problem, from google > searches, yet nobody had a concrete answer. I'm afraid I don't either: > my solution was to stash my current changes and `git clean -df'. I > don't version control configure, aclocal.m4, config.* etc., and so this > got me a virgin tree. > > At that point 'libtoolize --copy --force && autoreconf -vi' got me a > working build system. There must have been some sort of state which > was not getting overwritten from the above w/o cleaning out the whole > tree, but I do not know what it was, exactly. I want to add this to the to-be-written FAQ. I have half an idea of where that bug comes from but would like to make sure. Please specify exactly which Autoconf, Automake, and Libtool versions you used before upgrading, and then, in which order you upgraded which tool to what newer version. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -soname passed directly to the compiler
Ralf Wildenhues writes: > * tom fogal wrote on Tue, Feb 15, 2011 at 06:34:44PM CET: > > I was still hitting issues, now with libtool trying to execute > > "X--gcc" or something like that; it seemed to be a common problem, > > from google searches, yet nobody had a concrete answer. I'm afraid > > I don't either: my solution was to stash my current changes and > > `git clean -df'. I don't version control configure, aclocal.m4, > > config.* etc., and so this got me a virgin tree. > > > > At that point 'libtoolize --copy --force && autoreconf -vi' got me > > a working build system. There must have been some sort of state > > which was not getting overwritten from the above w/o cleaning out > > the whole tree, but I do not know what it was, exactly. > > I want to add this to the to-be-written FAQ. I have half an idea > of where that bug comes from but would like to make sure. Please > specify exactly which Autoconf, Automake, and Libtool versions you > used before upgrading, and then, in which order you upgraded which > tool to what newer version. Original versions: ltmain.sh (GNU libtool) 1.5.26 Debian 1.5.26-4+lenny1 (1.1220.2.493 2008/02/01 16:58:18) autoconf (GNU Autoconf) 2.61 automake (GNU automake) 1.10.1 (these come from a Debian's previous stable install (5.0). I'll note that 6.0 was just released... which makes me about infinity happy, 5.0 was way too old :) Versions I upgraded to: libtool (GNU libtool) 2.4 autoconf (GNU Autoconf) 2.68 automake (GNU automake) 1.11.1 My shell's history is long gone, now, but if I had to guess I would say I: # upgraded libtool $ libtoolize --copy --force && autoreconf -vi $ $EDITOR configure.ac # fix complaints; missing LT_INIT, for example $ libtoolize --copy --force && autoreconf -vi $ make ... repeat the last two a bunch :) # upgrade autoconf $ libtoolize --copy --force && autoreconf -vi $ make # upgrade automake $ libtoolize --copy --force && autoreconf -vi $ make There was definitely some 'aclocal's in there as well; one of the tools kept telling me that something might be out of date and I should re-run aclocal. Not sure if they fell between the libtoolize's and the autoreconf's or between the autoreconf's and the make. -tom ___ http://lists.gnu.org/mailman/listinfo/libtool
