mesa3d-dev

Re: [Mesa3d-dev] glReadPixels

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

Michael Vance wrote:
> 
> On Mon, Jul 03, 2000 at 08:14:57AM -0500, Stephen J Baker wrote:
> 
> > Since passing NULL to glReadPixels is illegal, you are lucky (perhaps)
> > not to get a core dump.  The effect of passing garbage pointers to OpenGL
> 
> This begs a question or two:
> 
> 1) why does Mesa not barf on NULL textures to glTexImage2D()?
> 
> ... Looking at the source it seems this is allowed.

Yes, See the last paragraph of section 3.8.1 of the 1.2 spec.
NULL is allowed for glTexImage[123]D.


> 2) where does the spec spell out when NULL pointers should or should
> not generate errors

You've got to hunt around.  Off-hand, I recall that glRead/DrawPixels
don't allow NULL but glBitmap does.

-Brian

[Mesa3d-dev] Proxy texture problems in 3.3?

[Scott M. <mcm...@ca...>]

Has anyone else noticed problems with proxy texture tests failing
in recent versions of 3.3?  I have them failing on relatively small
(64x64) ones whereas in 3.2 the test passed (or at least seemed to).
I will try and come up with a small test case, but it may take me
a while.

scott

-- 
Scott McMillan                        mailto:mcm...@ca...
Cambridge Research Associates         http://www.cambridge.com
1430 Spring Hill Road, Ste. 200       Voice: (703) 790-0505 x7235
McLean, VA 22102                      Fax:   (703) 790-0370

[Mesa3d-dev] mesa 3.2/win32+3dfx with optimizations link-error (?!?)

[Alessandro P. <al...@ti...>]

Hi all.
I'm having some problems with 3dnow and MMX optimized code compiling the 
Mesa3.2 for Win32 using 3dfx-Glide driver.
I use MS-VC 6.0, NASM 0.98 and Glide SDK 2.x.
The problem is: the code is compiled and linked successfully in 
opengl32.dll *only if* i do not set USE_X86_ASM nor USE_3DNOW_ASM nor 
USE_MMX_ASM, which i do adding /DUSE_xxx_ASM swtiches in the $(CPPOPTS) 
field of (mesadir)\WIN32\RULES\LIB.FXMESA and 
(mesadir)\WIN32\RULES\LIB.FXMESA32 .

Enabling these switches (which make optimized routines becoming operative) 
cause code to be compiled successfully but resulting in a linked error from 
NASM during opengl32.dll creation. Also, as far as i see in makefile.fx 
file in (mesadir)\src, the file src\fx\x86\fx_3dnow_fastpath.S is NOT 
compiled 'cos it is missing in both lib.fxmesa and lib.fxmesa32.

The error i obtain is specifically this:

.\Release\fxmesa32\OpenGL32.dll ...
NMAKE : fatal error U1077: 'E:\PROGRA~1\MICROS~2\VC98\BIN\link.exe' : 
return code '0x460'
Stop.
NMAKE : fatal error U1077: '"E:\PROGRAMMI\MICROSOFT VISUAL 
STUDIO\VC98\BIN\NMAKE.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"E:\PROGRAMMI\MICROSOFT VISUAL 
STUDIO\VC98\BIN\NMAKE.exe"' : return code '0x2'
Stop.

I found it happens IF AND ONLY IF the gl_init_xxx_asm_transforms() (where 
xxx can assume values of x86, 3dnow, mmx) function is compiled.

Is this a known problem ? What can I do ?
Thank you in advance,
TXM
---
Alessandro Pisani aka TXM - email:al...@ti..., ICQ #2209087
INWO Project Head-programmer - http://www.inwoproject.f2s.com/
Team Isa++ software design coder ----- http://teamisa.cjb.net/

[Mesa3d-dev] Re: [ogl-sample] SGI SI GLU integration

[Olivier M. <Oli...@cy...>]

Good news: It was a bit tricky, but I successfully built 2 RPM binary
packages (for i386)

  ogl-sample-glu-1.3.04JUL00-1.i386.rpm and
mesa-without-glu-3.3.04JUL00-1.i386.rpm

I am not sure the names and version numbering are fine, but that's just
a first trial.

You may use rpm -Uvh with --nodeps or --force to get them installed
properly on differents Linux distros I could test it on Suze 6.4, Redhat
6.0 and Slackware 7.0 and seemed to work properly: the tesselator
doesn't crash my app any more :)

These packages are available at ftp://ftp.cyberbotics.com (you may also
download the other packages to test my app: webots).

I finally found the real problem with building the SGI libGLU from the
current CVS:

In the file glue.c, the functions

static const char *__glNURBSErrorString( int errno )

and

static const char *__glTessErrorString( int errno )

should not be defined as static because they are used by error.c. This
cause the libGLU.so doesn't work at runtime because it doesn't find
these functions called by error.c (which are local to glue.c).

So, the fix is pretty simple: just remove the static keyword for these
two functions in glue.c

Again, since I have no write access to the CVS, I hope someone could do
it for me.

Moreover I had to hack the glu.h problem by hand.

Thanks,

-Olivier

Re: [Mesa3d-dev] glReadPixels

[Steve B. <st...@li...>]

On Mon, 3 Jul 2000, Michael Vance wrote:

> Yep, it's in the blue book. Create texture of width and height with
> unspecified contents. Mesa sticks a big old piece of 'MESA' text in it
> :)
 
Boring!  It should have been Brian Paul's cat/dog/kid!

   :-)


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

Re: [Mesa3d-dev] glReadPixels

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

On Mon, Jul 03, 2000 at 11:56:13AM -0500, Steve Baker wrote:

> glTexImage2D explicitly allows NULL textures - that's legal in OpenGL
> and has a very specific meaning - glReadPixels does not.

Yep, looked this up after sending my message (/me hits myself)...

> I actually quoted that from an SGI 'man' page - I don't have the Blue Book
> to hand - but I bet it's there.  If it's not, I apologise in advance - but

Yep, it's in the blue book. Create texture of width and height with
unspecified contents. Mesa sticks a big old piece of 'MESA' text in it
:)

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] glReadPixels

[Steve B. <st...@li...>]

On Mon, 3 Jul 2000, Michael Vance wrote:

> On Mon, Jul 03, 2000 at 08:14:57AM -0500, Stephen J Baker wrote:
> 
> > Since passing NULL to glReadPixels is illegal, you are lucky (perhaps)
> > not to get a core dump.  The effect of passing garbage pointers to OpenGL
> 
> This begs a question or two:
> 
> 1) why does Mesa not barf on NULL textures to glTexImage2D()?
> 
> ... Looking at the source it seems this is allowed.
 
glTexImage2D explicitly allows NULL textures - that's legal in OpenGL
and has a very specific meaning - glReadPixels does not.

> 2) where does the spec spell out when NULL pointers should or should
> not generate errors

For example, for glTexImage2D:

  "In GL version 1.1 or greater, pixels may be a null pointer.  In this case
   texture memory is allocated to accommodate a texture of width width and
   height height.  You can then download subtextures to initialize this
   texture memory."

...there is no such indication under glReadPixels - so you are just expected
to pass a valid pointer.

> Daniel and I looked in the Red and Blue books, and the Spec, but
> didn't see anything, offhand.

I actually quoted that from an SGI 'man' page - I don't have the Blue Book
to hand - but I bet it's there.  If it's not, I apologise in advance - but
that *is* the reason.

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

Re: [Mesa3d-dev] glReadPixels

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

On Mon, Jul 03, 2000 at 08:14:57AM -0500, Stephen J Baker wrote:

> Since passing NULL to glReadPixels is illegal, you are lucky (perhaps)
> not to get a core dump.  The effect of passing garbage pointers to OpenGL

This begs a question or two:

1) why does Mesa not barf on NULL textures to glTexImage2D()?

... Looking at the source it seems this is allowed.

2) where does the spec spell out when NULL pointers should or should
not generate errors

Daniel and I looked in the Red and Blue books, and the Spec, but
didn't see anything, offhand.

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] glReadPixels

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

On Sat, 1 Jul 2000, Daniel Vogel wrote:

> Allen Akin wrote:
> > 
> > I guess the bottom line is that the implementation *is* free to
> > generate errors under conditions not mandated by the spec, but it
> > would be dangerous for apps to depend on it.  A nice compromise is to
> 
> I was actually thinking the other way round - the app depending on no
> errors to be generated ;-) 
 
I agree that a LEGAL program should be able to depend on no
errors being generated - but passing NULL to glReadPixels isn't 
legal - so your program has a bug in it - and hence is not able
to rely on *anything*.

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

Re: [Mesa3d-dev] glReadPixels

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

On Fri, 30 Jun 2000, Daniel Vogel wrote:

> neither the specs nor the blue book mentions creating a GL_INVALID_VALUE
> when you pass NULL to glReadPixels - is it legal for Mesa to generate an
> error in this case? I am wondering how much I can assume about error
> checking, like can an implementation generate errors for things not
> covered by the specs?
 
Since passing NULL to glReadPixels is illegal, you are lucky (perhaps)
not to get a core dump.  The effect of passing garbage pointers to OpenGL
is undefined - and returning a nicely checked error return is an acceptable
response in an undefined situation.

Erasing all files starting with the letter 'q', painting the screen
purple with little blue polkadots or printing "Wibble, wibble, wibble" to
stdout are also acceptable behaviors in this situation....you got lucky!

   :-)

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

Re: [Mesa3d-dev] glReadPixels

[Daniel V. <vo...@lo...>]

Allen Akin wrote:
> 
> I guess the bottom line is that the implementation *is* free to
> generate errors under conditions not mandated by the spec, but it
> would be dangerous for apps to depend on it.  A nice compromise is to

I was actually thinking the other way round - the app depending on no
errors to be generated ;-) 

-- 
Daniel Vogel
Programmer
Loki Entertainment Software

Re: [Mesa3d-dev] Compiling error

[Hayden J. <hj...@st...>]

The latest cvs compiles fine now with the --with-glide option :)

On Sat, 1 Jul 2000, Sven M. Hallberg wrote:

> On Fri, Jun 30, 2000 at 11:44:46PM -0400, Hayden James wrote:
> > yes thanks it seems that I had glide3 installed for some reason but it is
> > removed now and I get further along in the compile but I get another
> > problem using the same configure options...
> > 
> > make[4]: Entering directory `/usr/src/Mesa-3.3/src/FX'
> > /bin/sh ../../libtool --mode=link gcc  -g -O2 -Wall -fomit-frame-pointer
> > -ffast-math -fexpensive-optimizations -malign-loops=2 -malign-jumps=2
> > -malign-functions=2 -D_REENTRANT  -o libMesaFX.la   fxapi.lo fxcva.lo
> > fxclip.lo fxdd.lo fxddspan.lo fxddtex.lo fxglidew.lo fxfastpath.lo
> > fxpipeline.lo fxrender.lo fxsanity.lo fxsetup.lo fxtexman.lo fxtrifuncs.lo
> > fxvsetup.lo fxwgl.lo -Lyes/lib -lglide2x 
> > ../../libtool: yes/lib: No such file or directory
> > libtool: link: cannot determine absolute directory name of `yes/lib'
> > make[4]: *** [libMesaFX.la] Error 1
> > make[4]: Leaving directory `/usr/src/Mesa-3.3/src/FX'
> > make[3]: *** [all-recursive] Error 1
> > make[3]: Leaving directory `/usr/src/Mesa-3.3/src/FX'
> > make[2]: *** [all-recursive] Error 1
> > make[2]: Leaving directory `/usr/src/Mesa-3.3/src'
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory `/usr/src/Mesa-3.3'
> > make: *** [all-recursive-am] Error 2
> 
> Oh, this was a bug in the configure script. I've corrected it and commited the
> fix into CVS.
> 
> 
> Hope this helps,
> Sven
> 
> -- 
> "Would the All-Seeing Eye please look in my direction?"
>  [ KeyID........: 0xC297FEAB ]
>  [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]
> 

Re: [Mesa3d-dev] Compiling error

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

On Fri, Jun 30, 2000 at 11:44:46PM -0400, Hayden James wrote:
> yes thanks it seems that I had glide3 installed for some reason but it is
> removed now and I get further along in the compile but I get another
> problem using the same configure options...
> 
> make[4]: Entering directory `/usr/src/Mesa-3.3/src/FX'
> /bin/sh ../../libtool --mode=link gcc  -g -O2 -Wall -fomit-frame-pointer
> -ffast-math -fexpensive-optimizations -malign-loops=2 -malign-jumps=2
> -malign-functions=2 -D_REENTRANT  -o libMesaFX.la   fxapi.lo fxcva.lo
> fxclip.lo fxdd.lo fxddspan.lo fxddtex.lo fxglidew.lo fxfastpath.lo
> fxpipeline.lo fxrender.lo fxsanity.lo fxsetup.lo fxtexman.lo fxtrifuncs.lo
> fxvsetup.lo fxwgl.lo -Lyes/lib -lglide2x 
> ../../libtool: yes/lib: No such file or directory
> libtool: link: cannot determine absolute directory name of `yes/lib'
> make[4]: *** [libMesaFX.la] Error 1
> make[4]: Leaving directory `/usr/src/Mesa-3.3/src/FX'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory `/usr/src/Mesa-3.3/src/FX'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/usr/src/Mesa-3.3/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/usr/src/Mesa-3.3'
> make: *** [all-recursive-am] Error 2

Oh, this was a bug in the configure script. I've corrected it and commited the
fix into CVS.


Hope this helps,
Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

Re: [Mesa3d-dev] Compiling error

[Hayden J. <hj...@st...>]

yes thanks it seems that I had glide3 installed for some reason but it is
removed now and I get further along in the compile but I get another
problem using the same configure options...

make[4]: Entering directory `/usr/src/Mesa-3.3/src/FX'
/bin/sh ../../libtool --mode=link gcc  -g -O2 -Wall -fomit-frame-pointer
-ffast-math -fexpensive-optimizations -malign-loops=2 -malign-jumps=2
-malign-functions=2 -D_REENTRANT  -o libMesaFX.la   fxapi.lo fxcva.lo
fxclip.lo fxdd.lo fxddspan.lo fxddtex.lo fxglidew.lo fxfastpath.lo
fxpipeline.lo fxrender.lo fxsanity.lo fxsetup.lo fxtexman.lo fxtrifuncs.lo
fxvsetup.lo fxwgl.lo -Lyes/lib -lglide2x 
../../libtool: yes/lib: No such file or directory
libtool: link: cannot determine absolute directory name of `yes/lib'
make[4]: *** [libMesaFX.la] Error 1
make[4]: Leaving directory `/usr/src/Mesa-3.3/src/FX'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/src/Mesa-3.3/src/FX'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/Mesa-3.3/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/Mesa-3.3'
make: *** [all-recursive-am] Error 2


On Fri, 30 Jun 2000, Sven M. Hallberg wrote:

> On Fri, Jun 30, 2000 at 02:47:10AM -0400, Hayden James wrote:
> > I have attached a list of compiling errors I got with latest cvs of Mesa
> > 3.3 compiled with ./configure --enable-sse --with-glide.  I am using the
> > Glide 2 headers.
> > 
> [...]
> > gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../src -Iyes/include/glide -g -O2 -Wall -fomit-frame-pointer -ffast-math -fexpensive-optimizations -malign-loops=2 -malign-jumps=2 -malign-functions=2 -D_REENTRANT -Wp,-MD,.deps/fxapi.pp -c fxapi.c  -fPIC -DPIC -o fxapi.lo
> > In file included from fxdrv.h:80,
> >                  from fxapi.c:624:
> > fxglidew.h:89: warning: `GR_ASPECT_1x1' redefined
> > /usr/include/glide.h:213: warning: this is the location of the previous definition
> > fxglidew.h:90: warning: `GR_ASPECT_2x1' redefined
> > /usr/include/glide.h:212: warning: this is the location of the previous definition
> ...
> 
> These symbols should only be defined in fxglidew.h if you have Glide 3. Maybe
> you're using the Glide 2 headers but have a libglide3 or libglide3x lying
> around? If the configure script finds it it assumes you also have Glide 3
> headers.
> 
> If you have a Glide 3 library you should temporarily rename it, delete the
> configure cache (config.cache), and rerun ./configure
> 
> Maybe seperate --with-glide3 --with-glide2 switches should be added to the
> configure script?
> 
> 
> Hope this helps,
> Sven
> 
> -- 
> "Would the All-Seeing Eye please look in my direction?"
>  [ KeyID........: 0xC297FEAB ]
>  [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]
> 

Re: [Mesa3d-dev] glReadPixels

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

On Fri, Jun 30, 2000 at 10:47:53AM -0700, Daryll Strauss wrote:

> that did things like debugging checks or recorded what operations where
> being performed for later playback. You could even think of using it to

Bernd has done this by creating his own library gllog, that maintains
its own OpenGL entry points and then has a variety of command
logging, state saving/restoring, etc., etc. features. He's planning to
contribute it to Mesa when he's done with it.

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] glReadPixels

[Daryll S. <da...@va...>]

On Fri, Jun 30, 2000 at 10:41:57AM -0700, Allen Akin wrote:
> I guess the bottom line is that the implementation *is* free to
> generate errors under conditions not mandated by the spec, but it
> would be dangerous for apps to depend on it.  A nice compromise is to
> use an OpenGL debugger to check for things like NULL pointers in
> inappropriate places, but I don't know if one of the existing *NIX or
> Win32 debuggers has been ported to Linux yet.  That would be a good
> open-source project.

Given the pluggable architecture of the DRI, it should be possible to
add a layer between the normal dispatch and the true OpenGL function
that did things like debugging checks or recorded what operations where
being performed for later playback. You could even think of using it to
analyze your OpenGL code and determine where you're being inefficient.

Those would be very useful contributions!

						- |Daryll

Re: [Mesa3d-dev] glReadPixels

[Allen A. <ak...@po...>]

On Fri, Jun 30, 2000 at 10:06:08AM -0700, Daniel Vogel wrote:
| 
| neither the specs nor the blue book mentions creating a GL_INVALID_VALUE
| when you pass NULL to glReadPixels ...

In most cases OpenGL doesn't check pointers for validity.  For
example, the spec doesn't require an implementation to generate an
error if the app calls glVertex3fv(NULL), or if the argument pointer
has incorrect alignment for the type of data it's supposed to
reference, or if it points to memory with insufficient access
permissions, etc.

There are some cases where pointers will be checked -- in the case of
glReadPixels, I imagine the pointer and destination image memory would
be checked thoroughly if the driver decides to use DMA for
transferring the image.  But as far as I know, the OpenGL spec doesn't
say what should happen in such cases, because they're too
system-dependent or even data-dependent.

|                                  ... is it legal for Mesa to generate an
| error in this case? I am wondering how much I can assume about error
| checking, like can an implementation generate errors for things not
| covered by the specs?

Some implementations do generate errors for conditions that aren't
mentioned in the spec, but in my experience, that's usually a strategy
of desperation.  For example, suppose there's a known bug in the
hardware, and the driver chooses to generate an error rather than fall
back to software rendering.  The rendering will be incorrect, but the
error gives the app developer a clue as to what caused the problem,
and he can then consult the release notes for the driver to understand
the situation.

I guess the bottom line is that the implementation *is* free to
generate errors under conditions not mandated by the spec, but it
would be dangerous for apps to depend on it.  A nice compromise is to
use an OpenGL debugger to check for things like NULL pointers in
inappropriate places, but I don't know if one of the existing *NIX or
Win32 debuggers has been ported to Linux yet.  That would be a good
open-source project.

Allen

[Mesa3d-dev] glReadPixels

[Daniel V. <vo...@lo...>]

hi`

