search for: ltmain

Citeren Arnaud Quette <aquette.dev at gmail.com>: > Author: aquette > Date: Sat Nov 15 22:47:26 2008 > New Revision: 1557 > > Log: > GNU libtool update > > Modified: > trunk/ChangeLog > trunk/configure.in > trunk/ltmain.sh I think 'ltmain.sh' is a generated file (at least, I hope it is), this change severely broke compilation here. I had to add '--force' to my autoreconf line to make this compile again. In the process, it re-created quite a couple of other files, so I don't think we shou...

...comes from libtool 2.2.6. libtool: You should recreate aclocal.m4 with macros from libtool 2.2 libtool: and run autoconf again. I have no idea what this error message is referring to. The version of libtool installed on the system is none of the ones mentioned in this error: % libtool --version ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365 2005/12/18 22:14:06) <FSF disclaimer> The libtool in the R directory has version 2.2: % /path/to/R/bin/libtool --version ltmain.sh (GNU libtool) 2.2 Written by Gordon Matzigkeit <gord at gnu.ai.mit.edu>, 1996 <FSF disclaime...

I just uploaded flac 1.0-1 to Debian unstable; it should appear in the archives tomorrow. In order to get things to work correctly with libtool 1.4, I had to apply the following patch: --- flac-1.0.orig/ltmain.sh +++ flac-1.0/ltmain.sh @@ -1862,6 +1862,7 @@ else # We cannot seem to hardcode it, guess we'll fake it. add_dir="-L$libdir" + test -d $ladir/.libs && add_dir="$add_dir -L$la...

...nload > > I just downloaded 1.0.4 beta, and it doesn't build for me. Since it > seems > that there might be more than one 1.0.4 beta floating around, this is > the > one with md5sum 2499d8d240c9bd5c923780b0427389cb. That is the latest. > It seems to be > missing > ltmain.sh, which causes libtool not to be built correctly. Correct. Ugh; I guess ltmain.sh now must appear in EXTRA_DIST. But something is else wierd. My libtool: $ libtool --version ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) Stock redhat7.3 libtool: $ libtool --version ltmain.s...

...ut I'm using libtool-1.3.5). I get: > > libtool: link: cannot build libtool library `libFLAC.la' from non-libtool > objects: ia32/libFLAC-asm.a > > Time to get libtool-1.4 I guess... I hope it's not so new that most people > don't have it. automake will include ltmain.sh in the source distribution, so it should be used even if it isn't installed on the build system. In fact, it seems to always use the distributed version, and not the installed one (which is sometimes annoying). -- - mdz

...; > I want to use a different libtool on my system, version 1.4. This > version requires "--tag=SOMETHING" and requires library objects to > be generated by libtool. flac CVS is not distributed with any libtool script at all. I was using libtool 1.4, and automake pulled in the ltmain.sh from there. There is no --tag option in libtool 1.4, at least not the one distributed by GNU. Where did your libtool 1.4 come from? > Maybe it would be a good idea to either (1) undo the patch I sent or > (2) generate flac's libtool script using libtool 1.4. > > Both versions...

--- Ben Hines <bhines@alumni.ucsd.edu> wrote: > At 10:39 AM -0700 5/21/02, Josh Coalson wrote: > >--- Ben Hines <bhines@alumni.ucsd.edu> wrote: > >> I guess the problem is really why is it trying to relink it? > >> > >> The "parse error: condition expected:" is suspicious, though.. > maybe > >> it's another "zsh as

...ch file or directory libtool-disable-static: install: error: relink `libxmms-flac.la' with the above command before installing it libtool-disable-static: install: warning: remember to run `libtool-disable-static --finish /sw/lib/xmms/Input' Not sure how to fix this one, but this HACK to ltmain.sh fixes this problem. It just totally disables relinking, and does not seem to have any ill effects. --- flac-1.0.2/ltmain.sh Mon Dec 3 23:10:14 2001 +++ flac-1.0.2-patched/ltmain.sh Wed Jun 26 01:06:54 2002 @@ -3948,10 +3952,10 @@ # Directory that this library needs to be installed in:...

...on (.) or string at /usr/bin/automake line 8449. : installing `./config.guess' Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8449. : installing `./config.sub' configure.in:3: required file `./config.h.in' not found aclocal.m4:916: required file `./ltmain.sh' not found src/auth/Makefile.am: installing `./depcomp' configure.in:13: warning: AC_ARG_PROGRAM invoked multiple times autoheader: `config.h.in' is created ----------------------------------------- would it be possible to not use your own libtool in the cvs? in this case I can run a...

