views:

337

answers:

2

Background

I recently came across the fuppes UPnP media server and it seemed great. I installed it on my home server and started using it to stream video to my XBox. It worked really really well and I was happy with it. Then I upgraded my servers distribution and fuppes stopped working; I now know that it's because various libraries have depreciated, most specifically debian has started dropping the .la libtool files from the majority of their packages.

The Problem / Question

So my question is, how do I build fuppes now that I don't have those .la files for libtool? More specifically, this is my exact error message:

/bin/sed: can't read /usr/lib/libogg.la: No such file or directory
libtool: link: `/usr/lib/libogg.la' is not a valid libtool archive

I don't have a /usr/lib/libogg.la file anymore. This proves it from the terminal:

# dpkg -L libogg-dev | grep "a$"
/usr/lib/libogg.a
#

I just need to be pointed in the right direction really. I've read the libtool-automake docs but I'm still missing that piece of information that tells me how to compile now that I don't have libogg.la anymore. So in short, how do I compile in the absence of .la files?

N.B. This is all on Ubuntu Karmic Koala

+1  A: 

You shouldn't be needing the .la files. You didn't paste the important parts of the command output - what step is trying to link to the libogg.la file. My guess is libtool, and my guess is that after upgrading you're running make in your source dir or vcs checkout, without rerunning autogen.sh or configure as appropriate.

In short, you don't give enough info to help you further (How did you get fuppes ? How did you build it ? How did you try to build it after upgrading ?). Most likely either you forgot to regenerate build files, or some other linker step is pulling in a .la file and needs to be regenerated (for example, a pkg-config file).

Thomas Vander Stichele
+1  A: 

I believe that Debian has been dropping the .la files because it can cause problems when you're building for both 32-bit and 64-bit. If libtool finds a .la file, it has a nasty habit of putting the full path to the library in the link command, and this is sometimes the wrong library (32-bit instead of 64-bit or vice-versa). On Solaris, I had a problem of libtool wanting to link /usr/lib/libintl.so instead of /usr/lib/64/libintl.so, all because it found /usr/lib/libintl.la

You should be able to link without the .la file by specifying -logg on the mumble_LIBADD line (replace 'mumble' with the name of the package you're building) within the appropriate Makefile.am. If for some reason the linker can't find the library, you can specify a path to it by adding something like this:

mumble_LDFLAGS = -R/usr/lib -L/usr/lib

But in this example, I have to believe that /usr/lib is in the default search path for libraries.

To your particular error message with sed, I don't know why fuppes uses sed to find /usr/lib/libogg.la, but this may hopefully be fixed by an appropriate change upstream from libtool (like in autoconf or automake). I suspect that there's a switch somewhere in 'configure' that helps with this issue (like --with-ogg or something). Run 'configure --help' and look for some hints there.

Matt Ball
Yes this is actually what I discovered myself. I just forgot to come back here and post an answer myself. I actually have one more thing to add to that. I was using Ubuntu karmic Koala and they are one version behind Debian. I suspect that in the Debian version of the package this issue has been fixed (and maybe the configure meeds to be cleaned up too). So I guess I'll just wait for the next release. Thanks for the comprehensive answer.
Robert Massaioli
Yes this has indeed been fixed in lucid. I checked and am now letting everybody know here.
Robert Massaioli