Can anyone provide static compile of aotuv beta 5.5 for linux?

Ok. maybe somebody can help to compile, and provide mini how-to. I am java developer but I believe I handle with C!

You download libvorbis source from Aoyumi's website.
You must untar the file: tar jxf libvorbis-aotuv_b5.5.tar.bz2

./configure
make
su make install

I was trying to make an rpm with checkinstall, but it did not work so I installed it as outlined above (on OpenSuse 10.3). It works OK.
You may wish to define where make install should put the files, so read ./configure --help.

Thank you. I will try. I asked my question, because I read this.

It looks like I always need use ld_preload to run oggenc.

No, I don't think so. You need to use ld_preload if you did not overwrite your existing libvorbis files. In this case you must tell oggenc which set of libvorbis files it should use - those in /usr (old) or those in /usr/local (new).
I simply deleted my existing libvorbis files: (rpm -e libvorbis --nodeps), and put the new files into the same place by using ./configure --prefix=/usr. The programs (and notably oggenc) find the libvorbis files, the downside is that at installing rpm files that require libvorbis they miss libvorbis, so I must use the --nodeps switch. I do not know how other, not rpm-based distros behave.

Right, you don't need ld_preload. Actually, you don't need to overwrite things either.

I used to have CVS (and later SVN) versions of libvorbis and oggenc in my home directory without any problems.

I used ./autogen.sh --prefix=/home/kjoonlee or something like that to create the configuration files. If that part is ready, I think you can just do ./configure --prefix=/home/alter4

If I ran ldd /usr/bin/oggenc it would have printed out /usr/lib/libvorbis*
If I ran ldd ~/bin/oggenc it would have printed out /home/kjoonlee/lib/libvorbis*

You can run ldd too, and if your compiles of oggenc show that they're linked to aoTuV, then all will be well. Good luck!

If you use slackware or a compatible distribution you can get the Zenwalk package for aotuvb5.5 (aotuv is used by default in Zenwalk): http://packages.zenwalk.org/?p=libvorbis-a...ersion=snapshot

Converting it with alien to another package format might work but I don't know for sure.

If you install vorbis tools right after you install the aotuv libvorbis you will have an encoder you don't have to do anything with to use.

Here's the b5.5 static binary, that I've just compiled for myself, just in case anyone's still needing it:
http://artfwo.googlepages.com/oggenc-aotuvb5a.bz2

Can you tell us the steps necessary to build that binary? I am thinking build here in Ubuntu 8.04 AMD64.

EDIT:
With some research, I got this:

libogg




libvorbis






vorbis-tools



The result was an oggenc binary in $HOME/build/out/bin. I tested and seens to be fine, the files encoded have correct codec signature of "AO; aoTuV b5a [20080330] (based on Xiph.Org's libVorbis)". The binary size is arround 2.2 MB (my Ubuntu is AMD64 version). Is this stuff right?

