similar to: configure option --with-ogg broken?

Hi, I'm trying to build a universal binary from libtheora-1.1alpha1. My configure line is as follows: env CFLAGS="-g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc" LDFLAGS="-arch i386 -arch ppc" ./configure --disable-dependency-tracking But when I make, I get: /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include

Hi, I can not anymore compile this version of theora. I get the following: /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../i nclude -I../lib -I../lib/dec -I../lib/enc -I/usr/local/include -Wall -Wno-p arentheses -O3 -fforce-addr -fomit-frame-pointer -finline-functions -funroll-loo ps -MT mode.lo -MD -MP -MF .deps/mode.Tpo -c -o mode.lo `test -f

Hi again, I measured my fragment reconstructions against the compiler output from GCC and well - the new codes perform better, so I brushed up my gcc inline assembler skills and made a port. Code is here: http://torus.untergrund.net/code/mmxfrag.c All routines perform much better now. Inter2 alone got a speedup of factor 5 on Pentium-M. Athlon CPU's execute roughly 3 times faster.

Hi all, I'm a Theora noob and just taking a look at the theora-mmx package in hopes of making Thoggen run faster for DVD ripping. I've checked out the latest svn of the theora-mmx branch and trying to compile it on Ubuntu Dapper AMD64. I run autogen.sh, then make, and soon get the following errors: make[2]: Entering directory `/home/dlenski/theora-mmx/lib' if /bin/sh ../libtool

Hi folks. Mozilla had some issues with the MMX optimized frag_recon functions over the last days, and I was able to track the problem down. The code itself is fine, but it unfortunately it has the tendency to cause a non-deterministic compiler bug. The whole discussion is here: https://bugzilla.mozilla.org/show_bug.cgi?id=474937 After thinking about the problem I've suggested to

Hi together, I have compiled so far a lot libs and already some programs on my Solaris 5.7 box (old, I know). When I try to compile libtheora the examples are not compiling: make[2]: Entering directory `/export/home/quix0r/more/libtheora-1.0/examples' if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/usr/local/include -I/usr/local/include/libpng12 -Wall -Wno-parentheses -O3

Hi folks, FYI: I've finally made some benchmarks for inline-assembler versus intrinsic based mmx code. I've just applied the changes to the fragment reconstruction functions as writing the IDCT and loopfilter have not been ported yet. Nevertheless here are some numbers: As a baseline I'll take the current version from the trunk with all inline assembler functions enabled. Lower

On Thu, 21 Jul 2005, Long Fei wrote: > Does anyone know the "standard" commandline to compile and run spec95 > benchmarks ? > > I found some scripts in llvm test suite (External/SPEC/CINT95), but I am not > sure if they are the *default ref* configurations. <Some of them seem to use > smaller problem sizes.> SPEC95 was retired many years ago, so few people

On Thu, 21 Jul 2005, Long Fei wrote: > which suggests the compiling command: > gcc -DSPEC_CPU95 -O2 -o spec_go g2.c g22.c g23.c g25.c g26.c g27a.c g27b.c > g28.c g29.c g2eye.c g2jlib2.c g2jos.c g2list.c g2reas.c g2s2.c g2s3.c g2shp.c > and the running commandline: > ./spec_go 50 9 2stone9.in > < are these correct ? > I believe that we only include test/train inputs for

> 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

Here is the patch with my changes. Most work went into the decoder. I just changed on the encoder if something was nessesary to build the library. You can find the patch here (quite big).. http://torus.untergrund.net/code/theora_mmx_vc2005.diff Please let me know if the encoder works without problems. I just did a very brief testing of it. The decoder has been tested against the test

The current llvm/llvm-gcc4.2 svn is now fixed with respect to the extra warnings that were being emitted by the gfortran compiler. The gfortran testsuite results under Intel Darwin9 are appended below. Jack Native configuration is i686-apple-darwin9 === gfortran tests === Running target unix/-m32 FAIL: gfortran.dg/aint_anint_1.f90 -O (internal compiler error) FAIL:

Building llvm 2.3 and llvm-gcc4.2-2.3 on Mac OS X 10.5, I am seeing the following failures remaining in the gcc 4.2.1 gfortran testsuite... LAST_UPDATED: Native configuration is i686-apple-darwin9 === gfortran tests === Running target unix FAIL: gfortran.dg/actual_array_constructor_1.f90 -O1 execution test FAIL: gfortran.dg/actual_array_constructor_1.f90 -O2 execution test FAIL:

Using the proposed patch for enabling the i386 multilib under the x86_64-apple-darwin build... http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025040.html the following gfortran testsuite results are obtained... Native configuration is x86_64-apple-darwin10 === gfortran tests === Running target unix/-m32 FAIL: gfortran.dg/aint_anint_1.f90 -O (internal compiler error) FAIL:

Some of the run commandlines don't seem to be the *default ref* configuration. For instance, in 099.go, what's in the script is: LEVEL = ../../../.. BM=099.go ifeq ($(RUN_TYPE),test) STDIN_FILENAME = /dev/null STDOUT_FILENAME = null.out RUN_OPTIONS = 40 19 else STDIN_FILENAME = 2stone9.in STDOUT_FILENAME = 2stone9.out RUN_OPTIONS = 50 9 endif include ../../Makefile.spec95

Building the prerelease of llvm-gcc 2.4 on Intel darwin9 with the following patch... --- llvm-gcc-4.2-2.3.999-20081024.source/gcc/stub-c.c.org 2008-10-30 18:55:45.000000000 -0400 +++ llvm-gcc-4.2-2.3.999-20081024.source/gcc/stub-c.c 2008-10-30 18:57:29.000000000 -0400 @@ -157,3 +157,27 @@ { gcc_assert(0); } + + +bool cvt_utf8_utf16 (const unsigned char *, size_t, unsigned char **, +

While browsing the code I came across line 83 bitpack.c: *_ret=((ret&0xFFFFFFFFUL)>>(m>>1))>>(m+1>>1); Is there any reason why this is so convoluted? Maybe endianess or 64 bit issues? If I'm not mistaken it does exactly the the same as: *_ret = ret >> m; Cheers, Nils

On Thursday 04 October 2007 04:27:47 you wrote: > Sir, you need to provide more information. What kind of errors? What > is not working? What exactly are you trying to do? What compiler are > you using? H IV0, we are using a lot of different cross-compiler (mainly based on GCC 3.4.x) When I tried to cross-compile FLAC for non-i386 platforms (such as ARM), I use use

A couple of questions: * Do I need a named account to commit changes? How do I get such an account? I'm used to commit roughly once every 8 hours of work if I have a stable point that compiles on linux and win32. That's just my way of working. Worked well in the past to protect myself from doing stupid things. * How anal are you about line endings, tabs vs. spaces, max. line length