mesa3d-dev

Re: [Mesa3d-dev] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile 4.1 on RedHat 6.2)

[Marcelo E. M. <mar...@bi...>]

>> Brian Paul <br...@va...> writes:

 > If anyone knows a solution to this I'd like to hear it.

 Sometime ago I submitted a patch for this (#403332).  The comment
 reads:

 | If the use of KATMAI instructions is enabled, on linux it's necessary
 | to have recent kernel headers installed (these are coupled to the C
 | library, so suggesting to place/change a link in /usr/src/ is not
 | advisable). There are two options for it's detection at compile time,
 | one is using LINUX_KERNEL_VERSION, what this patch does, the other is
 | checking for X86_FXSR_MAGIC to be defined. I'm sure Gareth can make a
 | recommendation as to which is better. With either of them, I think
 | it's important to provide the user with an error that at least
 | suggests a course of action (the current one goes along the lines of
 | "magic is not a member of structure sigcontext", IIRC)

 | The patch uses 2.4.0 as a reference point, I'm not really sure when
 | the SSE support was introduced in the kernel, but it's not on the
 | 2.2.18 I looked at.

 The patch, which is not on SF (weird) is basically:

Index: extras/Mesa/src/X86/common_x86.c
===================================================================
RCS file: /cvsroot/dri/xc/xc/extras/Mesa/src/X86/common_x86.c,v
retrieving revision 1.10
diff -u -r1.10 common_x86.c
--- extras/Mesa/src/X86/common_x86.c    2001/02/12 20:42:42     1.10
+++ extras/Mesa/src/X86/common_x86.c    2001/06/05 15:22:50
@@ -88,6 +88,11 @@
 extern void gl_test_os_katmai_exception_support( void );
 
 #if defined(__linux__) && defined(_POSIX_SOURCE)
+#include <linux/version.h>
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
+#error "linux headers older than 2.4.0 don't provide support for SSE."
+#endif
+
 static void sigill_handler( int signal, struct sigcontext sc )
 {
    message( "SIGILL, " );

 Granted, it's not the best solution, but it's at least an useful error.
 Some conditionals on the configuration files would do it, too.
 (HAVE_LINUX_2_4_HEADERS, Imakefile style).  The point is, you need 2.4
 kernel headers to compile this.

-- 
Marcelo

[Mesa3d-dev] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile 4.1 on RedHat 6.2)

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

Chaskiel M Grundman wrote:
> 
> Around line 90 of xc/extras/Mesa/src/X86/common_x86.c
> #if defined(__linux__) && defined(_POSIX_SOURCE)
> [...]
> static void sigfpe_handler( int signal, struct sigcontext sc )
> {
>    message( "SIGFPE, " );
> 
>    if ( sc.fpstate->magic != 0xffff ) {
> 
> fpstate.magic is not defined in asm/sigcontext.h on my RedHat 6.2 box
> (which has a stock 2.2.19 kernel, not the redhat one). It is defined in
> the linux 2.4.5 asm/sigcontext.h, and I'm assuming the reason this is
> working for most people is that glibc 2.2's bits/sigcontext.h defines
> these things itself rather than deferring to the kernel headers.
> Something ought to be done about this, I think.
> 
> For my own purposes, I'm just going to disable SSE support entirely...


If anyone knows a solution to this I'd like to hear it.

-Brian

Re: [Mesa3d-dev] Re: Adding Mesa support for 3.3.6 to XFree86

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

"Mike A. Harris" wrote:
> 
> On Tue, 5 Jun 2001, Marcelo E. Magallon wrote:
> 
> > > For all of our XFree86 4.x releases, we have shipped XFree86 but
> > > have replaced the Mesa that comes with it with the standalone
> > > Mesa from the mesa3d project hacked to support DRI.
> > >
> > > The reason for this is that we need software OpenGL working on
> > > both 4.x and 3.3.6, and DRI hardware acceleration on 4.x.
> >
> > Hmmm... isn't this what Brian did?  Your problem is that the 3.3.6
> > server doesn't have the GLX extension.  The proper hack ;-) is to teach
> > the libGL in the XFree86 4 sources about fakeglx, and I'm under the
> > impression Brian did this.
> 
> Brian, can you comment on this?  If it is in fact true I'd like
> to discuss it a bit deeper so that I understand what is going on
> with it all.

I just implemented this last week (and am still making tweaks).
Basically, I've modified the libGL that's included with XFree86
so that it can render to displays which lack the GLX extension.

First, libGL checks if the given display supports the GLX extension.
If so, we use the usual GLX code to either send GLX protocol to
the server or use the DRI to do 3D rendering.

If the display does not have the GLX extension (ala XFree86 3.3.6)
then I fallback to Xlib-based software rendering (like stand-alone
Mesa).

"fakeglx", BTW, is an emulation of the GLX programming API which
uses ordinary Xlib calls.  "xmesa" is the actual Mesa device driver
for rendering via Xlib.

Another terminology note: "GLX" refers to three things: the X
server extension, the OpenGL wire protocol, and the X/OpenGL
programming API.

I've done this work in the DRI tree on the mesa-3-5-branch branch.
Currently, the Xlib software rendering code gets built into libGL.
Alternately, we could dynamically load the rendering code as a
module, like the DRI driver.  I'm afraid that the later might be
too error prone though.

A few more comments below...



> > > There were some oddball chicken and egg dependancy problems with
> > > this solution, and so we've decided instead of having a separate
> > > Mesa package, to take the Mesa package and fold it into the
> > > XFree86 src.rpm.
> >
> > ugh.
> 
> I agree.  I've successfully got it to build finally, but not
> without severely evil specfile hacks.
> 
> > > Here is what would IMHO be the best - at least from my viewpoint
> > > as a distributor/package maintainer:
> >
> > hi from one of the guys that has your job on the Debian side...
> 
> Hi.  ;o)
> 
> I don't know how Debian handles backwards compatibility with
> upgrades, etc.. but that is also part of the headache for me.
> Making sure nothing breaks with this.
> 
> > > The easiest method (for me) would be if the Mesa that comes with
> > > XFree86 had the 3.3.6 compatibility built right into it, and was
> > > perhaps an Imake directive to enable at X build time
> > > (BuildMesaSupport336?).  This would make our hack unnecessary,
> > > and would make package maintenance much simpler as well.  I'd
> > > much rather spend my time hacking on and contributing to XFree86
> > > itself than on packaging nightmares in unfamiliar turf...  ;o)
> >
> > Again, your problem is that Mesa in the XFree86 4 sources doesn't work
> > unless the Xserver knows about the GLX extension (IOW, you'll also have
> 
> Ok.
> 
> > a problem with an XF4 server that doesn't have the GLX module
> > installed).  Mesa works with 3.3.6 servers because it has a "fake" GLX
> > inside it, that is, it nevers sends GLX requests to the server, but it
> > handles all of that internally.
> 
> Ok, you're refering to standalone Mesa right?  Or the one
> included with XFree86?  I'm assuming the former.
> 
> > And again, I think Brian already did the necessary work...  (I haven't
> > really tested)
> 
> If that is true then what I am looking for above is already
> implemented?  Does Mesa 3.4.2 that comes with XFree86 4.1.0
> support OpenGL on 3.3.6 servers?  Brian?

No.  There wasn't time to implement this and do extensive testing
in time for XFree86 4.1.0.  I don't know which XFree86 release
will get this new libGL code.


> If so, I can completely eliminate the separate Mesa package and
> add a few more names to the people-to-buy-beer list.  ;o)

Unfortunatley, I think you'll still need it for a while.

Have you looked at the BuildGLXLibrary configuration variable?
I think that might disable building XFree86's libGL entirely.

-Brian

[Mesa3d-dev] Re: Adding Mesa support for 3.3.6 to XFree86

[Mike A. H. <mh...@re...>]

On Tue, 5 Jun 2001, Marcelo E. Magallon wrote:

> > For all of our XFree86 4.x releases, we have shipped XFree86 but
> > have replaced the Mesa that comes with it with the standalone
> > Mesa from the mesa3d project hacked to support DRI.
> >
> > The reason for this is that we need software OpenGL working on
> > both 4.x and 3.3.6, and DRI hardware acceleration on 4.x.
>
> Hmmm... isn't this what Brian did?  Your problem is that the 3.3.6
> server doesn't have the GLX extension.  The proper hack ;-) is to teach
> the libGL in the XFree86 4 sources about fakeglx, and I'm under the
> impression Brian did this.

Brian, can you comment on this?  If it is in fact true I'd like
to discuss it a bit deeper so that I understand what is going on
with it all.


> > There were some oddball chicken and egg dependancy problems with
> > this solution, and so we've decided instead of having a separate
> > Mesa package, to take the Mesa package and fold it into the
> > XFree86 src.rpm.
>
> ugh.

I agree.  I've successfully got it to build finally, but not
without severely evil specfile hacks.


> > Here is what would IMHO be the best - at least from my viewpoint
> > as a distributor/package maintainer:
>
> hi from one of the guys that has your job on the Debian side...

Hi.  ;o)

I don't know how Debian handles backwards compatibility with
upgrades, etc.. but that is also part of the headache for me.
Making sure nothing breaks with this.


> > The easiest method (for me) would be if the Mesa that comes with
> > XFree86 had the 3.3.6 compatibility built right into it, and was
> > perhaps an Imake directive to enable at X build time
> > (BuildMesaSupport336?).  This would make our hack unnecessary,
> > and would make package maintenance much simpler as well.  I'd
> > much rather spend my time hacking on and contributing to XFree86
> > itself than on packaging nightmares in unfamiliar turf...  ;o)
>
> Again, your problem is that Mesa in the XFree86 4 sources doesn't work
> unless the Xserver knows about the GLX extension (IOW, you'll also have

Ok.

> a problem with an XF4 server that doesn't have the GLX module
> installed).  Mesa works with 3.3.6 servers because it has a "fake" GLX
> inside it, that is, it nevers sends GLX requests to the server, but it
> handles all of that internally.

Ok, you're refering to standalone Mesa right?  Or the one
included with XFree86?  I'm assuming the former.


> And again, I think Brian already did the necessary work...  (I haven't
> really tested)

If that is true then what I am looking for above is already
implemented?  Does Mesa 3.4.2 that comes with XFree86 4.1.0
support OpenGL on 3.3.6 servers?  Brian?

If so, I can completely eliminate the separate Mesa package and
add a few more names to the people-to-buy-beer list.  ;o)



----------------------------------------------------------------------
Mike A. Harris                  Shipping/mailing address:
OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
Red Hat Inc.                    Ontario, Canada, P6C 5B3
http://www.redhat.com           Phone: (705)949-2136
----------------------------------------------------------------------
Latest XFree86 test RPMS:      ftp://people.redhat.com/mharris/testing

Re: [Mesa3d-dev] Adding Mesa support for 3.3.6 to XFree86

[Marcelo E. M. <mar...@bi...>]

>> "Mike A. Harris" <mh...@re...> writes:

 > For all of our XFree86 4.x releases, we have shipped XFree86 but
 > have replaced the Mesa that comes with it with the standalone
 > Mesa from the mesa3d project hacked to support DRI.
 > 
 > The reason for this is that we need software OpenGL working on
 > both 4.x and 3.3.6, and DRI hardware acceleration on 4.x.

 Hmmm... isn't this what Brian did?  Your problem is that the 3.3.6
 server doesn't have the GLX extension.  The proper hack ;-) is to teach
 the libGL in the XFree86 4 sources about fakeglx, and I'm under the
 impression Brian did this.

 > There were some oddball chicken and egg dependancy problems with
 > this solution, and so we've decided instead of having a separate
 > Mesa package, to take the Mesa package and fold it into the
 > XFree86 src.rpm.

 ugh.

 > Here is what would IMHO be the best - at least from my viewpoint
 > as a distributor/package maintainer:

 hi from one of the guys that has your job on the Debian side...

 > The easiest method (for me) would be if the Mesa that comes with
 > XFree86 had the 3.3.6 compatibility built right into it, and was
 > perhaps an Imake directive to enable at X build time
 > (BuildMesaSupport336?).  This would make our hack unnecessary,
 > and would make package maintenance much simpler as well.  I'd
 > much rather spend my time hacking on and contributing to XFree86
 > itself than on packaging nightmares in unfamiliar turf...  ;o)

 Again, your problem is that Mesa in the XFree86 4 sources doesn't work
 unless the Xserver knows about the GLX extension (IOW, you'll also have
 a problem with an XF4 server that doesn't have the GLX module
 installed).  Mesa works with 3.3.6 servers because it has a "fake" GLX
 inside it, that is, it nevers sends GLX requests to the server, but it
 handles all of that internally.

 And again, I think Brian already did the necessary work...  (I haven't
 really tested)

-- 
Marcelo

[Mesa3d-dev] Adding Mesa support for 3.3.6 to XFree86

[Mike A. H. <mh...@re...>]

I'm having some trouble with Mesa that I'm not sure how to
properly handle and would like some advice.

For all of our XFree86 4.x releases, we have shipped XFree86 but
have replaced the Mesa that comes with it with the standalone
Mesa from the mesa3d project hacked to support DRI.

The reason for this is that we need software OpenGL working on
both 4.x and 3.3.6, and DRI hardware acceleration on 4.x.

This 'hack' works well, however it is somewhat of a maintenance
nightmare, because portions of the DRI code that are needed must
be extracted from our XFree86 sources first then included in the
separate Mesa packaging.  Every time XFree needs updating, the
Mesa package thus needs updating as well to keep them in sync.

There were some oddball chicken and egg dependancy problems with
this solution, and so we've decided instead of having a separate
Mesa package, to take the Mesa package and fold it into the
XFree86 src.rpm.

I've got this part working now.  Mesa builds first, and then X,
but when it comes %install time in the specfile, the two Mesa's
step on each others toes and I'm not sure how to work around it
other than intense gross hacks - that are likely to be a
maintenance nightmare in their own regards.

Currently the relevant portions of the XFree spec look like:

%install
mkdir -p $RPM_BUILD_ROOT{/usr/{include,lib},/etc/{pam.d,security/console.apps}}
make DESTDIR=$RPM_BUILD_ROOT install install.man -C xc
# FIXME: Can MESA stuff be disabled with Imake instead?
# Clean out Mesa stuff
{
   rm -f  $RPM_BUILD_ROOT/usr/include/GL
   find   $RPM_BUILD_ROOT/usr/lib -type f |grep -vi "glide"|xargs rm -f
   rm -rf $RPM_BUILD_ROOT/usr/X11R6/include/GL
   rm -f  $RPM_BUILD_ROOT/usr/X11R6/lib/lib{GL,OSM}*
}


As such, I'd like to have opinions on how to solve this dilemna
from those who actually understand how Mesa works - I am no
OpenGL guy by far.

Here is what would IMHO be the best - at least from my viewpoint
as a distributor/package maintainer:

The easiest method (for me) would be if the Mesa that comes with
XFree86 had the 3.3.6 compatibility built right into it, and was
perhaps an Imake directive to enable at X build time
(BuildMesaSupport336?).  This would make our hack unnecessary,
and would make package maintenance much simpler as well.  I'd
much rather spend my time hacking on and contributing to XFree86
itself than on packaging nightmares in unfamiliar turf...  ;o)

