search for: libtoolize

On Thu, Jul 19, 2001 at 02:56:11PM -0700, collver@linuxfreemail.com wrote: > On Thu, Jul 19, 2001 at 05:01:07PM -0400, Matt Zimmerman wrote: > > Once I removed that, it also seems to hate the .nasm extension: > > > > /bin/sh ../../../libtool --mode=compile \ > > sh ../../../strip_fPIC.sh nasm -f elf -d OBJ_FORMAT_elf cpu_asm.nasm > > libtool: compile:

Hello Dovecot users, There haven't been that many Pigeonhole developments lately, not even really significant bugs were reported. That is why this release is pretty small in terms of changes. However, one issue got some attention: the fact that not recompiling Pigeonhole for Dovecot v2.0.3 would result in rather interesting message delivery. Normally, Dovecot would complain about a

Hello Dovecot users, There haven't been that many Pigeonhole developments lately, not even really significant bugs were reported. That is why this release is pretty small in terms of changes. However, one issue got some attention: the fact that not recompiling Pigeonhole for Dovecot v2.0.3 would result in rather interesting message delivery. Normally, Dovecot would complain about a

On Thu, Jul 19, 2001 at 04:58:44PM -0400, Matt Zimmerman wrote: > On Thu, Jul 19, 2001 at 10:38:14AM -0700, Josh Coalson wrote: > > > So, last chance to checkout from CVS and break it! > > Also, my libtool doesn't seem to recognize --tag=CC. What is its purpose? > > /bin/sh ../../../libtool --tag=CC --mode=compile \ > sh ../../../strip_fPIC.sh nasm -f

I'm trying to build an executable for a program I wrote. The compilation steps go well, but the linking step fails with a libtool "version mismatch" error. My linking command has this prefix: /path/to/R/bin/R CMD LINK gcc -g -std=gnu99 ... etc. The error looks like this: libtool: Version mismatch error. This is libtool 2.2, but the libtool: definition of this LT_INIT comes from

for am in automake-$AM_NEEDED automake$AM_NEEDED \ automake automake-1.7 automake-1.8 automake-1.9 automake-1.10; do This code makes it check for automake-1.7 (AM_NEEDED evaluates to 1.7), then automake (unversioned wrapper), then 1.7 (again), 1.8, 1.9 and then 1.10 1) Why the check is generally ascending? Isn't it better use the most recent version that is known to work instead of

Hi, all Although PoCC is optional, I want to give it a try. But I have a problem while building PoCC. Here is the error, ---------------------------------------------------------- make[1]: Entering directory `/tmp/chenwj/pocc-1.0-rc3.1/optimizers/letsee-0.2.0-pre/letsee' make[2]: Entering directory `/tmp/chenwj/pocc-1.0-rc3.1/optimizers/letsee-0.2.0-pre/letsee' /bin/sh ../libtool

We're planning to contribute an LLVM version of Apple's libtool utility. To quote its man page, "Libtool with -static is intended to replace ar(5) and ranlib". In other words, libtool is the preferred tool to create archives for Apple platforms, and it also has good defaults for that platform (e.g. automatically creating a table of contents with the right format). It provides a

...nu loading site script './config.site' loading build-specific script './config.site' ./configure: line 2982: syntax error near unexpected token `blas' ./configure: line 2982: ` withval=$with_blas; R_ARG_USE(blas)' OK.. there's a recipe that oen can use, starting with: libtoolize --force but you get: A sequence typical found out there, starting withlibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `tools'. libtoolize: linking file `tools/ltmain.sh' libtoolize: You should add the contents of the following files to `aclocal.m4': libtoolize: `/usr/share...

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 f...

I've encountered a new problem building gluster-2.0.1 that I did not have with gluster-2.0.0rc8. This is on a mandriva-2008.1-x86_64 system. ../../libtool: line 466: CDPATH: command not found ../../libtool: line 1144: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.2.6 Debian-2.2.6a-4, but the libtool: definition of this LT_INIT comes from an older

...togen.sh Checking for automake version found automake found aclocal Generating configuration files for ices, please wait.... aclocal -I m4 aclocal: configure.in: 13: macro `AM_PROG_LIBTOOL' not found in library autoheader autoheader: error: AC_CONFIG_HEADERS not found in configure.in libtoolize --automake automake --add-missing configure.in: no proper invocation of AM_INIT_AUTOMAKE was found. configure.in: You should verify that configure.in invokes AM_INIT_AUTOMAKE, configure.in: that aclocal.m4 is present in the top-level directory, configure.in: and that aclocal.m4 was recently regen...

