Hi, I was reading through the debian-x list archives when I found this ...
----- Forwarded message from [EMAIL PROTECTED] (Branden Robinson) -----
To: [EMAIL PROTECTED], "Zephaniah E. Hull" <[EMAIL PROTECTED]>
Subject: Re: glide3 and X4.
From: [EMAIL PROTECTED] (Branden Robinson)
Date: Wed, 6 Sep 2000 03:25:44 -0500
In-Reply-To: <[EMAIL PROTECTED]>; from
[EMAIL PROTECTED] on Tue, Sep 05, 2000 at 04:38:34PM -0400
Mail-Followup-To: [EMAIL PROTECTED],"Zephaniah E. Hull"
<[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED] | 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 <[EMAIL PROTECTED]> for Debian email: <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED] or [EMAIL PROTECTED]
PGP signature
