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

glide 3 stuff ...



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


Reply to: