Subject: building a static, indirect-only libGL--worth it?
To: None <>
From: Blair Sadewitz <>
List: tech-pkg
Date: 12/08/2007 09:28:51
It occurred to me this morning that building a static libGL with
indirect rendering support only could simplify life for [NetBSD] DRI
users who spend a vast majority of their time using indirect
rendering: Not only would they not have to start their compositor with
a customized environment, e.g. LIBGL_ALWAYS_INDIRECT=1, but it might
mitigate/eliminate certain issues people run into with compiz
frequently, e.g. dynamic loading/pthread insanity.

Any opinions on this?  Would we want this to be a discrete package or
included in the libGL package?
Any logic for it?  How about USE_FEATURES?



P.S. in <git://>,
there is an "autoconf2" branch with the beginnings of autoconf support
for mesa, just in case anyone's interested.  Ultimately, I'd like to
incorporate this work and use BSD makefiles and libtool along with it.
 When I saw that they were using it to provide options for Mesa's
mklib script, my head hurt! ;)