On Mon, Mar 3, 2008 at 5:37 PM, Peter O'Gorman <[EMAIL PROTECTED]> 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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool