Matt Ownby wrote:
Your ogg error may be because daphne may be using the wrong version of the ogg library at runtime. That is, it may be using a different version of the ogg library when running than what it used when it was built. I include ogg libraries in the daphne binaries that I release that are generally not compatible with other ogg libraries, so make sure that if you're building from source that you delete the ogg libraries inside the "lib" directory, assuming you are using my binaries as a starting point.
At any rate, I think you've got some conflicting ogg libs on your system somewhere.
The 32bit x86 Linux binary has only the following libs included:
libGLEW.so.1.3* libcrypto.so.0.9.7 libexpat.so.1 libssl.so.0.9.7 libstdc++.so.6
So i cannot test it with the libogg you used. If it was included
i could adjust the lib path or preload them to override the installed
32bit libs of my system.
I cannot find any prebuilt libs or source parts in the source tarball
which could conflict either. The test source builds i did with more
verbose ov_xxx func output was pure x86_64 (64bit) anyway and
that's using another set of ogg libs. 32bit libraries cannot be used
and only native 64bit libs get linked or loaded when
bulding or running a x86_64 64bit binary.
So all in all the 32bit ogg compat lib is incompatible with the released
binaries. Building it in x86 (32bit) mode on my system with those ogg
libs also is incompaible. So it looks like a pure runtime problem no
matter if the same libogg has been used at build/link time or not.
Building in x86_64 (64bit) mode with native 64bit ogg libs is also
incompatible.
Too bad both archs have exactly the same version here so i guess
its the version libogg-1.1.3 which has runtime issues:
/usr/lib32/libogg.so.0.5.3, /usr/lib64/libogg.so.0.5.3