On Sat, Apr 09, 2011 at 02:04:07AM +0200, Alexander Graf wrote: > > On 08.04.2011, at 23:13, Michael Walle wrote: > > > Am Freitag 08 April 2011, 12:00:32 schrieb Edgar E. Iglesias: > >> On Thu, Apr 07, 2011 at 11:35:47PM +0200, Michael Walle wrote: > >>> Am Mittwoch 06 April 2011, 16:13:58 schrieb Benjamin Poirier: > >>>> Works as usual. > >>>> The problem I'm facing stems from linking to libGL and memory > >>>> protection issues. The particular system I ran this on has the binary > >>>> nvidia driver and its companion libGL.so.260.19.44. As such I'd take > >>>> no offense if we wave it off as a "problem in the unsupported binary > >>>> drivers" and I'll be satisfied configuring with no opengl on that > >>>> system. > >>> > >>> I would also be happy with opengl disabled by default. It is only used > >>> for one hardware model (milkymist-tmu2.c) atm. I don't think its worth > >>> that this potentially breaks qemu for lots of users. What do you think? > >> > >> I agree, FWIW I've already got a couple of reports regarding the same > >> problem. > >> > >> Cheers > > > > OTOH, a milkymist team member is worried that distributions would just > > build > > the QEMU package with the default options and all will ship > > qemu-system-lm32 > > without opengl. > > > > What do you think about disabling opengl by default except for lm32 targets? > > I would really like to see some more logic behind target library requirements > and actual linking anyway. On PPC for example, we link with libfdt to do > device tree modifications, but link with libfdt on x86 as well when it's > detected. Same goes for the xen libraries. > > Being more clever about target requirements would certainly be useful. For > now, I'd disable OpenGL by default though and then follow up with a patch to > add the cleverness :).
Yep, that sounds good. Cheers