Hi, I was reading through the debian-x list archives when I found this ... ----- Forwarded message from branden@deadbeast.net (Branden Robinson) ----- To: debian-x@lists.debian.org, "Zephaniah E. Hull" <warp@whitestar.soark.net> Subject: Re: glide3 and X4. From: branden@deadbeast.net (Branden Robinson) Date: Wed, 6 Sep 2000 03:25:44 -0500 In-Reply-To: <20000905163834.C10232@whitestar.soark.net>; from warp@whitestar.soark.net on Tue, Sep 05, 2000 at 04:38:34PM -0400 Mail-Followup-To: debian-x@lists.debian.org,"Zephaniah E. Hull" <warp@whitestar.soark.net> References: <20000905163834.C10232@whitestar.soark.net> User-Agent: Mutt/1.2.5i [Merc, let's discuss this in the open on debian-x] On Tue, Sep 05, 2000 at 04:38:34PM -0400, Zephaniah E. Hull wrote: > In short, I am pretty close to having glide3 ready for testing, except > for one thing, glide3 needs libXxf86dga and libXxf86vm as shared libs > instead of static libs. These aren't compiled as dynamic libraries because they have no real API. Not one that anyone is willing to commit to yet, anyway. > The glide3 new build system uses autoconf, automake, and libtool, the > first two are no problem, the latter is another issue, glide3 links > against libXxf86dga and libXxf86vm, both of which are provided only as > static librarys. > > Not a big problem, until you interduce libtool, which absolutely refuses > to link a shared library with a non-libtool static library, there is no > quick override to say 'I know what I'm doing, now link the damn thing!', > in fact, there is no way to do that at all. Well, that's just plain stupid. There are all kinds of valid reasons to link statically to a library. > So I have three options. > 1: Have libXxf86dga and libXxf86vm as shared libs. > 2: Rewrite the entire glide3 build system. > 3: Learn and rewrite libtool. > > Obviously, the latter two are not high on my list of things I'd love to > do, the first depends on you. I am highly reluctant to do that unless it really turns out to be the only option. Is there a chance that the libtool maintainer(s) can be taught to see reason? Know anyone who can stalk and beat them in a dark alleyway? > Let me know ASAP so I can start the rewrite of the glide3 build system > if I need to. Let's see if we can't accomplish something with threats and intimidation against our common enemy first. gcc -DLIBTOOL_IS_A_FOOL -- G. Branden Robinson | Debian GNU/Linux | Exercise your freedom of religion. Set branden@deadbeast.net | fire to a church of your choice. http://deadbeast.net/~branden/ | ----- End forwarded message ----- I've been mucking around trying to get glide3 building properly (ie. without the nasty libtool errors) for quite a while now. I think you can totally rule out option 3, as there is a reason why libtool wants shared rather than static libs - when libtool compiles source files for a library, it does 2 compiles - one compiled with -fPIC -DPIC (for the shared library), and the other without. The shared ones have a .lo suffix, the static ones a normal .o. Obviously, the static libs that glide wants aren't compiled with -fPIC -DPIC, so statically linking libXxf86(dga|vm).a to libglide.so would be bad _bad_ BAD, as well as violating policy. This would also be the case with the old glide3 build system, as it is still linking a shared library compiled with -fPIC with the static objects from libXxf86(dga|vm).a. Option 2 is a _real_ pain in the arse (without going back to glide3's old non-autoconfuse build system), so the only solution I can see are to do option 1. Only a tiny change to the debian host.def file (2 added lines): #define SharedLibXxf86dga YES #define SharedLibXxf86vm YES and adding: usr/X11R6/lib/libXxf86dga.so.1 usr/X11R6/lib/libXxf86dga.so.1.0 usr/X11R6/lib/libXxf86vm.so.1 usr/X11R6/lib/libXxf86vm.so.1.0 to debian/xlibs.files, as well as: usr/X11R6/lib/libXxf86dga.so usr/X11R6/lib/libXxf86vm.so to debian/xlibs-dev.files. IMHO, there isn't much alternative other than to use shared libs ... Comments? I was also wondering about getting DRM modules in a package somewhere ... At the moment the DRM modules are not built - it's a simple matter of cd'ing to xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel and doing a 'make -f Makefile.linux'. I thought that a package could be made out of this for 'make-kpkg modules_image' to build. If I get time on the W/E I'll sit down to look at it and see what I can do. AFAICT, For my card (3Dfx VB) (as well as many others I believe), DRI does nothing without the DRM module. Thoughts/comments/criticisms/suggestions welcome. Thanks, Timshel -- Timshel Knoll <timshel@pobox.com> for Debian email: <timshel@debian.org> Second year Computer Science, RMIT | CS108 Tutor (Semester 2, 2000) Debian GNU/Linux developer, see http://www.debian.org/~timshel/ For GnuPG public key: finger timshel@ozemail.com.au or timshel@debian.org
Attachment:
pgpy50GI3wu0D.pgp
Description: PGP signature