similar to: vorbis-tools build problems

The latest CVS update of libvorbis fails to compile on SuSE Linux 6.4. The error is below. Also, what happened to the xmms plugin directory in cvs? It complains that it is missing when I do a 'cvs update'. gcc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0beta3\" -DHAVE_ALLOCA_H=1 -DHAVE_ ALLOCA=1 -I. -I. -I../include -O20 -ffast-math -mno-ieee-fp -D_REENTRANT -fs

Ok, I managed to compile the Ogg and Vorbis libs. Then, after modifying the file audio_out.c as follows: original: #include <dlfcn.h> modified: #include <win32/include/dlfcn.h> I was able to (finally!) compile libao. Then I tried to compile the module vorbis-tools, but uninvited problems came to my party. [...] > /usr/bin/ld: multiple definitions of symbol _getopt >

Updating the fink flac to 1.0.4, it won't compile because finds the headers of the previous version in /sw/include, because the CPPFLAGS/CFLAGS are being put before the local includes: (configure with ./configure --prefix=/sw --mandir=/sw/share/man ) gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"

I get an error when compiling libshout. it's the version from cvs, i checked it out a few minutes ago... make[2]: Entering directory `/opt/ices2/libshout/src/net' /bin/sh ../../libtool --mode=compile gcc -DPACKAGE=\"libshout\" -DVERSION=\"2.0\" -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -DHAVE_STDINT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_C99_INTTYPES=1 -DHAVE_NANOSLEEP=1

Hi, I just read the thread about making 3dnow optimisations default and thought I would test it as I have an AMD here. Unfortunately I can not even compile with default (no 3dnow) options. ./configure goes fine including this part: checking whether to build static libraries... yes checking whether -lc should be explicitly linked in... no creating libtool checking for g++... no checking for

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

While trying to compile libao 0.8.0 under OS X 10.1, I got the following problems: > [localhost:ecc/Sources/libao-0.8.0] root# ./configure > creating cache ./config.cache > checking for a BSD compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking whether make sets ${MAKE}... yes > checking for working aclocal... found >

Just checked out the vorbis CVS branch a couple minutes ago and got an internal compiler error with gcc 2.95.4 on envelope.c gcc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0rc2\" -DHAVE_DLFCN_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_SQRTF=1 -DHAVE_LOGF=1 -DHAVE_EXPF=1 -DHAVE_ACOSF=1 -DHAVE_ATANF=1 -DHAVE_FREXPF=1 -DHAVE_RINTF=1 -I. -I. -I../include -O20 -ffast-math

> OK, that worked. > > I checked in your patch to make a static libFLAC-asm.a and > I moved @XMMS_LIBS@ to the end of ...LIBADD. Matt and Ben, > can you try the latest CVS to see if it works for you now? It doesn't work for me. Looks like libtool decided not to link libFLAC-asm.a into libFLAC. Here's the output: Making all in src gmake[1]: Entering directory

hello! Today I tried to compile the new FLAC 0.8 sourcecode on my SuSE Linux 7.1 machine and failed. Below is the output of "make" and "configure". I hope the information is enough that somebody can help me to compile the source. Thanks a lot. PS: A lot of thanks to all developers of FLAC. Its very useful to me!! ------------------------------------------------------ This

Jake wrote: >$ ./autogen.sh >aclocal: configure.in: 142: macro `AM_PROG_LIBTOOL' not found in library >aclocal: configure.in: 255: macro `AM_ICONV' not found in library >aclocal: configure.in: 256: macro `AM_LANGINFO_CODESET' not found in >library I can compile now that I've installed libtool-1.5.6 and gettext-0.14.1. :-) I did need to tweak autogen.sh to use

current Vorbis cvs gives: gcc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0\" -DHAVE_DLFCN_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -I. -I. -I../include -O20 --fast-math -mno-ieee-fp -D_REENTRANT -fsigned-char -O2 -march=i686 -mcpu=i686 -DUSE_MEMORY_H -Wp,-MD,.deps/envelope.cpp -c envelope.c -fPIC -DPIC -o .libs/envelope.lo gcc: Internal compiler error: program cc1 got fatal

It's not really documented, but when you compile with --enable-sse, you need to add -march=pentium3 to the compile switches. That's actually a gcc requirement. Jean-Marc Le mer 21/01/2004 à 04:22, war a écrit : > gcc-3.2.2 + slack 9 + p4 2.6ghz (has sse/2) > > ./configure --prefix=/app/speex-1.1.4 --enable-shared --enable-sse > --with-ogg-dir=/app/libogg-1.1 >

My ogg library is located in /home/warren/local. So when I configure and compile the vorbis module on my linux box using configure --with-ogg-prefix=/home/warren/local make I get the following error during the make: gcc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0.0\" -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -I. -I. -I../include -O20 -ffast-math -mno-ieee-fp -D_REENTRANT

Wow, I've never seen an FSF gcc crap out like this on a non-overheating system. When lib/envelope.c is compiled with -march=i686, gcc gets a signal 11, but not with -march=i586. I'm not sure whether to blame gcc or libvorbis. There are apparently three other files in libvorbis where this same behavior is seen. jeffrey@diddl:/usr/src/build/libvorbis-1.0/lib$ gcc

This one may be my fault.... I've put a temporary fix for libvorbis not linking, I altered libvorbis_la_LIBADD = to libvorbis_la_LIBADD = $(OGG_LIBS) in the makefile, hence the temporary and continued with the build. I'm now getting gcc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0.0\" -DHAVE_ALLOCA_H=1 - DHAVE_ALLOCA=1 -I. -I. -I../include

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, I can't compile ices2 from cvs.xiph.org OS Linux gcc 2.95 I get this error: make[2]: Entre dans le répertoire `/usr/local/src/ices/src' gcc -DPACKAGE=\"ices\" -DVERSION=\"2.0\" -DSTDC_HEADERS=1 -DHAVE_STDINT_H=1 - -I. -I. -Inet -Ithread -Iavl -Ilog -Itiming -DHAVE_OSS -O20 -ffast-math - -fsigned-char

Karl Heyes wrote: >> In file included from sock.c:49: >> sock.h:32: os.h: No such file or directory >> make[2]: *** [sock.lo] Error 1 >> make[2]: Leaving directory `/opt/ices2/libshout/src/net' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory `/opt/ices2/libshout/src' >> make: *** [all-recursive] Error 1 > > > yes

> > >seems odd.. > >with sh use >make 2>&1 1> output > >or with csh > >make >& output > >karl > I ran make again. Here is the output: Making all in src make[1]: Entering directory `/usr/ices/src' Making all in avl make[2]: Entering directory `/usr/ices/src/avl' make[2]: Nothing to be done for `all'. make[2]: Leaving directory

Wondering if anyone else is having this problem compiling the latest version in CVS. autogen.sh runs fine, configure runs fine, make fails with the following: gcc -DPACKAGE=\"icecast\" -DVERSION=\"2.0\" -DHAVE_DLFCN_H=1 -DHAVE_IPV6=1 -DSTDC_HEADERS=1 -DHAVE_STDINT_H=1 -DCHUID=1 -DCHROOT=1 -I. -I. -I./net -I./thread -I./avl -I./httpp -I./log -I./timing -g -O20