I've been trying to get libvorbis built and installed for a while now, but libvorbis is not linking to libogg when they build their libraries.

I attached the build log for libvorbis, hopefully someone can help me. The problem is in the last few lines before all of the undefined reference errors near the bottom of the log.

// ...
C:/msys/1.0/bin/sh.exe ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I/mingw/include    -O20 -D__NO_MATH_INLINES -fsigned-char  -DUSE_MEMORY_H -MT vorbisfile.lo -MD -MP -MF .deps/vorbisfile.Tpo -c -o vorbisfile.lo vorbisfile.c
 gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I/mingw/include -O20 -D__NO_MATH_INLINES -fsigned-char -DUSE_MEMORY_H -MT vorbisfile.lo -MD -MP -MF .deps/vorbisfile.Tpo -c vorbisfile.c  -DDLL_EXPORT -DPIC -o .libs/vorbisfile.o
 gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I/mingw/include -O20 -D__NO_MATH_INLINES -fsigned-char -DUSE_MEMORY_H -MT vorbisfile.lo -MD -MP -MF .deps/vorbisfile.Tpo -c vorbisfile.c -o vorbisfile.o >/dev/null 2>&1
mv -f .deps/vorbisfile.Tpo .deps/vorbisfile.Plo
C:/msys/1.0/bin/sh.exe ../libtool --tag=CC   --mode=link gcc  -O20 -D__NO_MATH_INLINES -fsigned-char  -DUSE_MEMORY_H -no-undefined -version-info 5:0:2  -o libvorbisfile.la -rpath /mingw/lib vorbisfile.lo libvorbis.la 
gcc -shared  .libs/vorbisfile.o  ./.libs/libvorbis.dll.a -L/mingw/lib  -o .libs/libvorbisfile-3.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libvorbisfile.dll.a
.libs/vorbisfile.o:vorbisfile.c:(.text+0x73): undefined reference to `ogg_sync_pageseek'
.libs/vorbisfile.o:vorbisfile.c:(.text+0xc2): undefined reference to `ogg_sync_buffer'
.libs/vorbisfile.o:vorbisfile.c:(.text+0xf6): undefined reference to `ogg_sync_wrote'
// ...

I found this reply about building libogg and libvorbis and the errors are similar, but I don't think Victor's solution is entirely accurate for my uses (He's using devcpp, I'm using MinGW , he links against both the static and import libraries of libogg).

Can anyone help me figure out how to manually link libvorbis at this stage so I can continue on with the rest of the make process?

Try with:

./configure --disable-shared

It worked for me (libogg-1.1.3 and libvorbis-1.2.0 with gcc 3.4.5).

Yup, that worked for me too. If you're really lazy I have some precompiled packages at http://trent.gamblin.ca/logg, static only.

That means the dll won't be built though, doesn't it? I'd like to get it built if I can. I'm trying to build the same versions of the libraries with the same MinGW version that you used as well.

So you skipped the shared library too?

Sorry, I'm just in the mood to make this thing work. I'm not going to let these wacko configure jobbies get the best of me.

It looks like this line is creating a dll and the import library in the same command :

//
gcc -shared  .libs/vorbisfile.o  ./.libs/libvorbis.dll.a -L/mingw/lib  -o .libs/libvorbisfile-3.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libvorbisfile.dll.a
//

It says '-o .libs/libvorbisfile-3.dll', and the two arguments following the -Xlinker arguments specify to create an import library (--out-implib), and name it .libs/libvorbisfile.dll.a

So, which form of the ogg library should I link to in addition to the arguments there?

Victor's reply seemed to link against both the static and import libraries of ogg ( -logg -logg.dll ).

//
gcc -shared  .libs/vorbisfile.o  -logg -logg.dll  ./.libs/libvorbis.dll.a  -o .libs/libvorbisfile-3.dll -Wl,--image-base=0x10000000 -Wl,--out-implib,.libs/libvorbisfile.dll.a
//

Since this is building the dll and the import library of libvorbisfile, should I use the import library of ogg, or does it make more sense to statically link ogg into it? I don't know all that much about library creation yet.

Curious thing is that it actually does create the shared library if you build it after ./configure --disable-shared. I'm not good with makefiles so I don't know why, but if after building, you ./configure it again enabling the shared lib, it will simply say that there's nothing left to do next time you make it.

I don't know if the shared lib is created correctly though since I haven't used it.

I'll keep that in mind in case I can't make it work normally.

After './configure --prefix=/mingw' and 'mingw32-make' fails with the undefined references, I can build the shared libraries without any error by using :

//
$ rm .libs/libvorbisfile.dll.a

$ gcc -shared  .libs/vorbisfile.o  ./.libs/libvorbis.dll.a -L/mingw/lib -logg -o .libs/libvorbisfile-3.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libvorbisfile.dll.a
Creating library file: .libs/libvorbisfile.dll.a
//

But calling mingw32-make again after that tries to rebuild it over again and fails in the same way.

So, I passed -k to mingw32-make to make it keep going past any errors, and it builds the libvorbisenc shared and static libraries and dll, but I seem to be missing the static library for libvorbisfile. Isn't there supposed to be a decoding library as well?

I managed to track what I believe to be the offending line that creates the command line missing the linker argument for libogg :

//
# Commands used to build and install a shared archive.
archive_cmds="\$CC -shared \$libobjs \$deplibs \$compiler_flags -o \$output_objdir/\$soname \${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker \$lib"
//

It matches the faulty compiling command from the build log verbatim. So I think the problem is with the way the \$deplibs variable is being created in the libtool file there. Maybe I can track it down further tomorrow.

Can anyone give me a quick rundown of what happens build wise when a configure script is run? Does it generate the libtool file? Ie.. - where's the real source of the missing -logg parameter coming from?

Have you tried with the options in ./configure --help to manually set the directory where libogg is installed?. I guess I'd read that it gets messed (at least with MinGW) and manually setting it should solve the problem, but I didn't try it.

As for manually fixing the configure script and makefiles, I have no idea.

I have these files generated in the libvorbis-1.2.0\lib\.libs dir:
libvorbis.a libvorbis.dll.a libvorbisenc.a libvorbisfile.a

See "fix" below

With the aforementioned tweaking to the build process, I have these :

Static                 Dynamic                  Import
---------------------------------------------------------------------
libvorbis.a            libvorbis.dll.a          libvorbis-0.dll
libvorbisenc.a         libvorbisenc.dll.a       libvorbisenc-2.dll
                       libvorbisfile.dll.a      libvorbisfile-3.dll

So somehow, it's missing the static link library libvorbisfile.a.

Oh, didn't know about './configure --help'. It shows these options related to linking with ogg.

I tried this :

./configure --prefix=/mingw --with-ogg-libraries=/c/mingw/lib --with-ogg-includes=/c/mingw/include

but it failed at the same place and had an extra warning -
'libogg.la may have been moved'.

#######     It's a hack, but it seems to work     #######

So I saw that you can set an environment variable named LIBS to the linking options for extra libraries to link with, so I unpacked a fresh copy of the library and used :

export LIBS=-logg
./configure --prefix=/mingw
.....
mingw32-make
.....

and it built the static and import libraries and the dlls for libvorbis, libvorbisfile, and libvorbisenc without any errors. After that I went back to compiling the logg addon for allegro 4.3.x, and it worked fine (it links against the static libraries of ogg and vorbis). I also tested a modified play_ogg.c that linked against ogg, vorbis, and vorbisfile dynamically and that worked as well.

It's certainly not a fix by any means but rather a hack - the build process passes -logg twice in one place and LIBS shouldn't need to be set to -logg.

I extracted a clean copy of libvorbis and tried your fix. It worked perfectly. It created all files including libvorbisfile.a... then I remembered that I only have the static libogg libraries installed, so it might have something to do.

There's something weird indeed in trying to build libvorbis, but your fix solve it pretty nicely.

I gave up on trying to find out where the configure script and/or autotools was messing up. Something to learn for another day, and perhaps better left to the libvorbis developers who know what's happening behind the scenes.

Anyway, thanks for your help guys. Cookies!

Edit
I also submitted a bug report over at xiph.org :
https://trac.xiph.org/ticket/1499