Alternative to that, the second method would be if in XFree86
there were Imake directives HasMesa, UseMesa like with Freetype2,
and friends, and I could stop libGL, libOSMesa, etc from being
built, and from being installed in my buildroot.  That would
remove the need for that hack we have now that deletes these
libraries during the buildroot'd install phase in the src.rpm.

Another possibility would be for us to redo the Mesa stuff and
instead of patching standalone Mesa with parts of DRI from X, if
we were to patch Mesa in X with parts of the standalone Mesa.
Not something I am comfortable with attempting myself though.

There are likely other approaches also that would work, but as
I've just started with Mesa stuff, I have no idea what is
realistic from what I've said above, and what is not.

How difficult would it be for someone familiar with the Mesa and
X code to merge the needed bits for 3.3.6 support into XFree86
sources?

Thanks in advance for any suggestions/comments/flames or help
with this matter.

TTYL


----------------------------------------------------------------------
Mike A. Harris                  Shipping/mailing address:
OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
Red Hat Inc.                    Ontario, Canada, P6C 5B3
http://www.redhat.com           Phone: (705)949-2136
----------------------------------------------------------------------
Latest XFree86 test RPMS:      ftp://people.redhat.com/mharris/testing

[Mesa3d-dev] sourceforge tracker emails

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

FYI: I've setup the various Mesa project trackers (bug database,
patch database, etc) to send email to the mesa3d-dev list whenever
something new is submitted or whenever an item is changed.

-Brian

Re: [Mesa3d-dev] OSMesa16 UseSoftwareAlphaBuffers init problem

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

"J.P. Delport" wrote:
> 
> Hello,
> 
> I tried some polygon anti-aliasing with OSMesa16 (RGBA buffer like
> osdemo16) and all seemed OK with
> glBlendFunc(GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA), but with
> glBlendFunc(GL_SRC_ALPHA_SATURATE,GL_ONE) the blending went berzerk. I
> found that mesa was reading back the wrong frame buffer alpha values
> with _mesa_read_rgba_span in swrast/s_span.c
> 
> inside _mesa_read_rgba_span: (*swrast->Driver.ReadRGBASpan) reads the
> correct r,g,b,a values, but then
> "if (buffer->UseSoftwareAlphaBuffers)" evaluates true and
> _mesa_read_alpha_span buggers the alpha values.
> 
> I saw in osmesa.c inside OSMesaCreateContextExt that there is a value
> "swalpha" set to GL_FALSE for RGBA buffers, but this value fails to make
> its way into osmesa->gl_buffer->UseSoftwareAlphaBuffers during the rest
> of the initialization. If during the init I manually set
> UseSoftwareAlphaBuffers to false, the blending looks OK and I think that
> the software uses a faster read function for the RGBA buffer in memory
> (havn't confirmed this yet).

I've just checked in a change to src/OSmesa/osmesa.c which should fix
this.  Please update your CVS tree and test.

Thanks for the bug report.

-Brian

[Mesa3d-dev] OSMesa16 UseSoftwareAlphaBuffers init problem

[J.P. D. <jpd...@cs...>]

Hello,

I tried some polygon anti-aliasing with OSMesa16 (RGBA buffer like
osdemo16) and all seemed OK with
glBlendFunc(GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA), but with
glBlendFunc(GL_SRC_ALPHA_SATURATE,GL_ONE) the blending went berzerk. I
found that mesa was reading back the wrong frame buffer alpha values
with _mesa_read_rgba_span in swrast/s_span.c

inside _mesa_read_rgba_span: (*swrast->Driver.ReadRGBASpan) reads the
correct r,g,b,a values, but then
"if (buffer->UseSoftwareAlphaBuffers)" evaluates true and
_mesa_read_alpha_span buggers the alpha values.

I saw in osmesa.c inside OSMesaCreateContextExt that there is a value
"swalpha" set to GL_FALSE for RGBA buffers, but this value fails to make
its way into osmesa->gl_buffer->UseSoftwareAlphaBuffers during the rest
of the initialization. If during the init I manually set
UseSoftwareAlphaBuffers to false, the blending looks OK and I think that
the software uses a faster read function for the RGBA buffer in memory
(havn't confirmed this yet).

cheers
jp

Re: [Mesa3d-dev] Debugging OSmesa16

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

"J.P. Delport" wrote:
> 
> The garbled triangle is fixed if I change GLubyte to GLchan in
> s_aatritemp.h (around line 68) like so:
> 
> #ifdef DO_RGBA
>    GLfloat rPlane[4], gPlane[4], bPlane[4], aPlane[4];
>    DEFMARRAY(GLchan, rgba, MAX_WIDTH, 4);  /* mac 32k limitation */
> #endif
>
> I don't know if this is completely right as I'm still learning the code.
> Thanks for the debugging tips, I can step around now.

Yup, that'll do it.  I think we were using GLchan before I applied
that Macintosh patch.  I'll check in the fix ASAP.

-Brian

Re: [Mesa3d-dev] Debugging OSmesa16

[J.P. D. <jpd...@cs...>]

The garbled triangle is fixed if I change GLubyte to GLchan in
s_aatritemp.h (around line 68) like so:

#ifdef DO_RGBA
   GLfloat rPlane[4], gPlane[4], bPlane[4], aPlane[4];
   DEFMARRAY(GLchan, rgba, MAX_WIDTH, 4);  /* mac 32k limitation */
#endif

I don't know if this is completely right as I'm still learning the code.
Thanks for the debugging tips, I can step around now.

cheers
jp

Brian Paul wrote:
> 
> "J.P. Delport" wrote:
> >
> > Hi,
> >
> > I've started experimenting with the OSmesa16 library on linux and wrote
> > a simple program based on osdemo16 that draws a single smooth shaded
> > triangle. I've managed to import the off-screen 16-bit data into Matlab
> > to do some checks. The program works fine without
> > glEnable(GL_SMOOTH_POLYGON), but with it gives a garbled triangle.
> 
> I'll look into this.
> 
> > I
> > would like to familiarise myself with the OSmesa16 code and trace the
> > origin of the error, but I need some pointers on debugging the lib. I'm
> > using ddd with gdb and when setting breakpoints e.g. in
> > swrast/s_triangle.c gdb complains:
> > Error in re-setting breakpoint 1:
> > No source file named swrast/s_triangle.c.
> >
> > I've tried using the gdb dir command to add source search dirs with no
> > success.
> >
> > gdb> info shar gives:
> > >From        To          Syms Read   Shared Object Library
> > 0x40015000  0x4002fe30  Yes         /home/jpdelport/Mesa/lib/libGLU.so.1
> > 0x40030000  0x40388fc4  Yes
> > /home/jpdelport/Mesa/lib/libOSMesa16.so.1
> > 0x4038e000  0x403aa9d8  Yes         /lib/libm.so.6
> > 0x403ab000  0x403bd138  Yes         /lib/libpthread.so.0
> > 0x403bf000  0x404b385c  Yes         /lib/libc.so.6
> > 0x40000000  0x40013ed0  Yes         /lib/ld-linux.so.2
> >
> > I compiled (from a CVS checkout on 28/05) libOSMesa16 with: make -f
> > Makefile.X11 linux-osmesa16
> > and compiled libGLU by going to src-glu and doing: make -f Makefile.X11
> > linux-debug
> >
> > Any pointers to what I'm doing wrong or how I'm supposed to set up an
> > OSmesa debugging session would be appreciated.
> 
> First, be sure to recompile the sources with -g and without -O.  Edit
> Make-config, look for 'linux-osmesa16'.
> 
> If you're debugging a dynamic library you can't set breakpoints in the
> library code until execution has begun.  Try setting a breakpoint in
> main(), run to that point, then set a breakpoint in the Mesa function
> you're interested in.
> 
> -Brian

Re: [Mesa3d-dev] Debugging OSmesa16

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

"J.P. Delport" wrote:
> 
> Hi,
> 
> I've started experimenting with the OSmesa16 library on linux and wrote
> a simple program based on osdemo16 that draws a single smooth shaded
> triangle. I've managed to import the off-screen 16-bit data into Matlab
> to do some checks. The program works fine without
> glEnable(GL_SMOOTH_POLYGON), but with it gives a garbled triangle.

I'll look into this.


> I
> would like to familiarise myself with the OSmesa16 code and trace the
> origin of the error, but I need some pointers on debugging the lib. I'm
> using ddd with gdb and when setting breakpoints e.g. in
> swrast/s_triangle.c gdb complains:
> Error in re-setting breakpoint 1:
> No source file named swrast/s_triangle.c.
> 
> I've tried using the gdb dir command to add source search dirs with no
> success.
> 
> gdb> info shar gives:
> >From        To          Syms Read   Shared Object Library
> 0x40015000  0x4002fe30  Yes         /home/jpdelport/Mesa/lib/libGLU.so.1
> 0x40030000  0x40388fc4  Yes
> /home/jpdelport/Mesa/lib/libOSMesa16.so.1
> 0x4038e000  0x403aa9d8  Yes         /lib/libm.so.6
> 0x403ab000  0x403bd138  Yes         /lib/libpthread.so.0
> 0x403bf000  0x404b385c  Yes         /lib/libc.so.6
> 0x40000000  0x40013ed0  Yes         /lib/ld-linux.so.2
> 
> I compiled (from a CVS checkout on 28/05) libOSMesa16 with: make -f
> Makefile.X11 linux-osmesa16
> and compiled libGLU by going to src-glu and doing: make -f Makefile.X11
> linux-debug
> 
> Any pointers to what I'm doing wrong or how I'm supposed to set up an
> OSmesa debugging session would be appreciated.

First, be sure to recompile the sources with -g and without -O.  Edit
Make-config, look for 'linux-osmesa16'.

If you're debugging a dynamic library you can't set breakpoints in the
library code until execution has begun.  Try setting a breakpoint in
main(), run to that point, then set a breakpoint in the Mesa function
you're interested in.

-Brian

[Mesa3d-dev] Debugging OSmesa16

[J.P. D. <jpd...@cs...>]

Hi,

I've started experimenting with the OSmesa16 library on linux and wrote
a simple program based on osdemo16 that draws a single smooth shaded
triangle. I've managed to import the off-screen 16-bit data into Matlab
to do some checks. The program works fine without
glEnable(GL_SMOOTH_POLYGON), but with it gives a garbled triangle. I
would like to familiarise myself with the OSmesa16 code and trace the
origin of the error, but I need some pointers on debugging the lib. I'm
using ddd with gdb and when setting breakpoints e.g. in
swrast/s_triangle.c gdb complains:
Error in re-setting breakpoint 1:
No source file named swrast/s_triangle.c.

I've tried using the gdb dir command to add source search dirs with no
success.

gdb> info shar gives:
From        To          Syms Read   Shared Object Library
0x40015000  0x4002fe30  Yes         /home/jpdelport/Mesa/lib/libGLU.so.1
0x40030000  0x40388fc4  Yes        
/home/jpdelport/Mesa/lib/libOSMesa16.so.1
0x4038e000  0x403aa9d8  Yes         /lib/libm.so.6
0x403ab000  0x403bd138  Yes         /lib/libpthread.so.0
0x403bf000  0x404b385c  Yes         /lib/libc.so.6
0x40000000  0x40013ed0  Yes         /lib/ld-linux.so.2

I compiled (from a CVS checkout on 28/05) libOSMesa16 with: make -f
Makefile.X11 linux-osmesa16
and compiled libGLU by going to src-glu and doing: make -f Makefile.X11
linux-debug

Any pointers to what I'm doing wrong or how I'm supposed to set up an
OSmesa debugging session would be appreciated.

thanks
jp

Re: [Mesa3d-dev] Re: New automake and autoconf are out!

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

On Wed, May 23, 2001 at 10:51:22AM -0600, Brian Paul wrote:
> "Sven M. Hallberg" wrote:
> > > Those undefined functions are part of the SGIX_video_resize extension.
> > > They're referenced in src-glut/glut_vidresize.c.  Mesa has stubs for
> > > these functions so I don't know why you're getting 'undefined reference'.
> > 
> > Strange, this works fine for me, too. However, in my compilation command, the
> > order of the libraries is different, namely libGL.so comes before any others.
> > Maybe that's the cause.
> 
> I wonder if Dieter has another older libGL somewhere on his system
> that doesn't have the video_resize functions.  If that libGL is
> getting picked up instead of the local version that could explain
> things.

Could be...


> > > Personally, compilation is failing for me on demos/osdemo because
> > > it's not getting linked with libOSMesa.so:
> > >
> > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include  -I../util  -I./src/X86  -g -O2 -Wall
> > > -fomit-frame-pointer -ffast-math -fexpensive-optimizations -fstrict-aliasing
> > > -malign-loops=2 -malign-jumps=2 -malign-functions=2 -D_REENTRANT -DPTHREADS -c osdemo.c
> > > osdemo.c:179: warning: `write_ppm' defined but not used
> > > /bin/sh ../libtool --mode=link gcc  -g -O2 -Wall -fomit-frame-pointer -ffast-math
> > > -fexpensive-optimizations -fstrict-aliasing -malign-loops=2 -malign-jumps=2
> > > -malign-functions=2 -D_REENTRANT -DPTHREADS  -o osdemo  osdemo.o ../si-glu/libGLU.la
> > > -lglut  ../src/libGL.la -lm
> > > gcc -g -O2 -Wall -fomit-frame-pointer -ffast-math -fexpensive-optimizations
> > > -fstrict-aliasing -malign-loops=2 -malign-jumps=2 -malign-functions=2 -D_REENTRANT
> > > -DPTHREADS -o .libs/osdemo osdemo.o ../si-glu/.libs/libGLU.so -L../src -lGL -lglut
> > > ../src/.libs/libGL.so -L/usr/X11R6/lib -lSM -lICE -lXmu -lXext -lXi -lX11 -lpthread -lm
> > > -Wl,--rpath -Wl,/tmp/Mesa/lib
> > > osdemo.o: In function `main':
> > > /home/brian/5/demos/osdemo.c:231: undefined reference to `OSMesaCreateContextExt'
> > > /home/brian/5/demos/osdemo.c:248: undefined reference to `OSMesaMakeCurrent'
> > > /home/brian/5/demos/osdemo.c:277: undefined reference to `OSMesaDestroyContext'
> > > collect2: ld returned 1 exit status
> > 
> > Hm.. src/OSMesa/Makefile.am builds a convenience library, not a shared one.
> > Should this be different?
> 
> What's a convenience library?
> 
> There should be a libOSMesa.so library.  Using the Makefile.X11
> process, I'm making a libOSMesa.so.3.5.030500
> 
> The reason for this new, separate library has to do with XFree86.
> The XFree86 libGL knows nothing about the OSMesa interface.  Instead,
> the OSMesa interface (and renderer) are a separate library.  I want
> to do the same thing with stand-alone Mesa for consistancy.

OIC, a "libtool convenience library" is a static library which is not to be
installed but only used within a package.

The Makefile.am's don't reflect what you say, yet. I'll change it anytime.
Just tell me, what version-info do I use, now??

-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] Re: New automake and autoconf are out!

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

"Sven M. Hallberg" wrote:
> 
> On Wed, May 23, 2001 at 09:40:49AM -0600, Brian Paul wrote:
> > > mkdir .libs
> > > gcc -O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
> > > -fschedule-insns2 -fexpensive-optimizations -Wall -fomit-frame-pointer
> > > -ffast-math -fexpensive-optimizations -fstrict-aliasing -malign-loops=2
> > > -malign-jumps=2 -malign-functions=2 -D_REENTRANT -DPTHREADS -o .libs/aaindex
> > > aaindex.o ../src-glut/.libs/libglut.so -L../si-glu -L/usr/X11R6/lib -lSM
> > > -lICE -lXmu -lXext -lXi -lX11 ../si-glu/.libs/libGLU.so -L../src -lGL
> > > ../src/.libs/libGL.so -lSM -lICE -lXmu -lXext -lXi -lX11 -lpthread -lm
> > > -Wl,--rpath -Wl,/opt/Mesa/lib
> > > ../src-glut/.libs/libglut.so: undefined reference to
> > > `glXBindChannelToWindowSGIX'
> > > ../src-glut/.libs/libglut.so: undefined reference to
> > > `glXCreateContextWithConfigSGIX'
> > > ../src-glut/.libs/libglut.so: undefined reference to
> > > `glXGetFBConfigAttribSGIX'
> > > ../src-glut/.libs/libglut.so: undefined reference to
> > > `glXQueryChannelDeltasSGIX'../src-glut/.libs/libglut.so: undefined reference
> > > to `glXChannelRectSyncSGIX'
> > > ../src-glut/.libs/libglut.so: undefined reference to `glXChannelRectSGIX'
> > > ../src-glut/.libs/libglut.so: undefined reference to `glXQueryChannelRectSGIX'
> > > ../src-glut/.libs/libglut.so: undefined reference to
> > > `glXGetFBConfigFromVisualSGIX'
> > > collect2: ld returned 1 exit status
> > > make[2]: *** [aaindex] Error 1
> > > make[2]: Leaving directory `/opt/Mesa/book'
> > > make[1]: *** [check-am] Error 2
> > > make[1]: Leaving directory `/opt/Mesa/book'
> > > make: *** [check-recursive] Error 1
> >
> > Those undefined functions are part of the SGIX_video_resize extension.
> > They're referenced in src-glut/glut_vidresize.c.  Mesa has stubs for
> > these functions so I don't know why you're getting 'undefined reference'.
> 
> Strange, this works fine for me, too. However, in my compilation command, the
> order of the libraries is different, namely libGL.so comes before any others.
> Maybe that's the cause.

I wonder if Dieter has another older libGL somewhere on his system
that doesn't have the video_resize functions.  If that libGL is
getting picked up instead of the local version that could explain
things.


> > Personally, compilation is failing for me on demos/osdemo because
> > it's not getting linked with libOSMesa.so:
> >
> > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include  -I../util  -I./src/X86  -g -O2 -Wall
> > -fomit-frame-pointer -ffast-math -fexpensive-optimizations -fstrict-aliasing
> > -malign-loops=2 -malign-jumps=2 -malign-functions=2 -D_REENTRANT -DPTHREADS -c osdemo.c
> > osdemo.c:179: warning: `write_ppm' defined but not used
> > /bin/sh ../libtool --mode=link gcc  -g -O2 -Wall -fomit-frame-pointer -ffast-math
> > -fexpensive-optimizations -fstrict-aliasing -malign-loops=2 -malign-jumps=2
> > -malign-functions=2 -D_REENTRANT -DPTHREADS  -o osdemo  osdemo.o ../si-glu/libGLU.la
> > -lglut  ../src/libGL.la -lm
> > gcc -g -O2 -Wall -fomit-frame-pointer -ffast-math -fexpensive-optimizations
> > -fstrict-aliasing -malign-loops=2 -malign-jumps=2 -malign-functions=2 -D_REENTRANT
> > -DPTHREADS -o .libs/osdemo osdemo.o ../si-glu/.libs/libGLU.so -L../src -lGL -lglut
> > ../src/.libs/libGL.so -L/usr/X11R6/lib -lSM -lICE -lXmu -lXext -lXi -lX11 -lpthread -lm
> > -Wl,--rpath -Wl,/tmp/Mesa/lib
> > osdemo.o: In function `main':
> > /home/brian/5/demos/osdemo.c:231: undefined reference to `OSMesaCreateContextExt'
> > /home/brian/5/demos/osdemo.c:248: undefined reference to `OSMesaMakeCurrent'
> > /home/brian/5/demos/osdemo.c:277: undefined reference to `OSMesaDestroyContext'
> > collect2: ld returned 1 exit status
> 
> Hm.. src/OSMesa/Makefile.am builds a convenience library, not a shared one.
> Should this be different?

What's a convenience library?

There should be a libOSMesa.so library.  Using the Makefile.X11
process, I'm making a libOSMesa.so.3.5.030500

The reason for this new, separate library has to do with XFree86.
The XFree86 libGL knows nothing about the OSMesa interface.  Instead,
the OSMesa interface (and renderer) are a separate library.  I want
to do the same thing with stand-alone Mesa for consistancy.

-Brian

Re: [Mesa3d-dev] Re: New automake and autoconf are out!

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

On Wed, May 23, 2001 at 09:40:49AM -0600, Brian Paul wrote:
> > mkdir .libs
> > gcc -O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
> > -fschedule-insns2 -fexpensive-optimizations -Wall -fomit-frame-pointer
> > -ffast-math -fexpensive-optimizations -fstrict-aliasing -malign-loops=2
> > -malign-jumps=2 -malign-functions=2 -D_REENTRANT -DPTHREADS -o .libs/aaindex
> > aaindex.o ../src-glut/.libs/libglut.so -L../si-glu -L/usr/X11R6/lib -lSM
> > -lICE -lXmu -lXext -lXi -lX11 ../si-glu/.libs/libGLU.so -L../src -lGL
> > ../src/.libs/libGL.so -lSM -lICE -lXmu -lXext -lXi -lX11 -lpthread -lm
> > -Wl,--rpath -Wl,/opt/Mesa/lib
> > ../src-glut/.libs/libglut.so: undefined reference to
> > `glXBindChannelToWindowSGIX'
> > ../src-glut/.libs/libglut.so: undefined reference to
> > `glXCreateContextWithConfigSGIX'
> > ../src-glut/.libs/libglut.so: undefined reference to
> > `glXGetFBConfigAttribSGIX'
> > ../src-glut/.libs/libglut.so: undefined reference to
> > `glXQueryChannelDeltasSGIX'../src-glut/.libs/libglut.so: undefined reference
> > to `glXChannelRectSyncSGIX'
> > ../src-glut/.libs/libglut.so: undefined reference to `glXChannelRectSGIX'
> > ../src-glut/.libs/libglut.so: undefined reference to `glXQueryChannelRectSGIX'
> > ../src-glut/.libs/libglut.so: undefined reference to
> > `glXGetFBConfigFromVisualSGIX'
> > collect2: ld returned 1 exit status
> > make[2]: *** [aaindex] Error 1
> > make[2]: Leaving directory `/opt/Mesa/book'
> > make[1]: *** [check-am] Error 2
> > make[1]: Leaving directory `/opt/Mesa/book'
> > make: *** [check-recursive] Error 1
> 
> Those undefined functions are part of the SGIX_video_resize extension.
> They're referenced in src-glut/glut_vidresize.c.  Mesa has stubs for
> these functions so I don't know why you're getting 'undefined reference'.

Strange, this works fine for me, too. However, in my compilation command, the
order of the libraries is different, namely libGL.so comes before any others.
Maybe that's the cause.


> Personally, compilation is failing for me on demos/osdemo because
> it's not getting linked with libOSMesa.so:
> 
> gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include  -I../util  -I./src/X86  -g -O2 -Wall
> -fomit-frame-pointer -ffast-math -fexpensive-optimizations -fstrict-aliasing
> -malign-loops=2 -malign-jumps=2 -malign-functions=2 -D_REENTRANT -DPTHREADS -c osdemo.c
> osdemo.c:179: warning: `write_ppm' defined but not used
> /bin/sh ../libtool --mode=link gcc  -g -O2 -Wall -fomit-frame-pointer -ffast-math
> -fexpensive-optimizations -fstrict-aliasing -malign-loops=2 -malign-jumps=2
> -malign-functions=2 -D_REENTRANT -DPTHREADS  -o osdemo  osdemo.o ../si-glu/libGLU.la     
> -lglut  ../src/libGL.la -lm 
> gcc -g -O2 -Wall -fomit-frame-pointer -ffast-math -fexpensive-optimizations
> -fstrict-aliasing -malign-loops=2 -malign-jumps=2 -malign-functions=2 -D_REENTRANT
> -DPTHREADS -o .libs/osdemo osdemo.o ../si-glu/.libs/libGLU.so -L../src -lGL -lglut
> ../src/.libs/libGL.so -L/usr/X11R6/lib -lSM -lICE -lXmu -lXext -lXi -lX11 -lpthread -lm
> -Wl,--rpath -Wl,/tmp/Mesa/lib
> osdemo.o: In function `main':
> /home/brian/5/demos/osdemo.c:231: undefined reference to `OSMesaCreateContextExt'
> /home/brian/5/demos/osdemo.c:248: undefined reference to `OSMesaMakeCurrent'
> /home/brian/5/demos/osdemo.c:277: undefined reference to `OSMesaDestroyContext'
> collect2: ld returned 1 exit status

Hm.. src/OSMesa/Makefile.am builds a convenience library, not a shared one.
Should this be different?

-- 
"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] Re: New automake and autoconf are out!

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

Dieter Nützel wrote:
> 
> > Woohoo! (See subject)
> >
> > My last apt-get upgrade left me with the following versions:
> > autoconf (GNU Autoconf) 2.50
> > automake (GNU automake) 1.4-p1
> > ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18)
> 
> O.K. I'll try that.
> 
> But I get a compilation error with
> ./configure --prefix=/opt/Mesa --without-svga --without-pic
> --enable-fast-install (--without-glide)
> "make check"
> 
> "make -f Makefile.X11 linux-x86" is fine
> 
> -Dieter
> 
> [-]
> mkdir .libs
> gcc -O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
> -fschedule-insns2 -fexpensive-optimizations -Wall -fomit-frame-pointer
> -ffast-math -fexpensive-optimizations -fstrict-aliasing -malign-loops=2
> -malign-jumps=2 -malign-functions=2 -D_REENTRANT -DPTHREADS -o .libs/aaindex
> aaindex.o ../src-glut/.libs/libglut.so -L../si-glu -L/usr/X11R6/lib -lSM
> -lICE -lXmu -lXext -lXi -lX11 ../si-glu/.libs/libGLU.so -L../src -lGL
> ../src/.libs/libGL.so -lSM -lICE -lXmu -lXext -lXi -lX11 -lpthread -lm
> -Wl,--rpath -Wl,/opt/Mesa/lib
> ../src-glut/.libs/libglut.so: undefined reference to
> `glXBindChannelToWindowSGIX'
> ../src-glut/.libs/libglut.so: undefined reference to
> `glXCreateContextWithConfigSGIX'
> ../src-glut/.libs/libglut.so: undefined reference to
> `glXGetFBConfigAttribSGIX'
> ../src-glut/.libs/libglut.so: undefined reference to
> `glXQueryChannelDeltasSGIX'../src-glut/.libs/libglut.so: undefined reference
> to `glXChannelRectSyncSGIX'
> ../src-glut/.libs/libglut.so: undefined reference to `glXChannelRectSGIX'
> ../src-glut/.libs/libglut.so: undefined reference to `glXQueryChannelRectSGIX'
> ../src-glut/.libs/libglut.so: undefined reference to
> `glXGetFBConfigFromVisualSGIX'
> collect2: ld returned 1 exit status
> make[2]: *** [aaindex] Error 1
> make[2]: Leaving directory `/opt/Mesa/book'
> make[1]: *** [check-am] Error 2
> make[1]: Leaving directory `/opt/Mesa/book'
> make: *** [check-recursive] Error 1

Those undefined functions are part of the SGIX_video_resize extension.
They're referenced in src-glut/glut_vidresize.c.  Mesa has stubs for
these functions so I don't know why you're getting 'undefined reference'.

Personally, compilation is failing for me on demos/osdemo because
it's not getting linked with libOSMesa.so:

gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include  -I../util  -I./src/X86  -g -O2 -Wall
-fomit-frame-pointer -ffast-math -fexpensive-optimizations -fstrict-aliasing
-malign-loops=2 -malign-jumps=2 -malign-functions=2 -D_REENTRANT -DPTHREADS -c osdemo.c
osdemo.c:179: warning: `write_ppm' defined but not used
/bin/sh ../libtool --mode=link gcc  -g -O2 -Wall -fomit-frame-pointer -ffast-math
-fexpensive-optimizations -fstrict-aliasing -malign-loops=2 -malign-jumps=2
-malign-functions=2 -D_REENTRANT -DPTHREADS  -o osdemo  osdemo.o ../si-glu/libGLU.la     
-lglut  ../src/libGL.la -lm 
gcc -g -O2 -Wall -fomit-frame-pointer -ffast-math -fexpensive-optimizations
-fstrict-aliasing -malign-loops=2 -malign-jumps=2 -malign-functions=2 -D_REENTRANT
-DPTHREADS -o .libs/osdemo osdemo.o ../si-glu/.libs/libGLU.so -L../src -lGL -lglut
../src/.libs/libGL.so -L/usr/X11R6/lib -lSM -lICE -lXmu -lXext -lXi -lX11 -lpthread -lm
-Wl,--rpath -Wl,/tmp/Mesa/lib
osdemo.o: In function `main':
/home/brian/5/demos/osdemo.c:231: undefined reference to `OSMesaCreateContextExt'
/home/brian/5/demos/osdemo.c:248: undefined reference to `OSMesaMakeCurrent'
/home/brian/5/demos/osdemo.c:277: undefined reference to `OSMesaDestroyContext'
collect2: ld returned 1 exit status


-Brian

[Mesa3d-dev] Re: New automake and autoconf are out!

[Dieter <Die...@ha...>]

> Woohoo! (See subject)
>
> My last apt-get upgrade left me with the following versions:
> autoconf (GNU Autoconf) 2.50
> automake (GNU automake) 1.4-p1
> ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18)

O.K. I'll try that.

But I get a compilation error with
./configure --prefix=/opt/Mesa --without-svga --without-pic 
--enable-fast-install (--without-glide)
"make check"

"make -f Makefile.X11 linux-x86" is fine

-Dieter

[-]
mkdir .libs
gcc -O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4 
-fschedule-insns2 -fexpensive-optimizations -Wall -fomit-frame-pointer 
-ffast-math -fexpensive-optimizations -fstrict-aliasing -malign-loops=2 
-malign-jumps=2 -malign-functions=2 -D_REENTRANT -DPTHREADS -o .libs/aaindex 
aaindex.o ../src-glut/.libs/libglut.so -L../si-glu -L/usr/X11R6/lib -lSM 
-lICE -lXmu -lXext -lXi -lX11 ../si-glu/.libs/libGLU.so -L../src -lGL 
../src/.libs/libGL.so -lSM -lICE -lXmu -lXext -lXi -lX11 -lpthread -lm 
-Wl,--rpath -Wl,/opt/Mesa/lib
../src-glut/.libs/libglut.so: undefined reference to 
`glXBindChannelToWindowSGIX'
../src-glut/.libs/libglut.so: undefined reference to 
`glXCreateContextWithConfigSGIX'
../src-glut/.libs/libglut.so: undefined reference to 
`glXGetFBConfigAttribSGIX'
../src-glut/.libs/libglut.so: undefined reference to 
`glXQueryChannelDeltasSGIX'../src-glut/.libs/libglut.so: undefined reference 
to `glXChannelRectSyncSGIX'
../src-glut/.libs/libglut.so: undefined reference to `glXChannelRectSGIX'
../src-glut/.libs/libglut.so: undefined reference to `glXQueryChannelRectSGIX'
../src-glut/.libs/libglut.so: undefined reference to 
`glXGetFBConfigFromVisualSGIX'
collect2: ld returned 1 exit status
make[2]: *** [aaindex] Error 1
make[2]: Leaving directory `/opt/Mesa/book'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/opt/Mesa/book'
make: *** [check-recursive] Error 1

[Mesa3d-dev] New automake and autoconf are out!

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

Woohoo! (See subject)

My last apt-get upgrade left me with the following versions:
  autoconf (GNU Autoconf) 2.50
  automake (GNU automake) 1.4-p1
  ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18)

I'm requesting we officially use them. On my system everything worked perfect.
In fact automake now no longer complains about a missing ltconfig script when
libtool 1.4 is used. On the same note, is there a specific reason for
distributing m4/libtool.m4?

Also the new autoconf generates _much_ prettier help output. I've actually
used their CVS version here on my machine all along.


Regards,
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] libtool (was CVS and SSE)

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

On Tue, May 22, 2001 at 09:19:53PM +0200, Marcelo E. Magallon wrote:
> >> "Sven M. Hallberg" <pe...@gm...> writes:
> 
>  > OK. So we let libtool do its work and (constructively) interfere with
>  > it only where the necessity pops up, right?
> 
>  Yes, I guess that's the safest solution.

Alright. Brian, is this OK with you?


>  > >  Like I said, what's important is the SONAME contained in the library,
>  > >  what this file is called is not important.  Like this:
>  > 
>  > Really?? I thought it was like this:
>  >  SONAME of library X = Y.
>  >  compile executable Z with -lX
>  >   -> linker puts SONAME(X)=Y to NEEDED(Z)
>  >  execute Z
>  >   -> linker looks up library of _name_ Y.
>  >      If lib Y doesn't exist, linker fails.
>  > 
>  > Is it different?
> 
>  No, it's like that.  I meant that you have to check that the SONAME is
>  set right and that there's a link SONAME(lib) ->
>  whatever_libtool_called_it (e.g. libGL.so.1 -> libGL.1.2.350) and
>  another one PUBLIC_NAME(lib) -> whatever_libtool_called_it (e.g.,
>  libGL.so -> libGL.1.2.350)

Right. Since we can't influence the SONAME directly, we don't have any other
option than to check whether libtool did what we wanted and issue an error
message otherwise.


>  > libGL already gets these dependencies from the various convenience libs.
>  > Can anyone see whether there are any missing? Since I built the si-glu
>  > Makefile.am's I'll just add -lGL there, right?
> 
>  Funny that it doesn't list libstdc++, but appart from libGL, no, it
>  doesn't need anything else ...

I don't think GLU uses the STL.


>  > Ugh. Do you have any indication why that fails? Maybe it doesn't like
>  > the high REVISION number?
> 
>  Libtool tries to pass something like 'sgi350.0:sgi349.0:...:sgi2.0:sgi1.0'
>  to the linker, and the linker doesn't seem to like that and terminates
>  with a bus error...

Did you try it with a lower revision number? What does a "bus error" mean
exactly, do you know? I don't.


Regards,
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] libtool (was CVS and SSE)

[Marcelo E. M. <mar...@bi...>]

>> "Sven M. Hallberg" <pe...@gm...> writes:

 > OK. So we let libtool do its work and (constructively) interfere with
 > it only where the necessity pops up, right?

 Yes, I guess that's the safest solution.
 
 > >  Like I said, what's important is the SONAME contained in the library,
 > >  what this file is called is not important.  Like this:
 > 
 > Really?? I thought it was like this:
 >  SONAME of library X = Y.
 >  compile executable Z with -lX
 >   -> linker puts SONAME(X)=Y to NEEDED(Z)
 >  execute Z
 >   -> linker looks up library of _name_ Y.
 >      If lib Y doesn't exist, linker fails.
 > 
 > Is it different?

 No, it's like that.  I meant that you have to check that the SONAME is
 set right and that there's a link SONAME(lib) ->
 whatever_libtool_called_it (e.g. libGL.so.1 -> libGL.1.2.350) and
 another one PUBLIC_NAME(lib) -> whatever_libtool_called_it (e.g.,
 libGL.so -> libGL.1.2.350)
 
 > libGL already gets these dependencies from the various convenience libs.
 > Can anyone see whether there are any missing? Since I built the si-glu
 > Makefile.am's I'll just add -lGL there, right?

 Funny that it doesn't list libstdc++, but appart from libGL, no, it
 doesn't need anything else ...

 > Ugh. Do you have any indication why that fails? Maybe it doesn't like
 > the high REVISION number?

 Libtool tries to pass something like 'sgi350.0:sgi349.0:...:sgi2.0:sgi1.0'
 to the linker, and the linker doesn't seem to like that and terminates
 with a bus error...

-- 
Marcelo

Re: [Mesa3d-dev] libtool (was CVS and SSE)

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

On Tue, May 22, 2001 at 01:12:39PM +0200, Marcelo E. Magallon wrote:
> >> "Sven M. Hallberg" <pe...@gm...> writes:
> 
>  > Then, if we don't know the correct filename (except in special cases
>  > where there is something like an ABI) we can let libtool decide.
>  > After all it's its job! If we stumble across a system with an ABI we
>  > might be violating, we can still incorporate a special-case
>  > treatment.
> 
>  Yes.  My guess is that each (Unix-like) vendor has (an|their own) ABI
>  for OpenGL.  Linux just happens to have one that's used by more than
>  one group.  A quick look arround here indicates that HP-UX's libGL is
>  called libGL.2, IRIX's seems to be called libGL.so with a "MIPS
>  version" of "sgi1.0" (I have never understood SGI's policy regarding
>  SONAMEs, but I've never seen it break, so I guess it's ok).  The other
>  Unix flavors I have access to don't have the vendor's libGL installed
>  on them. 

OK. So we let libtool do its work and (constructively) interfere with it only
where the necessity pops up, right?


>  > Here's the pseudo-code for the install-hook, do you think this would
>  > be OK to do on systems identified as Linux?
> 
>  Hmmm...  the whole ABI bussiness is about the soname *in* the library
>  file.  libtool happyly ignores any -Wl,-soname,libfoo.so.1 you pass to
>  it (because it's not portable).

Oh, I'll try it, too.


>  >         if test `find .libs/ -name libGL.so.1 | grep -c libGL.so.1` != 1; then
>  if there's exactly one file named libGL.so.1 ...
If there's not exactly one.
>  >           libfile=`find .libs/* -not -type l -not -name '*.lai'`
>  look for the library files ... (note there are likely two of these, one
>  libGL.so.x.y.z and one libGL.a -- you *want* the libGL.a, too)
Oh, right. Maybe we should just scrap this whole thing, assuming libtool does
it right.
>  >           if test 'echo $libfile | grep -c $libfile` = 1; then
>  I got lost here.  If there's exactly one shared library?
Oh, this is of course bull. echo $libfile | grep -c '*' = 1 would be correct.
Basically meant as a line count (Is wc -l portable?).
>  >             ln -s @libdir@/$libfile @libdir@/libGL.so.1
>  link libGL.so.1 to this
>  >           else
>  else there's a problem.


>  Like I said, what's important is the SONAME contained in the library,
>  what this file is called is not important.  Like this:

Really?? I thought it was like this:
 SONAME of library X = Y.
 compile executable Z with -lX
  -> linker puts SONAME(X)=Y to NEEDED(Z)
 execute Z
  -> linker looks up library of _name_ Y.
     If lib Y doesn't exist, linker fails.

Is it different?


>  soname=`readelf -d $libfile | sed -ne '/SONAME/ s/.*\[\(.*\)\]/\1/p'`
>  if test $soname != libGL.so.1
>      echo There's a problem ...
>      exit 1
>  else
>      # Asuming libfile is something like libGL.so.1.2.350 (and not
>      # /some/dir/.libs/libGL.so.1.2.350)
>      ln -s $libfile @libdir@/libGL.so.1
>  fi
> 
>  (objdump and readelf are both part of binutils, so on Linux it's safe
>  to asume they are present.  I just happen to like readelf better)

OK.


>  > So you mean, we should include the library depedencies in our library
>  > objects?
> 
>  If possible, yes.  It makes life much simpler.  :-)

Hm. look at this:
--- 8< ---
pesco@crest:~/cvswork/Mesa/src/.libs$ ldd libGL.so
        libvga.so.1 => /usr/lib/libvga.so.1 (0x401de000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40235000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4023e000)
        libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40254000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40269000)
        libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40278000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40280000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x4035b000)
        libc.so.6 => /lib/libc.so.6 (0x40371000)
        libm.so.6 => /lib/libm.so.6 (0x40483000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x404a5000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)
pesco@crest:~/cvswork/Mesa/si-glu/.libs$ ldd libGLU.so
        libc.so.6 => /lib/libc.so.6 (0x400b5000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)
--- >8 ---

libGL already gets these dependencies from the various convenience libs.
Can anyone see whether there are any missing? Since I built the si-glu
Makefile.am's I'll just add -lGL there, right?


>  BTW, I tried -version-info 3:350:2 on IRIX...  not good... the linker
>  exits with a bus error.  Gotta love the MIPSpro tool chain...

Ugh. Do you have any indication why that fails? Maybe it doesn't like the high
REVISION number?


Greetings,
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] Linux-x86 FAST_MATH macros in mmath.h

[Gareth H. <ga...@va...>]

Gareth Hughes wrote:
> 
> After discussions with Brian and Josh, I'm adding an fnclex instruction
> to the END_FAST_MATH macro to clear any FP exceptions that may have
> occurred in the FAST_MATH block.  It seems pointless to have a
> GCC-specific END_FAST_MATH, when I can convert the entire block to
> inline assembly and get rid of the _FPU_SET* checks etc.
> 
> Do people have strong objections to this?  I'm essentially adding GCC as
> a requirement to enable the fast math stuff, but with our change in
> policy regarding FP exceptions this seems reasonable -- and we can
> always add non-GCC code for other Linux-x86 targets as required.

I've changed the linux/x86 requirement to GCC/x86, which will allow
other OSes running on x86 that compile Mesa with GCC to benefit from the
FAST_MATH code (perhaps the *BSDs?).  Nice and clean, in any case.

-- Gareth

Re: [Mesa3d-dev] libtool (was CVS and SSE)

[Marcelo E. M. <mar...@bi...>]

>> "Sven M. Hallberg" <pe...@gm...> writes:

 > Then, if we don't know the correct filename (except in special cases
 > where there is something like an ABI) we can let libtool decide.
 > After all it's its job! If we stumble across a system with an ABI we
 > might be violating, we can still incorporate a special-case
 > treatment.

 Yes.  My guess is that each (Unix-like) vendor has (an|their own) ABI
 for OpenGL.  Linux just happens to have one that's used by more than
 one group.  A quick look arround here indicates that HP-UX's libGL is
 called libGL.2, IRIX's seems to be called libGL.so with a "MIPS
 version" of "sgi1.0" (I have never understood SGI's policy regarding
 SONAMEs, but I've never seen it break, so I guess it's ok).  The other
 Unix flavors I have access to don't have the vendor's libGL installed
 on them. 

 > Here's the pseudo-code for the install-hook, do you think this would
 > be OK to do on systems identified as Linux?

 Hmmm...  the whole ABI bussiness is about the soname *in* the library
 file.  libtool happyly ignores any -Wl,-soname,libfoo.so.1 you pass to
 it (because it's not portable).

 >         if test `find .libs/ -name libGL.so.1 | grep -c libGL.so.1` != 1; then
 if there's exactly one file named libGL.so.1 ...
 >           libfile=`find .libs/* -not -type l -not -name '*.lai'`
 look for the library files ... (note there are likely two of these, one
 libGL.so.x.y.z and one libGL.a -- you *want* the libGL.a, too)
 >           if test 'echo $libfile | grep -c $libfile` = 1; then
 I got lost here.  If there's exactly one shared library?
 >             ln -s @libdir@/$libfile @libdir@/libGL.so.1
 link libGL.so.1 to this
 >           else
 else there's a problem.

 Like I said, what's important is the SONAME contained in the library,
 what this file is called is not important.  Like this:

 soname=`readelf -d $libfile | sed -ne '/SONAME/ s/.*\[\(.*\)\]/\1/p'`
 if test $soname != libGL.so.1
     echo There's a problem ...
     exit 1
 else
     # Asuming libfile is something like libGL.so.1.2.350 (and not
     # /some/dir/.libs/libGL.so.1.2.350)
     ln -s $libfile @libdir@/libGL.so.1
 fi

 (objdump and readelf are both part of binutils, so on Linux it's safe
 to asume they are present.  I just happen to like readelf better)

 > So you mean, we should include the library depedencies in our library
 > objects?

 If possible, yes.  It makes life much simpler.  :-)

 BTW, I tried -version-info 3:350:2 on IRIX...  not good... the linker
 exits with a bus error.  Gotta love the MIPSpro tool chain...

-- 
Marcelo

Re: [Mesa3d-dev] Re: libtool (was CVS and SSE)

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

On Mon, May 21, 2001 at 11:41:40PM +0200, Marcelo E. Magallon wrote:
> >> Brian Paul <br...@va...> writes:
> 
>  > I'm curious why revision 30500 doesn't work.  Do you know if the revision
>  > is stored as a number or a string?  I'd at least ask the libtool people why
>  > 30500 doesn't work.
> 
>  because libtool defines non negative as:
> 
>     0 | [1-9] | [1-9][0-9] | [1-9][0-9][0-9]
> 
>  i.e., it not only can't start with 0, it can only have three digits.  I
>  suspect this has to do with some funny test or expr implementation.  Or
>  perhaps they thought three digits would be enough.  Or maybe some sick
>  linker uses integers to store this info.
>  
>  Hmm... funky that '0 | [1-9]' bit...

I'd suspect this was quickly hacked in (explaining the superfluous 0) so they
probably did limit to three digits because they thought it would suffice.

-Sven

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