Re: mysterious xmms buildd failure on alpha buildd
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?"
Reply to: