mesa3d-dev

RE: [Mesa3d-dev] WIN32 compilation, problems and partial patch

[Suhaib M. S. <ssi...@nc...>]

That one I already tried.  I was asking Makefiels or 
MSVC project files for whole Mesa3D code, not only 3dfx.

Suhaib


> -----Original Message-----
> From: Eero Pajarre [mailto:epa...@ko...]
> Sent: Sunday, June 04, 2000 2:11 PM
> To: Suhaib M. Siddiqi
> Cc: mes...@li...
> Subject: Re: [Mesa3d-dev] WIN32 compilation, problems and partial patch
> 
> 
> "Suhaib M. Siddiqi" wrote:
> > 
> > One more problem.  The Microsoft Makefiles in CVS are 
> aboslutely useless.  I
> > assume Ted Jump is not supporting the project.  I started 
> working on fixing
> > Mesa3D for Widnows, but soon discovered the Makefiles in Win32 
> directory are
> > useless and Ted removed the Developers Studio Project  files 
> long time ago.
> > One had to create MSVC project files from scratch.  If anyone 
> has working
> > Makefiles or Developers Studio Projectf iles for MSVC, please 
> post them or
> > send them to me by email (ssi...@in...).  It will 
> be of great
> > help and speed up work.
> > 
> > Thanks
> > Suhaib
> > 
> 
> The Makefile.fx files in the src  (+ glu + glut + 3dfx/demos)
> directories should work if you want a glide accelerated Mesa.
> the src/makefile.fx is also 3DNow + PIII enhanced (with nasm)
> 
> I have tried to keep them up to date, although I have not tested the
> latest chages. I have changed my main computer to a non 3dfx display
> so I will be myself using these files less in the future.
> 
> 
> 		Eero

Re: [Mesa3d-dev] WIN32 compilation, problems and partial patch

[Eero P. <epa...@ko...>]

"Suhaib M. Siddiqi" wrote:
> 
> One more problem.  The Microsoft Makefiles in CVS are aboslutely useless.  I
> assume Ted Jump is not supporting the project.  I started working on fixing
> Mesa3D for Widnows, but soon discovered the Makefiles in Win32 directory are
> useless and Ted removed the Developers Studio Project  files long time ago.
> One had to create MSVC project files from scratch.  If anyone has working
> Makefiles or Developers Studio Projectf iles for MSVC, please post them or
> send them to me by email (ssi...@in...).  It will be of great
> help and speed up work.
> 
> Thanks
> Suhaib
> 

The Makefile.fx files in the src  (+ glu + glut + 3dfx/demos)
directories should work if you want a glide accelerated Mesa.
the src/makefile.fx is also 3DNow + PIII enhanced (with nasm)

I have tried to keep them up to date, although I have not tested the
latest chages. I have changed my main computer to a non 3dfx display
so I will be myself using these files less in the future.


		Eero

RE: [Mesa3d-dev] WIN32 compilation, problems and partial patch

[Suhaib M. S. <ssi...@nc...>]

One more problem.  The Microsoft Makefiles in CVS are aboslutely useless.  I
assume Ted Jump is not supporting the project.  I started working on fixing
Mesa3D for Widnows, but soon discovered the Makefiles in Win32 directory are
useless and Ted removed the Developers Studio Project  files long time ago.
One had to create MSVC project files from scratch.  If anyone has working
Makefiles or Developers Studio Projectf iles for MSVC, please post them or
send them to me by email (ssi...@in...).  It will be of great
help and speed up work.

Thanks
Suhaib

> -----Original Message-----
> From: mes...@li...
> [mailto:mes...@li...]On Behalf Of Eero Pajarre
> Sent: Sunday, June 04, 2000 12:57 PM
> To: Brian Paul; mes...@li...
> Subject: Re: [Mesa3d-dev] WIN32 compilation, problems and partial patch
>
>
> Brian Paul wrote:
> >
> > Eero Pajarre wrote:
> > >
>
> > > I am not sure how to fix this, except by placing the
> > > definitions of HGLRC etc back to one of the
> > > GL/*.h files, or including <windows.h> there.
> >
> > As you've seen, I removed a lot of Windows-related stuff from the
> > gl.h header because it doesn't belong there.  Sorry for breaking
> > things on Windows.
> >
> > It seems to me that HGLRC stuff should go in mesa_wgl.h.
> >
>
>
> I have just done a major software/hardware change on my setup.
> Among other things I installed was the "Microsoft Platform SDK".
>
> The SDK contains lots of new header files,
> which it plugs in to the VC++ compilation process.
> If no special options are used, these files apparently
> actively break any user defined HGLRC (or any other opaque type)
> definitions. I understand that enforcing the opaquenes of the types
> does have its merit.
>
> As I want to get my program to compile (still using
> Mesa gl*.h files) I had to create my own header file
> which first includes windows.h and then includes the gl*.h files.
>
> It looks like that in order to be compatible with the different
> alternatives, the only way is to include windows.h...
> I think this is an issue especially for glut.h because
> it is supposed to not require the user to include
> any "windows.h" like headers.
>
>
>
> 			Eero
>
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> http://lists.sourceforge.net/mailman/listinfo/mesa3d-dev

Re: [Mesa3d-dev] WIN32 compilation, problems and partial patch

[Eero P. <epa...@ko...>]

Brian Paul wrote:
> 
> Eero Pajarre wrote:
> >

> > I am not sure how to fix this, except by placing the
> > definitions of HGLRC etc back to one of the
> > GL/*.h files, or including <windows.h> there.
> 
> As you've seen, I removed a lot of Windows-related stuff from the
> gl.h header because it doesn't belong there.  Sorry for breaking
> things on Windows.
> 
> It seems to me that HGLRC stuff should go in mesa_wgl.h.
> 


I have just done a major software/hardware change on my setup.
Among other things I installed was the "Microsoft Platform SDK".

The SDK contains lots of new header files,
which it plugs in to the VC++ compilation process.
If no special options are used, these files apparently
actively break any user defined HGLRC (or any other opaque type)
definitions. I understand that enforcing the opaquenes of the types
does have its merit.

As I want to get my program to compile (still using 
Mesa gl*.h files) I had to create my own header file
which first includes windows.h and then includes the gl*.h files.

It looks like that in order to be compatible with the different 
alternatives, the only way is to include windows.h...
I think this is an issue especially for glut.h because 
it is supposed to not require the user to include 
any "windows.h" like headers.



			Eero

Re: [Mesa3d-dev] glide3 compilation fix for mesa_3_2_dev

[Andy S. <an...@gu...>]

It seems there are other problems with glide3...

The code that checks for framebuffer and texture ram seems to expect a
number in bytes, but on my voodoo2 with glide3 it reports megs.  removing
the line that says
       config->SSTs[i].sstBoard.VoodooConfig.fbRam/= 1024*1024;
and 
       config->SSTs[i].sstBoard.VoodooConfig.tmuConfig[j].tmuRam /= 1024*1024;

takes care of that.

Does the Voodoo3/banshee/whatever report bytes instead of megs?  is this an
inconsistency or just untested code?

I've also added some more modes that glide supports to the table in
fxGetBestResolution, since it has been a pet peeve of mine that mesa would
always show tiny windows in 640x480 mode when i was trying out low
resolution modes.

The diff is attached here.

-Andy

Re: [Mesa3d-dev] glide3 compilation fix for mesa_3_2_dev

[Brian P. <br...@pr...>]

Andy Sloane wrote:
> 
> 3dfx Glide version 3 doesn't have a grSstQueryHardware function.  I gather
> this is why the FX_grSstQueryHardware wrappers exist in the src/FX tree.
> 
> But it turns out that X/xmesa1.c uses grSstQueryHardware to determine
> whether a 3dfx card is really installed, which resulted in linking problems
> when trying to run mesa3d apps.
> 
> This seems to take care of it:
> 
> Index: src/X/xmesa1.c
> ===================================================================
> RCS file: /cvsroot/mesa3d/Mesa/src/X/xmesa1.c,v
> retrieving revision 1.7.2.3
> diff -u -r1.7.2.3 xmesa1.c
> --- src/X/xmesa1.c      2000/05/20 23:17:37     1.7.2.3
> +++ src/X/xmesa1.c      2000/05/26 17:37:09
> @@ -2073,7 +2073,7 @@
>     const char *fx = getenv("MESA_GLX_FX");
>     if (fx && fx[0] != 'd') {
>        GrHwConfiguration hw;
> -      if (!grSstQueryHardware(&hw))
> +      if (!FX_grSstQueryHardware(&hw))
>           return GL_FALSE;
>        if (hw.num_sst < 1)
>           return GL_FALSE;
> 
> I know this problem exists in the current mesa_3_2_dev branch, but I don't
> know about the status of the other branches.

Fixed in the 3.2 and 3.3 branches.  Thanks.

-Brian

[Mesa3d-dev] glide3 compilation fix for mesa_3_2_dev

[Andy S. <an...@gu...>]

3dfx Glide version 3 doesn't have a grSstQueryHardware function.  I gather
this is why the FX_grSstQueryHardware wrappers exist in the src/FX tree.

But it turns out that X/xmesa1.c uses grSstQueryHardware to determine
whether a 3dfx card is really installed, which resulted in linking problems
when trying to run mesa3d apps.

This seems to take care of it:

Index: src/X/xmesa1.c
===================================================================
RCS file: /cvsroot/mesa3d/Mesa/src/X/xmesa1.c,v
retrieving revision 1.7.2.3
diff -u -r1.7.2.3 xmesa1.c
--- src/X/xmesa1.c	2000/05/20 23:17:37	1.7.2.3
+++ src/X/xmesa1.c	2000/05/26 17:37:09
@@ -2073,7 +2073,7 @@
    const char *fx = getenv("MESA_GLX_FX");
    if (fx && fx[0] != 'd') {
       GrHwConfiguration hw;
-      if (!grSstQueryHardware(&hw))
+      if (!FX_grSstQueryHardware(&hw))
          return GL_FALSE;
       if (hw.num_sst < 1)
          return GL_FALSE;

I know this problem exists in the current mesa_3_2_dev branch, but I don't
know about the status of the other branches.

-Andy

Re: [Mesa3d-dev] WIN32 compilation, problems and partial patch

[Brian P. <br...@pr...>]

Eero Pajarre wrote:
> 
> I compiled the latest CVS sources using the Makefile.fx.
> There were problems with mesa_wgl.h and undefined
> HGLRC etc.
> 
> glheader.h defines these symbols, but it includes
> gl.h (which includes mesa_wgl.h) before defining
> them.
> 
> Thus I was able to get rid of these errors by moving
> the point where glheader.h includes gl.h to
> a latter position in the file: (patch attached in the
> end)
> 
> I also #if ed out the #define CALLBACK in glheader.h
> because it gave me duplicate definition warnings.
> 
> There were also problems in compiling some
> of the subdirectories of src.
> In order to fix these I changed:
> fxdrv.h, osmesa.c and x86.c
> to include glheader.h before including other Mesa headers.

I've applied your patch and fixed those 3 files.  I'll check
them in soon, after I've tested.


> With these changes I got the library to compile, but there is
> an other problem: When my application code uses <GL/gl.h>
> (or even GL/glut.h), I get errors from mesa_wgl.h.
> I assume that I could fix these by including windows.h first
> but a) I don't want to
>     b) I thought that especially with glut.h that should not be
>         needed.
> 
> I am not sure how to fix this, except by placing the
> definitions of HGLRC etc back to one of the
> GL/*.h files, or including <windows.h> there.

As you've seen, I removed a lot of Windows-related stuff from the
gl.h header because it doesn't belong there.  Sorry for breaking
things on Windows.

It seems to me that HGLRC stuff should go in mesa_wgl.h.

-Brian

[Mesa3d-dev] WIN32 compilation, problems and partial patch

[Eero P. <epa...@ko...>]

I compiled the latest CVS sources using the Makefile.fx.
There were problems with mesa_wgl.h and undefined 
HGLRC etc.

glheader.h defines these symbols, but it includes
gl.h (which includes mesa_wgl.h) before defining
them.

Thus I was able to get rid of these errors by moving
the point where glheader.h includes gl.h to
a latter position in the file: (patch attached in the
end)

I also #if ed out the #define CALLBACK in glheader.h
because it gave me duplicate definition warnings.

There were also problems in compiling some
of the subdirectories of src.
In order to fix these I changed:
fxdrv.h, osmesa.c and x86.c
to include glheader.h before including other Mesa headers.


With these changes I got the library to compile, but there is
an other problem: When my application code uses <GL/gl.h>
(or even GL/glut.h), I get errors from mesa_wgl.h.
I assume that I could fix these by including windows.h first
but a) I don't want to
    b) I thought that especially with glut.h that should not be 
	needed.

I am not sure how to fix this, except by placing the 
definitions of HGLRC etc back to one of the
GL/*.h files, or including <windows.h> there.

Notice that doing, one of these might be incompatible
with my patch for compiling Mesa library itself.

	Eero




 
Index: glheader.h
===================================================================
RCS file: /cvsroot/mesa3d/Mesa/src/glheader.h,v
retrieving revision 1.9
diff -c -r1.9 glheader.h
*** glheader.h	2000/05/22 19:41:34	1.9
--- glheader.h	2000/05/25 06:09:44
***************
*** 63,71 ****
  #include "conf.h"
  #endif
  
- /* Make sure we include glext.h */
- #include "GL/gl.h"
- #include "GL/glext.h"
  
  
  
--- 63,68 ----
***************
*** 133,139 ****
--- 130,138 ----
  /* compatability guard so we don't need to change client code */
  
  #if defined(_WIN32) && !defined(_WINDEF_) && !defined(_GNU_H_WINDOWS32_BASE) && !defined(OPENSTEP)
+ #if 0
  #	define CALLBACK GLCALLBACK
+ #endif
  typedef int (GLAPIENTRY *PROC)();
  typedef void *HGLRC;
  typedef void *HDC;
***************
*** 158,163 ****
--- 157,165 ----
  #include <gl/mesa_wgl.h>
  #endif
  
+ /* Make sure we include glext.h */
+ #include "GL/gl.h"
+ #include "GL/glext.h"

Re: [Mesa3d-dev] assertion failure in HEAD CVS

[Brian P. <br...@pr...>]

Michael Vance wrote:
> 
> On Wed, May 24, 2000 at 09:10:17AM -0700, Michael Vance wrote:
> > sof-bin: glapi.c:1566: _glapi_add_entrypoint: Assertion `!GetSizeCalled' failed.
> 
> Followup:
> 
> Assertion error condition set:
> 
> _glapi_get_dispatch_table_size
> _mesa_initialize_context
> gl_create_context
> XMesaCreateContext
> Fake_glXCreateContext
> glXCreateContext
> 
> Assertion failure:
> 
> _glapi_add_entrypoint
> _mesa_initialize_context
> gl_create_context
> fxMesaCreateContext
> fxMesaCreateBestContext
> XMesaCreateWindowBuffer2
> Fake_glXMakeContextCurrent
> Fake_glXMakeCurrent
> glXMakeCurrent

Update and try again.  I hadn't tested my latest changes with the 3dfx driver.

-Brian

Re: [Mesa3d-dev] assertion failure in HEAD CVS

[Michael V. <bri...@lo...>]

On Wed, May 24, 2000 at 09:10:17AM -0700, Michael Vance wrote:
> sof-bin: glapi.c:1566: _glapi_add_entrypoint: Assertion `!GetSizeCalled' failed.