with rarewares/debian i:
* build libvorbis-aotuv and install in /usr/lib/libvorbis-aotuv/*
* build vorbis-tools (only oggenc) using this lib source and adding "-aotuv" suffix to the binary with configure.

works great.


later

Wow, that's a lot simpler than my scheme... I usually


Then configure vorbis-tools and edit the makefiles replacing libvorbis.so with /path/to/aotuv/libvorbis.a

I also used to check that the binary does not depend on any shared libraries with ldd:


Didn't actually think of using --with-vorbis, that really helps, thanks!


I also have an Ubuntu hardy package in my PPA:
https://launchpad.net/~artfwo/+archive

Ubuntu has a bug for aoTuV as well:
https://launchpad.net/bugs/57797

i just updated libvorbis-aotuv & oggenc-aotuv again for rarewares/debian so i thought i'd post the process.

it's a little more in-depth for the debian packages (i.e. patching, etc.), but you could replicate this for your own install by the following:

note: you could also change the prefix to /usr/local and use $(prefix)


for libvorbis-aotuv:

CFLAGS="-O2 -fno-strict-aliasing" ./configure \
--prefix=/usr \
--libdir=/usr/lib/libvorbis-aotuv \
--datadir=/usr/share/libvorbis-aotuv \
--includedir=/usr/include/vorbis-aotuv \
--enable-shared

(make install...)

for oggenc-aotuv (i.e. vorbis-tools):

CFLAGS="-O2" ./configure \
--prefix=/usr \
--with-vorbis-libraries=/usr/lib/libvorbis-aotuv \
--with-vorbis-includes=/usr/include/vorbis-aotuv \
--program-suffix=-aotuv \
--enable-shared \
--disable-ogg123 \
--disable-oggdec \
--disable-ogginfo \
--disable-vcut \
--disable-vorbiscomments

(make install...)

this will add libraries and a program (/usr/bin/oggenc-aotuv) selectable by any program that offers that functionality like k3b or other rippers.


later

Thank you artfwo and xmixahlx for the responses.

Whoa! You all are making this too complicate. Here is some advice from a linux audio freak.

- Compiling your own audio libs on Linux is actually very easy and surprisingly simple. But you have to know a few basics to avoid some pitfalls. First, compiling software on Linux is essentially divided in two camps: The first I call the "Traditional Linux/Slackware" camp, and the other is the Debian/Ubuntu camp. Part of what make debian and it's related distributions different is that debian has a different opinion about how the file system in Linux should be layed out. When this originally came about back in around '96, it was a deliberate deliverance from "mainstream" Linux. The upshot of this is that if you compile a package on Debian/Ubuntu that is not specifically debianized, you run the risk of have the files being put in all the wrong places/config not finding installed libraries it needs etc... Thus you will have to do some plumbing with the build system.

Most software released in source form for linux tends to compile successfully with none or very little modification. This is especially true for the slackware families (Zenwalk, Arch etc...) for two reasons. First slack and it's relatives are unpretentious in that they tend to go "with the flow" of the community of upstream developers. Second is the slackbuild system. A slackbuild is a script that does all the work of turning a source code package into an installable software package optimized for your specific system. It's a system that works remarkably well.

For example, in our situation lets check out the Zenwalk slackbuild script for aotuv beta 5.5. You can find it at http://thenktor.dyndns.org/packages/libvorbis/

To compile aotuv beta 5.5 and install it on your system you only need the file build-libvorbis.sh from the above URL. Download the file and put it in a directory someware. Then do:

chmod +x build-libvorbis.sh

to make the script exacutable. Then type:

./build-libvorbis.sh

The zenbuild script will then download the source code for aotuv beta 5.5, unzip it into a tempory directory and then cofigure and compile the code. After compiling the code, it will then create an installable packable of the finished code. In this case it creates the file libvorbis-aotuv.b5.5-i486-52.2.tgz which is a "Zenpackage" file, which is just Zenwalk's version of an rpm or deb file. To install it just do a:

installpkg libvorbis-aotuv.b5.5-i486-52.2.tgz

That's it. This zenbuild script will probably work on most non-debian linux distributions. There are slackbuild scripts for just about every piece of linux software ever released. Just type slackbuild into google...

The other advantage is you tend to avoid the mistakes/unnecessary configuration that has been posted on this forum. For example, the following is a far better/correct way to compile libvorbis than has been mentioned. I've included extensive optimizations for my own personal system (an old pentium 4 hyperthreader). I did this because I have no clue where some of the posters came up with their CFLAGS lines. Please not that CFLAGS is not required at all in this case. However, properly used it will build a slightly faster binary.
----------------------------------------------
for libvorbis-aotuv:

export CFLAGS="-O3 -march=prescott"
export CXXFLAGS="-O3 -march=prescott"

chmod +x autogen.sh configure
./autogen.sh
./configure --prefix=/usr
make
make install
----------------------------------------------
You get the idea.....

you should figure out why people do the things you don't understand before trying to fix it.

...all you have to do is read ./configure --help to figure out the build system.

a possible outcome of your "optimizations" will be a completely unusable library, so good luck!


later

I mentioned that the optimizations were optional and included as an example in response to the various other cxxflags that were previously posted. I did this because I was concerned that the previous posts would do exactly that, result in a completely useless library. GCC 4 has changed the way optimizations are specified, for the better. For example mtune and mcpu are depreciated. You just need to specify the overall architecture(with -march) like I did in my example. The compiler now chooses most of the tuning optimizations automatically -- and does a very good job at it. This is all in the gcc documentation... It is very rare for a system to break with the new optimizations. A good way to get your correct optimization strings is to use the following script:

http://www.pixelbeat.org/scripts/gcccpuopt

thanks for your concern...

Big THX for all who helped me!!!