Hydrogenaudio Forums > Compile WavPack from SVN

krmathis

Aug 23 2006, 14:09

I move my build problems to a new thread, instead of go even more off-topic in the 'WavPack 4.4 alpha 2 for Windows' thread.

I pulled revision 8 from the WavPack SVN server (http://svn.slomosnail.de/wavpack). But I get all sorts of problems compiling this on Mac OS 10.4.7, using Xcode 2.3 (GCC 4.0.1 build 5363).

Here it goes....
Version 4.32 compiled with a plain "./configure && make", and the README file in SVN have the same instructions:

CODE

To build everything, type:
1. ./configure
2. make
3. make install

But there are no configure file in the source, so it fails.
Making autogen.sh executable and run it end with errors as well. Like this:

QUOTE

$ ./configure
-bash: ./configure: No such file or directory
$ chmod +x autogen.sh
$ ./autogen.sh
./autogen.sh: line 5: libtoolize: command not found
configure.ac: installing `./mkinstalldirs'
Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8449.
: installing `./config.guess'
Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8449.
: installing `./config.sub'
aclocal.m4:825: required file `./ltmain.sh' not found

This process creates the needed configure file, but running "./configure && make" errors out like this:

QUOTE

$ make
Making all in src
source='bits.c' object='libwavpack_la-bits.lo' libtool=yes \
depfile='.deps/libwavpack_la-bits.Plo' tmpdepfile='.deps/libwavpack_la-bits.TPlo' \
depmode=gcc3 /bin/sh ../depcomp \
/bin/sh ../libtool --mode=compile gcc -DPACKAGE_NAME=\"wavpack\" -DPACKAGE_TARNAME=\"wavpack\" -DPACKAGE_VERSION=\"4.33\" -DPACKAGE_STRING=\"wavpack\ 4.33\" -DPACKAGE_BUGREPORT=\"bryant@wavpack.com\" -DVERSION_OS=\"Darwin\" -DHIGHFIRST=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1 -I. -I. -g -O2 -c -o libwavpack_la-bits.lo `test -f 'bits.c' || echo './'`bits.c
../libtool: ../libtool: No such file or directory
make[1]: *** [libwavpack_la-bits.lo] Error 127
make: *** [all-recursive] Error 1

I have both libtool and autoconf installed:

CODE

$ libtool -V
Apple Computer, Inc. version cctools-622.3
----
$ autoconf -V
shell-init: could not get current directory: getcwd: cannot access parent directories: No such file or directory
autoconf (GNU Autoconf) 2.59
Written by David J. MacKenzie and Akim Demaille.

Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling WavPack 4.32 (from wavpack-4.32.tar.bz2) works without any problems with a simple "./configure && make" though.
So if the requirements have not changed, there is nothing wrong on my side!

bryant, I know you are new at this non-Windows part. But I think you should take a look at how the 4.32 build system do this. Cause it works like a treat!

bryant

Aug 23 2006, 22:00

Your autoconf is the same version as mine, but I think your libtool may be too old. The fact that libtoolize isn't found is a bad sign...

QUOTE

david@ubuntu:~/temp$ libtoolize --version
libtoolize (GNU libtool) 1.5.22

Copyright © 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Anyway, I built a distribution that should have almost the same requirements as the 4.32 version and uploaded it here:

http://www.wavpack.com/wavpack-4.33.tar.bz2

This builds as 4.33, but is really 4.4a3 (and that's what it reports when run). Until we get all the version stuff sorted out I wouldn't install it; just run it where you build it.

Hope this works better for you!

krmathis

Aug 24 2006, 08:56

I am a bit closer!

For some reason, 'libtoolize' are called 'glibtoolize' on Mac OS X.

QUOTE

$ glibtoolize --version
libtoolize (GNU libtool) 1.5

Copyright © 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Changing "libtoolize --copy" to "glibtoolize --copy" in autogen.sh seems to work. Meaning that ./autogen.sh and ./configure run without problems.
For some reason version 4.32 and the 4.33 (4.4a3) you posted detect this libtoolize/glibtoolize issue and don't spit out error messages.
I guess you could add a check for "Darwin" in autogen.sh and run the appropriate command:

CODE

if [ `uname` = "Darwin" ]; then
glibtoolize --copy
else
libtoolize --copy
fi

The 'make' process errors out at the end though. But I don't know if it is related to my previous issue?

QUOTE

gcc -g -O2 -o .libs/wavpack wavpack-wavpack.o wavpack-utils.o wavpack-md5.o ../src/.libs/.libs/libwavpack.1.0.0.dylib -lm /usr/lib/libiconv.dylib
powerpc-apple-darwin8-gcc-4.0.1: ../src/.libs/.libs/libwavpack.1.0.0.dylib: No such file or directory
make[1]: *** [wavpack] Error 1
make: *** [all-recursive] Error 1

I am happy for all the help I get!

Edit: The libwavpack.1.0.0.dylib exist in "src/.libs/", not "src/.libs/.libs/".
I have to little build knowledge to fix this myself...

bryant

Aug 24 2006, 23:59

QUOTE(krmathis @ Aug 24 2006, 07:56)

The 'make' process errors out at the end though. But I don't know if it is related to my previous issue?

QUOTE

gcc -g -O2 -o .libs/wavpack wavpack-wavpack.o wavpack-utils.o wavpack-md5.o ../src/.libs/.libs/libwavpack.1.0.0.dylib -lm /usr/lib/libiconv.dylib
powerpc-apple-darwin8-gcc-4.0.1: ../src/.libs/.libs/libwavpack.1.0.0.dylib: No such file or directory
make[1]: *** [wavpack] Error 1
make: *** [all-recursive] Error 1

I am happy for all the help I get!

Edit: The libwavpack.1.0.0.dylib exist in "src/.libs/", not "src/.libs/.libs/".
I have to little build knowledge to fix this myself...

Okay, this does look better. When I first got this new build configuration I got exactly the same error as you are getting now (with /.libs/.libs/). We could not figure out what it was, but it went away when I upgraded my Ubuntu to the new version. Our best guess was that it was fixed by changing the automake version from 1.9.5 to 1.9.6, but the weird thing is that it works in my cygwin which has automake version 1.9.2. I have no idea, but maybe updating your automake will fix it.

I'll shoot off an e-mail to the developer of the build setup and see if he has any idea.

Sorry for the difficulties...

Slo Mo Snail

Aug 25 2006, 02:22

QUOTE(krmathis @ Aug 24 2006, 16:56)

I am a bit closer!

For some reason, 'libtoolize' are called 'glibtoolize' on Mac OS X.

QUOTE

$ glibtoolize --version
libtoolize (GNU libtool) 1.5

Copyright © 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Changing "libtoolize --copy" to "glibtoolize --copy" in autogen.sh seems to work. Meaning that ./autogen.sh and ./configure run without problems.
For some reason version 4.32 and the 4.33 (4.4a3) you posted detect this libtoolize/glibtoolize issue and don't spit out error messages.
I guess you could add a check for "Darwin" in autogen.sh and run the appropriate command:

CODE

if [ `uname` = "Darwin" ]; then
glibtoolize --copy
else
libtoolize --copy
fi

The 'make' process errors out at the end though. But I don't know if it is related to my previous issue?

QUOTE

gcc -g -O2 -o .libs/wavpack wavpack-wavpack.o wavpack-utils.o wavpack-md5.o ../src/.libs/.libs/libwavpack.1.0.0.dylib -lm /usr/lib/libiconv.dylib
powerpc-apple-darwin8-gcc-4.0.1: ../src/.libs/.libs/libwavpack.1.0.0.dylib: No such file or directory
make[1]: *** [wavpack] Error 1
make: *** [all-recursive] Error 1

I am happy for all the help I get!

Edit: The libwavpack.1.0.0.dylib exist in "src/.libs/", not "src/.libs/.libs/".
I have to little build knowledge to fix this myself...

Hi,
could you please retry with the latest version from SVN? Please start from a completely clean source tree again to prevent failures by leftover files.

Bye

Edit: also could you try the tarball at http://slomosnail.de/~slomo/temp/wavpack-4.33.tar.gz ?

krmathis

Aug 25 2006, 09:21

QUOTE(bryant @ Aug 25 2006, 07:59)

I'll shoot off an e-mail to the developer of the build setup and see if he has any idea.

Sorry for the difficulties...

No need to be sorry!
If my problems can help finding problems with the build setup, and resolve these, then I am happy.

Lets see what the build setup developer say...

QUOTE(Slo Mo Snail @ Aug 25 2006, 10:22)

Hi,
could you please retry with the latest version from SVN? Please start from a completely clean source tree again to prevent failures by leftover files.

Bye

The previous error was with revision 8.
Pulled a fresh revision 9 now, and see that the autogen.sh file is rewritten. It still don't detect my glibtoolize, and I no longer understand how to manually make it work. So it fails like this:

CODE

$ ./autogen.sh
Generating configuration files for wavpack, please wait...

You must have libtool installed to compile wavpack.
Download the appropriate package for your distribution,
or get the source tarball at ftp://ftp.gnu.org/pub/gnu/

QUOTE

Edit: also could you try the tarball at http://slomosnail.de/~slomo/temp/wavpack-4.33.tar.gz ?

Like version 4.32, and the 4.33 which bryant linked to, this one builds successfully with a simple "./configure && make"

I'm still lost!

bryant

Aug 25 2006, 10:27

QUOTE(krmathis @ Aug 25 2006, 08:21)

QUOTE

Edit: also could you try the tarball at http://slomosnail.de/~slomo/temp/wavpack-4.33.tar.gz ?

Like version 4.32, and the 4.33 which bryant linked to, this one builds successfully with a simple "./configure && make"

Oops, I was confused. I thought that the bzip2 I posted gave you the .../.libs/.libs/... error, but you actually got that error when building the CVS code drop with your modified script. As long as you can build from the distribution you can use and test the new version.

Obviously it would be nice if the autogen.sh stuff worked (and I assume we'll get that going) but the final distribution will probably be like 4.32 and so there shouldn't be a problem, unless you want to build and test a new version every day!

krmathis

Aug 25 2006, 11:34

Correct!
The .../.libs/.libs/... error come from trying to build SVN revision 8 and 9. While both the 4.33 archives build just fine.

I thought you where moving to a new build setup (./autogen && ./configure && make), and hence it would be great to make it build-able on Mac OS X as well. I now understand that this is only a temporary situation.

he-jo

Nov 14 2006, 05:31

I also have these problems on Mac OS X. But regarding libtoolize, I would suggest this pach ('which' doesn't give proper return codes):

CODE

--- autogen.sh
+++ autogen.sh
@@ -16,14 +16,11 @@
for LIBTOOLIZE in libtoolize glibtoolize nope; do
-  (which $LIBTOOLIZE) > /dev/null 2>&1 && break
+  $LIBTOOLIZE --version &> /dev/null && break
done
if test x$LIBTOOLIZE = xnope; then
-  LIBTOOLIZE=libtoolize
-fi
-($LIBTOOLIZE --version) < /dev/null > /dev/null 2>&1 || {
        echo
        echo "You must have libtool installed to compile $PACKAGE."
        echo "Download the appropriate package for your distribution,"
        echo "or get the source tarball at ftp://ftp.gnu.org/pub/gnu/"
        DIE=1
-}
+fi

@@ -40,3 +37,3 @@
touch NEWS README AUTHORS ChangeLog
-aclocal --force
+aclocal
$LIBTOOLIZE --copy --force

bryant

Nov 15 2006, 22:14

I'd like to try this patch, but I can't get it to work. On both Cygwin and Ubuntu I get:

CODE

david@ubuntu:~/beta/trunk$ patch -i patch.dif
patching file autogen.sh
patch: **** malformed patch at line 4: for LIBTOOLIZE in libtoolize glibtoolize nope; do

I've never had trouble before applying a patch, but I don't do it very often. This seems so simple; what am I missing?

Thanks in advance,
David

xmixahlx

Nov 16 2006, 01:45

make sure you format the patch when you copy/paste it (check the indentations) if you are using unix patch

later

he-jo

Nov 16 2006, 06:00

Yes, whitespaces get messed up in the forum. I uploaded the patch 'autogen-osx.diff.gz' to http://base91.sourceforge.net/download/wavpack/

bryant

Nov 16 2006, 11:33

Thanks, guys! I knew it was something simple...

bhoar

Nov 16 2006, 14:33

QUOTE(he-jo @ Nov 16 2006, 08:00)

Yes, whitespaces get messed up in the forum. I uploaded the patch 'autogen-osx.diff.gz' to http://base91.sourceforge.net/download/wavpack/

In other forums I've found that, if copy/pasting from the message in question gives incorrect whitespace, the answer is to start a reply-with-quoting to the message in question and copy/paste from there. Then discard the reply before posting, if applicable.

-brendan

he-jo

Nov 20 2006, 07:49

QUOTE(bryant @ Nov 16 2006, 18:33)

Thanks, guys! I knew it was something simple...

Thanks for taking it into SVN!

xmixahlx

Nov 20 2006, 12:25

heh, i didn't even know there WAS a svn for wavpack

i packaged r41 for rarewares/debian... so us linux folk can test it too

later

bryant

Nov 20 2006, 23:08

QUOTE(bhoar @ Nov 16 2006, 12:33)

In other forums I've found that, if copy/pasting from the message in question gives incorrect whitespace, the answer is to start a reply-with-quoting to the message in question and copy/paste from there. Then discard the reply before posting, if applicable.

Ah, I should have thought of that because I've used the same technique to figure out how people make certain effects in their posts.

QUOTE(he-jo @ Nov 20 2006, 05:49)

QUOTE(bryant @ Nov 16 2006, 18:33)

Thanks, guys! I knew it was something simple...

Thanks for taking it into SVN!

Haha. Thank you for the patch!

I suppose this means you won't mind me putting in your clever improvements to the update_weight macros!?

QUOTE(xmixahlx @ Nov 20 2006, 10:25)

heh, i didn't even know there WAS a svn for wavpack

i packaged r41 for rarewares/debian... so us linux folk can test it too

Yeah, mention of the SVN was buried in some thread, and I'm terrible at updating my website with any useful information. I still don't have my testsuite on there! But now that I've gotten used to SVN I can't believe I waited so long. I always thought it was a little silly unless there were many developers, but now I think it would be handy even for single developer projects.

Oh, and thanks for the package!

he-jo

Nov 21 2006, 02:52

QUOTE(bryant)

Haha. Thank you for the patch!

Oh, no problem! I'm really happy, if I can provide something useful.

QUOTE(bryant)

I suppose this means you won't mind me putting in your clever improvements to the update_weight macros!?

No, please feel free!

Just for the case you already downloaded an older version, please get the 'wp-4.40beta-jh_mmx.diff.gz' I uploaded yesterday.

And for the case that you're wondering... You already applied my modified update_weight macro from April to SVN, but you changed

CODE

weight = (weight - s) + (s ^ delta);

to

CODE

weight += (s ^ delta) - s;

which, of course, looks nicer. But I didn't use this compact form by intention, because gcc isn't clever enough to figure out, that the xor and subtraction could be executed independently. That's why my patch changes that back. According to my tests, this gives a speedup of ~1% on x86 and PPC. I think it's worth to have not so nice C code in this case.

bryant

Nov 21 2006, 07:20

QUOTE(he-jo @ Nov 21 2006, 00:52)

QUOTE(bryant)

I suppose this means you won't mind me putting in your clever improvements to the update_weight macros!?

No, please feel free!

Just for the case you already downloaded an older version, please get the 'wp-4.40beta-jh_mmx.diff.gz' I uploaded yesterday.

Thanks for letting me know; I'll grab the latest.

QUOTE(he-jo @ Nov 21 2006, 00:52)

And for the case that you're wondering... You already applied my modified update_weight macro from April to SVN, but you changed

CODE

weight = (weight - s) + (s ^ delta);

to

CODE

weight += (s ^ delta) - s;

which, of course, looks nicer. But I didn't use this compact form by intention, because gcc isn't clever enough to figure out, that the xor and subtraction could be executed independently. That's why my patch changes that back. According to my tests, this gives a speedup of ~1% on x86 and PPC. I think it's worth to have not so nice C code in this case.

I don't actually remember changing the line to be simpler, although I certainly would have if I'd noticed that. I do remember looking for (and not finding) a way to eliminate the intermediate variable.

Anyway, I'll change it back and incorporate the other changes because I think they're very safe. And thanks again!

Mangix

Nov 30 2006, 18:42

apologize for reviving a 9 day old topic, but i didn't feel like creating a new one.

anyways, i just updated WavPack's revision from 41 to 42 and i'm wondering if there is any way to check any info about the new revision. for instance: on sourceforge, when you go to multiple revisions of different programs, you can find that the author has added a comment saying "bug1 and bug2 fixes" or something similar.

bryant

Nov 30 2006, 21:08

QUOTE(Mangix @ Nov 30 2006, 16:42)

apologize for reviving a 9 day old topic, but i didn't feel like creating a new one.

anyways, i just updated WavPack's revision from 41 to 42 and i'm wondering if there is any way to check any info about the new revision. for instance: on sourceforge, when you go to multiple revisions of different programs, you can find that the author has added a comment saying "bug1 and bug2 fixes" or something similar.

I don't know if there's a way from the web interface to check the log.

If you're using the SVN command line (or a shell like Tortoise) then you can use the "log" command.

It turns out that the only change from 41 to 42 was the tagging of the "beta" version. The changes for the final release should start soon and finish [hopefully] with the release on Sunday.

Mangix

Nov 30 2006, 22:14

SourceForge's web interface lets you see the log.

i'm using the svn binaries which were provided by tigris.org for windows. using "svn log "WavPack"" seemed to work like a charm. thank you

glad to hear that development is still progressing