Hi, looking on the build scripts, I noticed on configure.ac ## <FIXME> ## Completely disable using libtool for building shlibs until libtool ## fully supports Fortran and C++. ## AC_ARG_WITH([libtool], ## [AS_HELP_STRING([--with-libtool],[use libtool for building shared libraries @ <:@yes@:>@])], ## [use_libtool="${withval}"], ## [use_libtool=yes]) ##

I'm not sure if this is related to me updating to gcc 4.6.0 or not, but in the gnulib/lib directory I get an error which comes down to the following libtool command running: $ ../../libtool --tag=CC --mode=compile gcc -std=gnu99 -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -g -O2 -MT c-ctype.lo -MD -MP -MF .deps/c-ctype.Tpo -c -o c-ctype.lo c-ctype.c ../../libtool: line 2075: c-ctype.c: command not

Hi. I want to add some code to flac and am having trouble building it out of cvs. I've had several problems, most of which were pretty easy to work around or had already been discussed here. But this one has me stumped (though I am admittedly new to autoconf, automake, and libtool). Here's the problem. autoconf does not see any definition for AC_PROG_LIBTOOL. There is such a

On Sat, Jul 21, 2001 at 04:06:14PM -0400, Matt Zimmerman wrote: > Argh. Maybe libtool will have to get involved after all. I'll work on it > this afternoon. I think I give up. automake and libtool assume that the compiler will be able to assemble stuff, and compilers don't generally understand NASM input. I don't like the strip_fPIC bit, since just about anything that could

...quot; + echo "use in the environment used to invoke $0," + echo "for example:" + echo " $ env AUTOMAKE=/path/to/automake ACLOCAL=/path/to/aclocal $0" + echo " or $ env AUTOMAKE=automake18 $0" exit 1 } fi echo -n "checking for libtool... " -for LIBTOOLIZE in libtoolize glibtoolize nope; do - ($LIBTOOLIZE --version) < /dev/null > /dev/null 2>&1 && break +LIBTOOLIZE=${LIBTOOLIZE:-libtoolize} +for libtoolize in ${LIBTOOLIZE} libtoolize glibtoolize nope; do + ($libtoolize --version) < /dev/null > /dev/null 2>&1 &&...

Thanks Ralph; Maybe it's me. I wiped out my whole /var/libvorbis directory, dropped in a new one from the libvorbis-1.0.1.tar.gz file including all the subdirectories, and edited /var/libvorbis/examples/Makefile.fm as instructed. I then ran ./configure without difficulty, then ran make again, which started afresh but still ended up with the same error: gcc -DDARWIN -fno-common

Hello, with rc6 on FreeBSD 6.1-STABLE, I encounter the following when running make after the usual configure [ Note : that worked with rc5 ] /usr/local/bin/zsh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -L/usr/local/lib -o dovecot-auth -export-dynamic

On Thu, Jul 19, 2001 at 04:58:44PM -0400, Matt Zimmerman wrote: > On Thu, Jul 19, 2001 at 10:38:14AM -0700, Josh Coalson wrote: > > > So, last chance to checkout from CVS and break it! > > Also, my libtool doesn't seem to recognize --tag=CC. What is its purpose? > > /bin/sh ../../../libtool --tag=CC --mode=compile \ > sh ../../../strip_fPIC.sh nasm -f elf