neither the specs nor the blue book mentions creating a GL_INVALID_VALUE
when you pass NULL to glReadPixels - is it legal for Mesa to generate an
error in this case? I am wondering how much I can assume about error
checking, like can an implementation generate errors for things not
covered by the specs?

-- 
Daniel Vogel
Programmer
Loki Entertainment Software

[Mesa3d-dev] Re: [ogl-sample] SGI SI GLU integration

[Olivier M. <Oli...@cy...>]

Brian Paul wrote:
> 
> Olivier Michel wrote:
> >
> > Thanks to Brian, I checked out and build the lastest CVS version.
> > It turns out that the GLU library is now properly built so that C++
> > symbols are now defined (i.e., I could like libGLU.so with simple C
> > programs).
> >
> > However, except for the problems with the glu.h include file which are
> > not yet fixed in the CVS, I discovered another problem that didn't exist
> > in the tarball version:
> >
> > libGLU.so needs a couple of symbols that belongs to SGI libGL.so (I
> > guess) and are not present in Mesa libGL.so. These symbols are:
> >
> > __glNURBSErrorString and __glTessErrorString
> >
> > They are used at the end of main/gfx/lib/glu/libutil/error.c and defined
> > as external in gluint.h (in the same directory as error.c)
> >
> > I guess GLU should not assume that such symbols are defined in libGL.so
> > and I think that the corresponding functions should be moved from SGI GL
> > into SGI GLU -> __gluNURBSErrorString and __gluTessErrorString
> >
> > I had to comment out these two calls to get SGI libGLU.so link with Mesa
> > libGL.so
> 
> Have you determined exactly how/why these two functions are used?
> 
> libGLU shouldn't use any internal libGL functions, in principle.
> But in practice, I'm not too surprised by this.  In the worst case,
> I could add those funcs to Mesa (but I'd rather not).

Ok, I found the problem:

Despite their strange names, I was wrong saying that these symbols were
belonging to core GL. I finally found them in glu/libutil/glue.c. They
were not found at run time because the GLU library is build without the
-fpic option. I recompiled the glue.c and error.c files by hand simply
adding the -fpic option to gcc and it worked fine. Symbols are not
anymore missing at runtime.

However, since I have no write access to ogl-sample CVS, I cannot commit
anything to fix this. I guess this is pretty simple to fix (just add
-fpic for Linux compilation in the main/root/usr/include/make/commondefs
which is included by all GNUmakefile).

Anyone with write access to CVS could fix this ?

Thanks,

-Olivier

[Mesa3d-dev] Re: [ogl-sample] SGI SI GLU integration

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

Olivier Michel wrote:
> 
> Thanks to Brian, I checked out and build the lastest CVS version.
> It turns out that the GLU library is now properly built so that C++
> symbols are now defined (i.e., I could like libGLU.so with simple C
> programs).
> 
> However, except for the problems with the glu.h include file which are
> not yet fixed in the CVS, I discovered another problem that didn't exist
> in the tarball version:
> 
> libGLU.so needs a couple of symbols that belongs to SGI libGL.so (I
> guess) and are not present in Mesa libGL.so. These symbols are:
> 
> __glNURBSErrorString and __glTessErrorString
> 
> They are used at the end of main/gfx/lib/glu/libutil/error.c and defined
> as external in gluint.h (in the same directory as error.c)
> 
> I guess GLU should not assume that such symbols are defined in libGL.so
> and I think that the corresponding functions should be moved from SGI GL
> into SGI GLU -> __gluNURBSErrorString and __gluTessErrorString
> 
> I had to comment out these two calls to get SGI libGLU.so link with Mesa
> libGL.so

Have you determined exactly how/why these two functions are used?

libGLU shouldn't use any internal libGL functions, in principle.
But in practice, I'm not too surprised by this.  In the worst case,
I could add those funcs to Mesa (but I'd rather not).


> We are getting closer...

Yup.  Thanks for doing this!

-Brian

Re: [Mesa3d-dev] Compiling error

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

On Fri, Jun 30, 2000 at 02:47:10AM -0400, Hayden James wrote:
> I have attached a list of compiling errors I got with latest cvs of Mesa
> 3.3 compiled with ./configure --enable-sse --with-glide.  I am using the
> Glide 2 headers.
> 
[...]
> gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../src -Iyes/include/glide -g -O2 -Wall -fomit-frame-pointer -ffast-math -fexpensive-optimizations -malign-loops=2 -malign-jumps=2 -malign-functions=2 -D_REENTRANT -Wp,-MD,.deps/fxapi.pp -c fxapi.c  -fPIC -DPIC -o fxapi.lo
> In file included from fxdrv.h:80,
>                  from fxapi.c:624:
> fxglidew.h:89: warning: `GR_ASPECT_1x1' redefined
> /usr/include/glide.h:213: warning: this is the location of the previous definition
> fxglidew.h:90: warning: `GR_ASPECT_2x1' redefined
> /usr/include/glide.h:212: warning: this is the location of the previous definition
...

These symbols should only be defined in fxglidew.h if you have Glide 3. Maybe
you're using the Glide 2 headers but have a libglide3 or libglide3x lying
around? If the configure script finds it it assumes you also have Glide 3
headers.

If you have a Glide 3 library you should temporarily rename it, delete the
configure cache (config.cache), and rerun ./configure

Maybe seperate --with-glide3 --with-glide2 switches should be added to the
configure script?


Hope this helps,
Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

[Mesa3d-dev] Re: [ogl-sample] SGI SI GLU integration

[Olivier M. <Oli...@cy...>]

Thanks to Brian, I checked out and build the lastest CVS version.
It turns out that the GLU library is now properly built so that C++
symbols are now defined (i.e., I could like libGLU.so with simple C
programs).

However, except for the problems with the glu.h include file which are
not yet fixed in the CVS, I discovered another problem that didn't exist
in the tarball version:

libGLU.so needs a couple of symbols that belongs to SGI libGL.so (I
guess) and are not present in Mesa libGL.so. These symbols are:

__glNURBSErrorString and __glTessErrorString

They are used at the end of main/gfx/lib/glu/libutil/error.c and defined
as external in gluint.h (in the same directory as error.c)

I guess GLU should not assume that such symbols are defined in libGL.so
and I think that the corresponding functions should be moved from SGI GL
into SGI GLU -> __gluNURBSErrorString and __gluTessErrorString

I had to comment out these two calls to get SGI libGLU.so link with Mesa
libGL.so

We are getting closer...

-Olivier

[Mesa3d-dev] Compiling error

[Hayden J. <hj...@st...>]

I have attached a list of compiling errors I got with latest cvs of Mesa
3.3 compiled with ./configure --enable-sse --with-glide.  I am using the
Glide 2 headers.

Is it something I am doing wrong?


Hayden A. James

[Mesa3d-dev] Mesa Begginer

[Witcomb <wi...@ho...>]

I do know OpenGL and I want to start doing some Mesa in Linux.  I am
just looking for some documentation to tell me the the difference
between Mesa and OpenGL ( features and implementation ).

Thanks
Neil Witcomb
wi...@ho...

Re: [Mesa3d-dev] libMesaGLw vs. libGLw: which is preferred

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

"James A. Treacy" wrote:
> 
> Debian has (mostly) converted to using lib{GL,GLU} from libMesa{GL,GLU}
> for the library names. Is it recommended that we also drop Mesa from
> the names of the mesa widgets, GLw and GLwM?

Yes.

-Brian

PS: You should be aware of http://oss.sgi.com/projects/ogl-sample/ABI/