libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Validity of "fake" convenience library


From: Dan Nicholson
Subject: Re: Validity of "fake" convenience library
Date: Mon, 3 Mar 2008 18:09:59 -0800

On Mon, Mar 3, 2008 at 5:37 PM, Peter O'Gorman <address@hidden> wrote:
>
>  Please make sure that this fake .la file is only used in the build tree
>  where it is needed (only when building xserver? Why not commit these
>  bits to xserver then?). I would not like to see such a thing in /usr/lib
>  (or /usr/X11/lib or whereever).

Yeah, it wouldn't be installed (the actual libmesa.a library isn't either).

So, here's the real quick story: when building GLX support in xserver,
a software only driver (GLcore) is created so there is a fallback when
there is no DRI driver available (the DRI drivers are built and
installed in mesa). This driver is created using the internal libmesa
library and other sources from mesa. To pull that off, the xserver has
a mirror of the mesa directory structure and a bunch on
nodist_*_SOURCES defined. The source files are symlinked in from a
user-supplied mesa tree at configure time and then true convenience
libraries are created. It's pretty ugly and breaks frequently.

I'm trying to change it so that the build will just descend into mesa
and it will handle building the necessary bits. Currently, the xserver
breaks whenever any of the files change names in mesa.

So, I suppose I could put the .la file in the xserver tree, but the
reason I put it in mesa is because that's where the actual library
would be my scenario.

>  The requirements for a convenience archive are that its objects be built
>  pic. Libtool has a pretty good idea how to do this with a large variety
>  of platforms and compilers. I have not looked at Mesa in quite a while
>  but I imagine that it also has this information for a number of
>  platforms and compilers.

More or less it does. Currently, there are a bunch of
platform-specific makefile stubs where these values are hardcoded.
I've recently added an autoconf generated configure, but it's really
light on platform specifics as I'm pretty much gcc on x86 Linux all
the time.

>  Please do not hardcode -fpic/-fPIC, as that would limit the build to
>  gcc, instead try to ensure that you know the correct pic flag for the
>  compiler and platform that the user has. You should probably refuse to
>  build this library for platforms and compiler combinations where you do
>  not know the compiler flag to generate position independent code (even
>  though pic may be the default).

I was just looking through the pic code evaluation in libtool.m4 and
not getting real excited about recreating that.

>  It really would be preferable to use libtool itself to generate this. If
>  it were possible to build it as part of the xserver then, since that
>  uses libtool, all would be well, wouldn't it?

Currently, it is generated in the xserver at the sacrifice that the
xserver tree needs to stay in lockstep with mesa. I definitely would
agree that using libtool would be better for the generation of the .la
file. I'm wondering if faking the .la file is the lesser of the two
evils if it means that building GLX in xserver would break less.

An alternative would be to keep a libtooled copy of the mesa tree in
xserver until such a time comes where GLX can be untangled from the
internals of both mesa and xserver.

Thanks for your reply.

--
Dan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]