search for: libtooling

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

Hi, Just a quick mail to mention that I cannot generate a new configure script using autoconf or autoreconf. I had edited the configure.ac and thought ... "oh, that's my fault", but then I tried it on R-patched and R-3.4.1 without touching configure.ac and had the same problems. The "building R packages" documentation seems to suggest that "autoconf" should take

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

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

Hello All: I just checked out the whole icecast but cannot build anything because autogen wouldn't cooperate. I have automake-1.7.6 just installed from ftp.gnu.org. Below is an example output in trying to build "icecast"; it's not very short... Thanks in advance for any help. --- $~/icecast/icecast> ./autogen.sh Checking for automake version found automake found

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

subversion now) source and versioned autoFoo Message-ID: <200407191939.i6JJd6g01573@Mail.NOSPAM.DynDNS.dK> [I don't think I sent this; if so, ignore. This was written over a month ago. Feedback probably won't work as I'm offline, but I'll patiently browse the archives when they're available again. Sorry.] Howdy. When building the CVS source using autogen.sh, in

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