On Saturday 27 September 2003 06:37 pm, Josip Rodin wrote: > The buildd on lully persistently can't build Input/mpg123 in > xmms 1.2.8 and unfortunately it's 2>/dev/null'ed (standard > libtool procedure, or so they say).
The "standard libtool procedure," as I understand it, is to compile each source file twice--once with all the necessary flags to create position-independent code (e.g. "-fpic -fPIC -DPIC"), then once more without those flags. The first pass creates a .lo file and lets the compiler warnings/errors go straight to the terminal; the second pass creates a .o file and throws stderr into /dev/null (as you saw). I believe libtool does much the same when linking both static and dynamic libraries in parallel--the first pass builds a .so from .lo files, and the second pass builds a .a from .o files. The errors from the static build get thrown away. In theory this should be A-OK, as the error/warning output from both passes would normally be the same. In practice it doesn't always work this way. :( > I tried to build it on escher and faure and it worked fine on > both, there was no such failure. I couldn't do it on lully > itself as there was no libgtk1.2-dev (maybe I should ask > -admin to install it?). Yes, ask an admin to install it. That contains the static gtk+ libraries, which you WILL need to build xmms with --enable-static. When you're linking stuff into a static library, everything you link in needs to either be a static library or an object file. I imagine libtool is trying to build the static mpg123 plugin, needs the static gtk+ library for it, but can only find the dynamic version. Of course, this only causes a problem when building the static plugin, and guess when the errors are thrown away... :/ -- Kelledin "If a server crashes in a server farm and no one pings it, does it still cost four figures to fix?"