...ion: 1560 > > Log: > Generated by libtool and should not be versioned. > > Modified: > trunk/ (props changed) Right, that didn't work out quite the way I intended. Can someone please set the svn:ignore property on 'config.guess', 'config.sub' and 'ltmain.sh'? Best regards, Arjen -- Please keep list traffic on the list

I'm trying to build upstream source on RHEL 7.5 and get this error: # autoreconf -i libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4...

...ts From rspencer at x10sys.com 2004-10-12 19:58 ------- The difficulty I had turned out to be the name of "mklib" instead of "libtool". The Makefiles use "mklib" but I was constantly regenerating libtool under various circumstances. The real problem was our version of ltmain.sh which didn't match our version of libtool.m4. Both these files have been committed as well as changes to the AutoRegen.sh script. Commits are here: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041011/019191.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-2004...

...on FreeBSD? Can you think of something that I am doing incorrectly upon installation or R or the packages that could cause these problems. In case it is relevant, FreeBSD uses an older version of libtool as compared to the one that comes with R. Here is the version information: FreeBSD libtool: ltmain.sh (GNU libtool) 1.3.4-freebsd-ports (1.385.2.196 1999/12/07 21:47:57) R libtool: ltmain.sh (GNU libtool) 1.3e (1.890 2001/04/06 23:48:27) Thanks for any help you can provide! Loren -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read...

...AM_SILENT_RULES], [m4_define([AM_SILENT_RULES],[])]) AM_SILENT_RULES([yes]) # make --enable-silent-rules the default. this nevertheless doesn't work. I had to comment out these two lines in both configure.ac and daemon/configure.ac. There is no libtoolize. I had to manually link build-aux/ltmain.sh -> /usr/share/libtool/ltmain.sh There is no autopoint. I think this is the reason I had to manually remove references to the po/ subdirectory. There is no mkisofs. I commented out the test for this in configure.ac, but eventually I'll have to find out if this is available for Mac OS X...

finished hooking up the altivec stuff so it works in ProjectBuilder. I ran a test, doing a 'flac -t' on 400MB of files compresses at level 5. the runtime dropped from from 180 sec to 105 sec! once I get the latest autotools on my ibook I'll try and get asm compilation to work that way. Josh --- Josh Coalson <xflac@yahoo.com> wrote: > OK, checked it all in (only minor

...=====================>] 435.80K 152KB/s in 2.9s 2019-12-04 10:49:59 (152 KB/s) - 'wiki2-export.tar.gz' saved [446263/446263] configure.ac:298: warning: macro 'AM_ICONV' not found in library libtoolize: putting auxiliary files in '.'. libtoolize: copying file './ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'. libtoolize: copying file 'm4/libtool.m4' libtoolize: copying file 'm4/ltoptions.m4' libtoolize: copying file 'm4/ltsugar.m4' libtoolize: copying file 'm4/ltversion.m4' libtoolize: copying file...

> flac CVS is not distributed with any libtool script at all. I was using > libtool 1.4, and automake pulled in the ltmain.sh from there. There is no > --tag option in libtool 1.4, at least not the one distributed by GNU. Where > did your libtool 1.4 come from? I was looking at the flac tarball, not CVS. Sorry for the misinformation. bash-2.05$ libtool --version ltmain.sh (GNU libtool) 1.4a (1.641.2.255 2001...

--- Matt Zimmerman <mdz@debian.org> wrote: > On Fri, Jul 20, 2001 at 03:01:54PM -0700, Josh Coalson wrote: > > > --- Matt Zimmerman <mdz@debian.org> wrote: > > > > > > automake will include ltmain.sh in the source distribution, so it > > > should be > > > used even if it isn't installed on the build system. In fact, it > > > seems to > > > always use the distributed version, and not the installed one > (which > > > is > > > someti...

...2001 at 06:21:14PM -0400, Matt Zimmerman wrote: > I just uploaded flac 1.0-1 to Debian unstable; it should appear in the archives > tomorrow. In order to get things to work correctly with libtool 1.4, I had to > apply the following patch: > > --- flac-1.0.orig/ltmain.sh > +++ flac-1.0/ltmain.sh > @@ -1862,6 +1862,7 @@ > else > # We cannot seem to hardcode it, guess we'll fake it. > add_dir="-L$libdir" > + test -d $ladir/.libs &&amp...

...h does get the .libs dir added to the compile line. But the > other problem is that libtool is attempting to link against the > installed version of libFLAC, that is $(DESTDIR)/lib/libFLAC.dylib > instead of -lFLAC. > > ... > > Not sure how to fix this one, but this HACK to ltmain.sh fixes this > problem. It just totally disables relinking, and does not seem to > have > any ill effects. OK, I see. Matt, are you having the same problem with the Debian package? If so, maybe I should conditionalize Ben's hack around the libxmms-flac build similar to how you did...