Followup:

Assertion error condition set:

_glapi_get_dispatch_table_size
_mesa_initialize_context
gl_create_context
XMesaCreateContext
Fake_glXCreateContext
glXCreateContext

Assertion failure:

_glapi_add_entrypoint
_mesa_initialize_context
gl_create_context
fxMesaCreateContext
fxMesaCreateBestContext
XMesaCreateWindowBuffer2
Fake_glXMakeContextCurrent
Fake_glXMakeCurrent
glXMakeCurrent

m.

-- 
Programmer             "Ha ha." "Ha ha." "What are you laughing at?"
Loki Software                      "Just the horror of being alive."
http://lokigames.com/~briareos/                   - Tony Millionaire

[Mesa3d-dev] assertion failure in HEAD CVS

[Michael V. <bri...@lo...>]

sof-bin: glapi.c:1566: _glapi_add_entrypoint: Assertion `!GetSizeCalled' failed.

m.

-- 
Programmer             "Ha ha." "Ha ha." "What are you laughing at?"
Loki Software                      "Just the horror of being alive."
http://lokigames.com/~briareos/                   - Tony Millionaire

Re: [Mesa3d-dev] A new face on the dev list

[Brian P. <br...@pr...>]

Joris Timmermans wrote:
> 
> Though it seems kindof intimidating now that I'm in here,
> I'd like to contribute to the Mesa3D project.  I downloaded the source
> a few days ago, while working on my PhD thesis, because I was looking
> for an open-source, well-documented graphics API to extend.
> Mesa seemed the perfect solution, since it builds fine on my
> Windows NT system.
> 
> The only problem is - it's not so easy to figure out where to add things
> that I need.  I've added the "#define"s that are necessary, and some
> additional glSomethingEXT functions.  I've located the rasterizer code,
> and played with it a little to learn more.
> However, the old developer document on the website is out of date
> ( it mentions draw.c for instance, no longer in the source tree ),
> so it's very hard to figure out the sequence of calls that occurs after
> a set of calls between glBegin(), glEnd().  I need to break into these
> calls, because my extension requires a lot of work to be done after
> the initial modeling transformation.
> 
> Is this still possible?
> Have I missed any important documentation perhaps? ( I've checked the
> readme.* files in the source tree ).

The code changes faster than the documentation.

The T&L code is pretty complicated because of all the optimizations.
Even I don't understand/know it very well.  Keith Whitwell's the person
to ask about it but he's been busy with hardware driver work.

You can ask your questions here, of course.

-Brian

[Mesa3d-dev] A new face on the dev list

[Joris T. <jor...@lu...>]

Though it seems kindof intimidating now that I'm in here,
I'd like to contribute to the Mesa3D project.  I downloaded the source
a few days ago, while working on my PhD thesis, because I was looking
for an open-source, well-documented graphics API to extend.
Mesa seemed the perfect solution, since it builds fine on my
Windows NT system.

The only problem is - it's not so easy to figure out where to add things
that I need.  I've added the "#define"s that are necessary, and some 
additional glSomethingEXT functions.  I've located the rasterizer code,
and played with it a little to learn more.
However, the old developer document on the website is out of date
( it mentions draw.c for instance, no longer in the source tree ),
so it's very hard to figure out the sequence of calls that occurs after
a set of calls between glBegin(), glEnd().  I need to break into these
calls, because my extension requires a lot of work to be done after
the initial modeling transformation.

Is this still possible?
Have I missed any important documentation perhaps? ( I've checked the 
readme.* files in the source tree ).

Thanks in advance,
Joris

[Mesa3d-dev] old mailing lists now shut down

[Brian P. <br...@pr...>]

FYI: the old mes...@me... and mes...@me... mailing lists
have now been shut down.

-Brian

Re: [Mesa3d-dev] Tru64 compile

[Stephen J B. <sj...@ht...>]

On Mon, 22 May 2000, Sven M. Hallberg wrote:

> On Mon, May 22, 2000 at 08:14:24AM -0600, Brian Paul wrote:
> > 
> > I get occasional emails from people asking why the Windows or DOS
> > drivers don't compile and I explain that nobody has volunteered to
> > maintain them.  It would be great if you could help out with this.
> 
> Agreed, that would be good. If something has to be done on the configure
> process, be sure to let me know, I'll be happy to take it. However I
> don't have the time or experience to actually do much work on the Win/DOS
> compilation itself.
 
Yep - but welcome to the land of freeware.  If there is so little interest
in something that nobody will step forward to maintain it, it *will* die.

It's unreasonable to expect people who are primarily focussed on Linux
(and a few other non-Microsoft OS's) to care very much about an OS that
already has quite a few reasonable OpenGL implementations.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@ht...            http://www.hti.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

[Mesa3d-dev] bugs can be closed

[Sven M. H. <pe...@gm...>]

Ok, I've submitted my changes to fix bugs 104648 and 105372. Someone with
Tru64 acces should check it out to confirm whether 104648 can really be
closed.

Furthermore I don't think bug #105057 (GLUT is not installed in `make
install' and not warned) is not up to date anymore. When I compiled Mesa it
installed glut fine at least.

So long,
Sven

-- 
"Think for yourself, Schmuck!"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

RE: [Mesa3d-dev] Tru64 compile

[Suhaib M. S. <ssi...@in...>]

>
> I get occasional emails from people asking why the Windows or DOS
> drivers don't compile and I explain that nobody has volunteered to
> maintain them.  It would be great if you could help out with this.
>

I can help with WIndows, but DOS is beyond my reach.  I do not have
it installed.

> Later today I'll probably check in a bunch of changes I made to
> clean-up the GL/gl.h header.  I moved a lot of the Windows-related
> #defines and #pragmas into other files.  Testing on Windows will
> probably expose some typos, etc.
>


There are several options for Windows

1) Microsoft Viusal C/C++ and build Mesa3D with wgl

2) Many developers want Mesa3D with glx API instead of wgl
so they can port UNIX OpenGL applications to Windows without
rewriting the code.  Of course it requires an X-server for Windodws.
I had been using Mesa for this option for a while.

3) Cygwin and MingW32 both cane be used to compile Mesa with wgl

4) Cygwin and Microsoft compilers, both, can be used to compile Mesa3D with
glx

Suhaib

> -Brian
>
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> http://lists.sourceforge.net/mailman/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Tru64 compile

[Sven M. H. <pe...@gm...>]

On Mon, May 22, 2000 at 08:14:24AM -0600, Brian Paul wrote:
> 
> I get occasional emails from people asking why the Windows or DOS
> drivers don't compile and I explain that nobody has volunteered to
> maintain them.  It would be great if you could help out with this.

Agreed, that would be good. If something has to be done on the configure
process, be sure to let me know, I'll be happy to take it. However I
don't have the time or experience to actually do much work on the Win/DOS
compilation itself.

Sven

-- 
"Think for yourself, Schmuck!"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

Re: [Mesa3d-dev] Tru64 compile

[Brian P. <br...@pr...>]

"Suhaib M. Siddiqi" wrote:
> 
> > The cygwin case isn't that bad, I have cygwin installed here but
> > am not too
> > familiar with its internals. If there's somebody with more experience I'd
> > greatly appreciate any advice.
> >
> >
> 
> What do you want to do with Cygwin, or what kind of help do you need?
> Basically, you need to watch out the #ifdef WIN32 and #ifdef __CYGWIN32__
> conflicts.
> I have fixed them several times, but till now I did not participated in
> Mesa3D developements
> therefore they never became part of official source tree.  A few times, I
> sent Makefile
> patches to Brian and they were added config files.
> 
> BTW: I sawa  note on Mesa3D home Page that Brian needs help for Win32 etc.
> I will be willing
> to help as time permits.

I get occasional emails from people asking why the Windows or DOS
drivers don't compile and I explain that nobody has volunteered to
maintain them.  It would be great if you could help out with this.

Later today I'll probably check in a bunch of changes I made to
clean-up the GL/gl.h header.  I moved a lot of the Windows-related
#defines and #pragmas into other files.  Testing on Windows will
probably expose some typos, etc.

-Brian

Re: [Mesa3d-dev] cygwin compile [Was: Tru64 compile]

[Sven M. H. <pe...@gm...>]

On Sun, May 21, 2000 at 08:00:19PM -0400, Suhaib M. Siddiqi wrote:
> > There's just an open bug stating that Mesa doesn't compile on 
> > cygwin, nothing
> > more. Well I can confirm it doesnt compile. I don't remember 
> > exactly what the
> > error was, but I'll post it sometime soon when I get around 
> > booting windoze
> > again.
> > 
> 
> 
> What the bug is which prevents its compilation? 
> I will have a look when I get time.

OK, great.

Thanks,
Sven

-- 
"Think for yourself, Schmuck!"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

RE: [Mesa3d-dev] cygwin compile [Was: Tru64 compile]

[Suhaib M. S. <ssi...@nc...>]

> On Mon, May 22, 2000 at 10:47:36AM -0400, Suhaib M. Siddiqi wrote:
> > What do you want to do with Cygwin, or what kind of help do you need?
> 
> There's just an open bug stating that Mesa doesn't compile on 
> cygwin, nothing
> more. Well I can confirm it doesnt compile. I don't remember 
> exactly what the
> error was, but I'll post it sometime soon when I get around 
> booting windoze
> again.
> 


What the bug is which prevents its compilation? 
I will have a look when I get time.

> 
> > Basically, you need to watch out the #ifdef WIN32 and #ifdef 
> __CYGWIN32__
> > conflicts.
> > I have fixed them several times, but till now I did not participated in
> > Mesa3D developements
> > therefore they never became part of official source tree.  A 
> few times, I
> > sent Makefile
> > patches to Brian and they were added config files.
> 
> The best thing will probably be if you try to compile Mesa under cygwin
> yourself, patching those errors you already know. Then just send 
> the patches
> in so we can, having those all ruled out, start fixing other 
> problems together
> (if you have time that is).
> 
> 
> Thanks,
> Sven
> 
> -- 
> "Think for yourself, Schmuck!"
>  [ KeyID........: 0xC297FEAB ]
>  [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

Re: [Mesa3d-dev] cygwin compile [Was: Tru64 compile]

[Sven M. H. <pe...@gm...>]

On Mon, May 22, 2000 at 10:47:36AM -0400, Suhaib M. Siddiqi wrote:
> What do you want to do with Cygwin, or what kind of help do you need?

There's just an open bug stating that Mesa doesn't compile on cygwin, nothing
more. Well I can confirm it doesnt compile. I don't remember exactly what the
error was, but I'll post it sometime soon when I get around booting windoze
again.


> Basically, you need to watch out the #ifdef WIN32 and #ifdef __CYGWIN32__
> conflicts.
> I have fixed them several times, but till now I did not participated in
> Mesa3D developements
> therefore they never became part of official source tree.  A few times, I
> sent Makefile
> patches to Brian and they were added config files.

The best thing will probably be if you try to compile Mesa under cygwin
yourself, patching those errors you already know. Then just send the patches
in so we can, having those all ruled out, start fixing other problems together
(if you have time that is).


Thanks,
Sven

-- 
"Think for yourself, Schmuck!"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

RE: [Mesa3d-dev] Tru64 compile

[Suhaib M. S. <ssi...@nc...>]

> The cygwin case isn't that bad, I have cygwin installed here but
> am not too
> familiar with its internals. If there's somebody with more experience I'd
> greatly appreciate any advice.
>
>

What do you want to do with Cygwin, or what kind of help do you need?
Basically, you need to watch out the #ifdef WIN32 and #ifdef __CYGWIN32__
conflicts.
I have fixed them several times, but till now I did not participated in
Mesa3D developements
therefore they never became part of official source tree.  A few times, I
sent Makefile
patches to Brian and they were added config files.

BTW: I sawa  note on Mesa3D home Page that Brian needs help for Win32 etc.
I will be willing
to help as time permits.

Suhaib


> Thanks,
> Sven
>
> --
> "Think for yourself, Schmuck!"
>  [ KeyID........: 0x0F520CF9 ]
>  [ Fingerprint..: 56 61 00 18 14 B4 01 01  06 90 D0 29 96 BD 58 6F ]
>
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> http://lists.sourceforge.net/mailman/listinfo/mesa3d-dev

[Mesa3d-dev] Tru64 compile

[Sven M. H. <pe...@gm...>]

Hi everyone, 

I've been in touch with Brian for some days, have fixed some issues with the
configure script, and am now trying to resolve other compilation issues,
namely bug #104528 (Mesa 3.2b1 fails to link on Compaq Tru64 UNIX) and #104856
(compilation on cygwinB + win2k fails).

Unfortunately I don't have access to Tru64 UNIX so it would be of great help
is someone else who does could assist me in finding the reason for the strange
behaviour. Over.

On the same note, I've already patched configure.in to include the compiler
flags suggested in bug #104648 (Tru64 Mesa crashes if not compiled with -g)
when on Tru64. Can someone verify the correctness of this?

The cygwin case isn't that bad, I have cygwin installed here but am not too
familiar with its internals. If there's somebody with more experience I'd
greatly appreciate any advice.


Thanks,
Sven

-- 
"Think for yourself, Schmuck!"
 [ KeyID........: 0x0F520CF9 ]
 [ Fingerprint..: 56 61 00 18 14 B4 01 01  06 90 D0 29 96 BD 58 6F ]