On Fri, 2004-10-29 at 18:35, Felix Kühling wrote:
> Yes, that's how it works now. We can't fix the Xorg tree to compile with
> the latest Mesa source since that would break the build of the Mesa
> version that is included in the Xorg tree. ?
so if you could *NOT* compile GL on Xorg, we save some t
Hi,
It seems this change breaks the build (at least removing it makes it
compile again for me) :
http://freedesktop.org/cgi-bin/viewcvs.cgi/mesa/Mesa/src/mesa/tnl_dd/t_dd_vbtmp.h?r1=1.3&r2=1.4
While making linux-dri-x86 :
gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver
-I../../.
On Fre, 2004-10-29 at 12:47 -0700, Ian Romanick wrote:
> The problem, which exists with most (all?) DRM drivers, is that data
> types are used in the kernel/user interface that have different sizes on
> LP32 and LP64. If your kernel is 64-bit, you will have problems with
> 32-bit applications.
On Thu, 2004-10-28 at 21:59, Mike Mestnik wrote:
> -- "Srgio M. Basto" <[EMAIL PROTECTED]> wrote:
> There is another problem with the Xorg(stable or unstable) tree getting
> too far ahead of the Mesa/drm trees, AKA can't build Mesa with latesed
> Xorg.
>
I compile Xorg cvs tree with last Mesa/dr
You are correct about the unresolved symbols, they seem to happen with
the cvs code also (but I think they must be new in the last couple of
weeks sometime). Here is the output of my LIBGL_DEBUG=verbose glxinfo:
[EMAIL PROTECTED] ~ $ LIBGL_DEBUG=verbose glxinfo
name of display: :0.0
libGL: XF86DR
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1735
[EMAIL PROTECTED] changed:
What|Removed |Added
Thomas Zehetbauer wrote:
Hi again,
I have now changed Kconfig and successfully compiled, loaded and used
DRI with a Matrox Millenium G550 on a dual Opteron system. I guess this
is a pretty good test and I wonder if the problem has already been fixed
or if it was limited to specific hard- or softwar
Dieter Nützel wrote:
Addition:
XFree86 DRI CVS build works, but libGLcore.a have unresolved symbols.
Symbol _mesa_Uniform2iARB from
module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved!
I suspect you need to include shaderobjects.c/shaderobjects.o in the
Imakefile.inc of lib/GL/mesa
Am Freitag, 29. Oktober 2004 19:16 schrieb Dieter Nützel:
> Am Freitag, 29. Oktober 2004 02:12 schrieb Adam Jackson:
> > On Thursday 28 October 2004 19:58, Roland Scheidegger wrote:
> > > I can compile the dri linux target, but when I try to compile
> > > progs/tests I get something similar:
> > >
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1731
--- Additional Comments From [EMAIL PROTECTED] 2004-10-29 10:52 ---
Created an
Am Fr, den 29.10.2004 schrieb Sérgio M. Basto um 13:04:
> On Thu, 2004-10-28 at 18:58, Sérgio M. Basto wrote:
> > Hi,
> > Felix I had also problem to compile your patches
> > and after check and recheck if isn't my fault,
> > I get the conclusion that
> > I can compile mesa with make in /opt/trun
Am Do, den 28.10.2004 schrieb Daniel J. Michael um 16:56:
> Well, it seemed to install fine, but direct rendering is disabled. I
> also get this error in my Xorg.0.log:
> Symbol SavageInitStreamsNew from module
> /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved!
> Symbol SavageInitStream
Am Freitag, 29. Oktober 2004 02:12 schrieb Adam Jackson:
> On Thursday 28 October 2004 19:58, Roland Scheidegger wrote:
> > I can compile the dri linux target, but when I try to compile
> > progs/tests I get something similar:
> > gcc -I. -I../../include -DDRI_NEW_INTERFACE_ONLY -Wall -g -O
> > -DU
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1731
[EMAIL PROTECTED] changed:
What|Removed |Added
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1731
--- Additional Comments From [EMAIL PROTECTED] 2004-10-29 09:34 ---
Here's some
Am Freitag, 29. Oktober 2004 16:38 schrieb Jon Smirl:
> On Fri, 29 Oct 2004 01:54:21 +0200, Dieter Nützel
>
> <[EMAIL PROTECTED]> wrote:
> > Am Donnerstag, 28. Oktober 2004 12:42 schrieb Felix Kühling:
> > > Two small problems I had with Linux 2.6.4:
> > >
> > > 1. In order to make drm_stub.c
On Fri, 29 Oct 2004 15:20:09 +0200 (CEST), Thomas Hellström
<[EMAIL PROTECTED]> wrote:
> Forgot to mention, of course, that this leeds to an unresolved symbol in
> the binary:
>
> pci_dev_get.
linux/drm_compat.h has this in it:
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0)
#define pci_dev_put(x
On Fri, 29 Oct 2004 01:54:21 +0200, Dieter Nützel
<[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 28. Oktober 2004 12:42 schrieb Felix Kühling:
> > Two small problems I had with Linux 2.6.4:
> >
> > 1. In order to make drm_stub.c compile without errors I had to
> > #include explicitly.
>
> Anyone?
> This was introduced after 1st of October.
>
> /Thomas
>
Forgot to mention, of course, that this leeds to an unresolved symbol in
the binary:
pci_dev_get.
>
>> Hi!
>>
>> Tried to compile recent CVS under a 2.4 series kernel yesterday and got
>>
>> In file included from drm_core.h:33,
On Thu, 2004-10-28 at 18:58, Sérgio M. Basto wrote:
> Hi,
> Felix I had also problem to compile your patches
> and after check and recheck if isn't my fault,
> I get the conclusion that
> I can compile mesa with make in /opt/trunk/Mesa, but can't compile it
> if I try compile from xorg cvs ( with
Anyone?
This was introduced after 1st of October.
/Thomas
> Hi!
>
> Tried to compile recent CVS under a 2.4 series kernel yesterday and got
>
> In file included from drm_core.h:33,
> from via_drv.c:31:
> drm_drv.h: In function `drm_init':
> drm_drv.h:568: warning: implicit decla
Felix Kühling <[EMAIL PROTECTED]> writes:
> Last thing I heard of it was that the web server uses a ridiculously old
> python version. One thought that occurred to me was to move the Wiki to
> fd.o. We don't have to use the fd.o wiki system (Tiki AFAIK) but we
> could use a local MoinMoin installa
22 matches
Mail list logo
