similar to: a few small bug

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

--- Matt Zimmerman <mdz@debian.org> wrote: > On Tue, Sep 10, 2002 at 11:11:24PM -0700, Josh Coalson wrote: > > > I have just finished uploading the source release for FLAC 1.0.4 > beta > > to Sourceforge; there are no binary releases. See the included > > doc/html/news.html for the changes since 1.0.3; there are quite a > few. > > > > >

After I ran my program through Rubyscript2exe, the Random.exe file that it created is causing the following error: D:\Ruby projects>random.exe C:\DOCUME~1\JEDELS~1\eee\eee.Random.exe.2\app\Random.rb:59: undefined method ''ru n'' for Wxruby2::App (NoMethodError) from C:\DOCUME~1\JEDELS~1\eee\eee.Random.exe.2\bootstrap.rb:77:in `load'' from

That patch 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. See: cc -bundle -flat_namespace -undefined suppress -o .libs/libxmms-flac.so plugin.lo -L/sw/lib /sw/lib/libFLAC.dylib -L/sw/src/flac-1.0.2-1/flac-1.0.2/src/libFLAC/.libs

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

I am working on getting the CentOS 3/Red Hat Enterprise 3 buildbot going, but I have hit a problem with the latest SVN build. Running './configure' works without any errors, (but I do note that it takes a long time on the drivers directory Makefile). Here is a copy of the configuration summary: Configuration summary: enable SSL development code: yes enable IPv6 support: yes build CGI

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

I'm forwarding this bug resolution because it has a pretty wide impact on LLVM developers. This bug (451) has been resolved (well, works for me anyway). If you have reconfigured your build tree since October 4th, you need to reconfigure again. The bug produced shared objects that don't have a .so extension. Reconfiguring will fix this problem. The notes below show what was needed to

I am struggling to compile Dovecot from CVS. I don't seem to be able to get a good configure script, always ending up with an error during configure. # sh autogen.sh configure.in:13: warning: AC_ARG_PROGRAM invoked multiple times # ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes [...] checking

Hi! The Netfilter project proudly presents: libnetfilter_log 1.0.1 libnetfilter_log is a userspace library providing interface to packets that have been logged by the kernel packet filter. See ChangeLog that comes attached to this email for more details. You can download it from: http://www.netfilter.org/projects/libnetfilter_log/downloads.html

> 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

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

On Wed, Jul 25, 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 @@

Here is the config.log : <p>----------------------------------------------------------- This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.57. Invocation command line was $ ./configure --prefix=/home/Darkmeteor --with-ogg-prefix=/home/Darkmeteor

good news, I finally got the asm compilation working with both autotools and project builder. it's all checked in. Brady, can you try it out too? autogen.sh may need a little tweaking depending on your environment. here's what mine looks like (I have some of the required libs in local places in the user acct that I build flac in, and the rest I get from Fink installed in /sw). aclocal

I've used R for a couple of years on FreeBSD with few problems. Recently, a couple of the contributed packages seem to have difficulty finding symbols in the shared libraries. Currently, I'm running R 1.3.1 on FreeBSD 4.4. I've tried setting LD_LIBRARY_PATH to /usr/local/lib and some other things. The packages I've had trouble with are: Matrix 0.3.15 RODBC 0.8.3 RSPython 0.3

Il 21/08/2011 19:31, Jordy Rose ha scritto: > What I can think of: > 1. Anonymous struct, to avoid a copy. > 2. Use stdarg.h...dangerous but accomplishes what you're looking for. probably it wasn't clear from my first post: I'm talking about LLVM-IR, not C or C++. > 3. Split up F: giant switch statements often indicate that your function is doing several different things.

Hello Jerry, don't know why you need to upgrade gst-inspect plugin. But I did update gstreamer plugin last year. If you like to take a view http://centos.cms4all.org/repo/7/gstreamer/ cms4all.repo [cms4all-gstreamer] name=cms4all-gstreamer #baseurl=http://centos.cms4all.org/repo/7/gstreamer/ baseurl=file:///srv/repo/centos/7/gstreamer gpgcheck=0 enabled=1 This are private package, does it

While diagnosing a problem I was having with IMAP and SSL (which I ended up fixing by simply upgrading from 0.99.9.1 to 0.99.10, and possibly affected by upgrading openssl libs from 0.9.7a to 0.9.7.b), I attempted to try the CVS version of Dovecot. When using the CVS version, apparently I have to first generate 'configure' using autogen.sh (?). This was the result of that, on FreeBSD

Hi, orry but when I said that I have the same problems when trying to compile libshout, i was wrong. My libshout compiles successfully but I have these problems when trying to compile ices2. after running autogen.sh I get the following response: ------------------------------- I am going to run ./configure with no arguments - if you wish to pass any to it, please specify them on the