mesa3d-dev

Re: [Mesa3d-dev] Segmentation Fault in shade_rastpos

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

On Thu, Jul 05, 2001 at 09:43:52AM -0600, Brian Paul wrote:
> Allen Barnett wrote:
> >
> > And another question(s): How do you debug Mesa with GDB? I guess I don't
> > understand how to get it to compile without optimization (a ./configure
> > option?) and if I have to build and link with a static archive library
> > instead of a shared object? Any tips would be helpful.
> 
> I always use the old-style Makefiles when debugging/developing.  Try this:
> 
> cd src
> make -f Makefile.X11 clean
> make -f Makefile.X11 linux-debug

Try:
    $ configure --enable-debug
That should add -O0 to CFLAGS if you're using GCC. If you're using a different
compiler, tell me which flag you need for debugging code, and I'll add it.

-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] Hardcopy Output Driver

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

>> Allen Barnett <ba...@lo...> writes:

 > Has anybody ever built a hardcopy output driver for Mesa which (more or
 > less) retained the detailed geometry of the original primitives (as
 > opposed to just taking a screen snapshot)?

 There are a couple of tools that do more or less this.  Look for gl2ps
 using google.

-- 
Marcelo

Re: [Mesa3d-dev] Segmentation Fault in shade_rastpos

[Allen B. <ba...@lo...>]

Brian Paul wrote:
> 
> Allen Barnett wrote:
> >
> > Hi,
> >
> > I'm getting a segmentation fault in the Mesa function shade_rastpos()
> > when lighting is turned on and if no other drawing precedes a call to
> > RasterPos2i(). Attached is a sample program which demonstrates the
> > problem. I'm using Mesa 3.5.1 on RedHat 7.1/i386.
> 
> Hmmm, your test program runs fine here.  Can you get a stack trace
> with your debugger?

Sorry, I pressed the send button before I reverted the attached code to
its failure mode in my original message. Did you test it with the quad
drawing commented out as below?

> void display ( void )
> {
> #if 0
>  glBegin( GL_QUADS );
>  glVertex2i( 0, 0 );
>  glVertex2i( 50, 0 );
>  glVertex2i( 50, 50 );
>  glVertex2i( 0, 50 );
>  glEnd();
> #endif
> 
>  glRasterPos2i( 0, 0 );
> }

The output from the debugger is below.

And another question(s): How do you debug Mesa with GDB? I guess I don't
understand how to get it to compile without optimization (a ./configure
option?) and if I have to build and link with a static archive library
instead of a shared object? Any tips would be helpful.

Thanks,
Allen

GNU gdb 5.0rh-5 Red Hat Linux 7.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) r
Starting program: /home/allen/lignumCAD/OGLFT/try7
[New Thread 1024 (LWP 25135)]
 
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 1024 (LWP 25135)]
0x4023916b in _mesa_test_os_sse_exception_support ()
   from /usr/local/lib/libGL.so.1
(gdb) c
Continuing.
Brian Paul Mesa X11 1.2 Mesa 3.5
 
Program received signal SIGSEGV, Segmentation fault.
0x40119526 in shade_rastpos (ctx=0xbffff928, vertex=0x403b3177,
normal=0x1,
    Rcolor=0xbffff954, Rspec=0xbffff95c, Rindex=0x804869e) at
rastpos.c:228
228                 GET_SHINE_TAB_ENTRY( ctx->_ShineTable[0], n_dot_h,
spec_coef );
(gdb) where
#0  0x40119526 in shade_rastpos (ctx=0xbffff928, vertex=0x403b3177,
    normal=0x1, Rcolor=0xbffff954, Rspec=0xbffff95c, Rindex=0x804869e)
    at rastpos.c:228
#1  0x00000007 in ?? ()
#2  0x4002b763 in processWindowWorkList (window=0xbfffff27)
    at glut_event.c:1297
#3  0x403b3177 in __libc_start_main (main=0x8048998 <main>, argc=1,
    ubp_av=0xbffff954, init=0x8048688 <_init>, fini=0x8048ab0 <_fini>,
    rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff94c)
    at ../sysdeps/generic/libc-start.c:129
(gdb) l
223                    n_dot_h *= n_dot_h;
224                    n_dot_h /= LEN_SQUARED_3FV( h );
225                    shininess *= .5;
226                 }
227
228                 GET_SHINE_TAB_ENTRY( ctx->_ShineTable[0], n_dot_h,
spec_coef );
229
230                 if (spec_coef > 1.0e-10) {
231                    if
(ctx->Light.Model.ColorControl==GL_SEPARATE_SPECULAR_COLOR) {
232                       ACC_SCALE_SCALAR_3V( specularContrib,
spec_coef,

[Mesa3d-dev] Hardcopy Output Driver

[Allen B. <ba...@lo...>]

Hi,

Has anybody ever built a hardcopy output driver for Mesa which (more or
less) retained the detailed geometry of the original primitives (as
opposed to just taking a screen snapshot)? For example, older versions
of the SGI Showcase program generated postscript commands which
corresponded directly to the transformed and lighted points, lines and
polygons in a scene; it even seemed to take care of depth sorting so
that 3D elements where drawn correctly. (It didn't support texture
mapping, though, which is probably why later versions of Showcase
generated raster images instead.)

I'd like to build something which works with StarOffice (or OpenOffice).
Currently, the only color vector drawing format which it can import is a
Windows Metafile (which is basically a 2D drawing format). You could
probably do something similar to the Showcase PostScript driver if you
weren't too picky about smooth shading and texture mapping.

Would this be a reasonable approach? Or would it be better to just
render in OSMesa at a high resolution and live with the raster image?

Thanks,
Allen

[Mesa3d-dev] [ mesa3d-Bugs-438798 ] No install directions

[<no...@so...>]

Bugs item #438798, was opened at 2001-07-05 08:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=438798&group_id=3

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: No install directions

Initial Comment:
Perhaps I'm blind, but I can't find any information on
how to
install mesa3d.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=438798&group_id=3

Re: [Mesa3d-dev] Segmentation Fault in shade_rastpos

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

Allen Barnett wrote:
> 
> Brian Paul wrote:
> >
> > Allen Barnett wrote:
> > >
> > > Hi,
> > >
> > > I'm getting a segmentation fault in the Mesa function shade_rastpos()
> > > when lighting is turned on and if no other drawing precedes a call to
> > > RasterPos2i(). Attached is a sample program which demonstrates the
> > > problem. I'm using Mesa 3.5.1 on RedHat 7.1/i386.
> >
> > Hmmm, your test program runs fine here.  Can you get a stack trace
> > with your debugger?
> 
> Sorry, I pressed the send button before I reverted the attached code to
> its failure mode in my original message. Did you test it with the quad
> drawing commented out as below?
> 
> > void display ( void )
> > {
> > #if 0
> >  glBegin( GL_QUADS );
> >  glVertex2i( 0, 0 );
> >  glVertex2i( 50, 0 );
> >  glVertex2i( 50, 50 );
> >  glVertex2i( 0, 50 );
> >  glEnd();
> > #endif
> >
> >  glRasterPos2i( 0, 0 );
> > }
> 
> The output from the debugger is below.

I've checked in a fix for this problem.  Here's the diff:

diff -r1.28 rastpos.c
133a134,136
>    if (!ctx->_ShineTable[0] || !ctx->_ShineTable[1])
>       _mesa_validate_all_lighting_tables( ctx );
> 


> And another question(s): How do you debug Mesa with GDB? I guess I don't
> understand how to get it to compile without optimization (a ./configure
> option?) and if I have to build and link with a static archive library
> instead of a shared object? Any tips would be helpful.

I always use the old-style Makefiles when debugging/developing.  Try this:

cd src
make -f Makefile.X11 clean
make -f Makefile.X11 linux-debug

When running with gdb and using a shared libGL.so, you can't set breakpoints
in the Mesa code until the program has begun executing.  To work around that,
first set a breakpoint in main(), then run.  When gdb stops in main() you
can then set breakpoints elsewhere in Mesa.

-Brian

Re: [Mesa3d-dev] Segmentation Fault in shade_rastpos

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

Allen Barnett wrote:
> 
> Hi,
> 
> I'm getting a segmentation fault in the Mesa function shade_rastpos()
> when lighting is turned on and if no other drawing precedes a call to
> RasterPos2i(). Attached is a sample program which demonstrates the
> problem. I'm using Mesa 3.5.1 on RedHat 7.1/i386.

Hmmm, your test program runs fine here.  Can you get a stack trace
with your debugger?


> BTW, GL_RASTER_POSITION_UNCLIPPED_IBM works great! Thank you.

You're welcome!

-Brain

[Mesa3d-dev] [ mesa3d-Bugs-438348 ] Clean CVS checkout fails to build.

[<no...@so...>]

Bugs item #438348, was opened at 2001-07-03 14:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=438348&group_id=3

Category: mesa-core
Group: Compile/Install
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Clean CVS checkout fails to build.

Initial Comment:
1) the bootstrap script fails because most automakes
want an argument "Makefile"

===================================================================
RCS file: /cvsroot/mesa3d/Mesa/bootstrap,v
retrieving revision 1.12
diff -u -r1.12 bootstrap
--- bootstrap   2001/06/26 14:11:45     1.12
+++ bootstrap   2001/07/03 20:43:45
@@ -20,7 +20,7 @@
 run_cmd libtoolize --automake --copy --force
 run_cmd aclocal
 run_cmd autoheader
-run_cmd automake -a -c
+run_cmd automake -a -c Makefile
 run_cmd autoconf
 
 exit 0


2) It is not entirely clear to a novice (me) that
automake-2.5 is actually  automake-2.50 and that the
automake-2.13 currently being distributed does not
support AC_CONFIG_FILES. (The 2.50 test in configure.in
catches this, but is it a bit of a struggle, the
tempation was to interpret the "0" as a typo, and
conclude that you meant 2.5 ..... an obsolete
automake!)


3) There are no instructions to build the Makfile.in's
in the sub directories so that AC_CONFIG_FILES can do
its stuff. One has to conclude that

foreach file ( `find . -name 'Makefile.am'` )
  automake -a -c `basname $file .am`
end

is the thing to do. Maybe the sh version of this
belongs in bootstrap.

4) Probably an autoconf bug, but the current autoconf
generated configure does not copy info like

 
# ### BEGIN LIBTOOL CONFIG
# Libtool was configured on host pcrod:
#
# CC="gcc" CFLAGS="-O2 -march=i386 -mcpu=i686"
CPPFLAGS="" \
# LD="/usr/bin/ld" LDFLAGS="" LIBS="" \
# NM="/usr/bin/nm -B" RANLIB="ranlib" LN_S="ln -s" \
# DLLTOOL="" OBJDUMP="" AS="" \
#   ./ltconfig --with-gcc --with-gnu-ld --enable-dlopen
--srcdir=. --output=libtool ./ltmain.sh
#
# Compiler and other test output produced by ltconfig,
useful for
# debugging ltconfig, is in ./config.log if it exists.
 
# The version of ltconfig that generated this script.
LTCONFIG_VERSION="1.3.5"

to the spot before SHELL=/bin/sh in libtool. Hence
libtool fails with a version mismatch.

5) Doco to the effect that

./configure --disable-osmesa --prefix=/usr
--infodir=/usr/share/info --mandir=/usr/share/man

is probably the right thing for linux. The
--disable-osmesa is needed on the first build because
the osmesa make tries to link to a library that is not
built yet.


Hope this helps, I know how easy it is to miss stuff
like this when you have a working CVS sandpit.

Cheers.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=438348&group_id=3

[Mesa3d-dev] Segmentation Fault in shade_rastpos

[Allen B. <ba...@lo...>]

Hi,

I'm getting a segmentation fault in the Mesa function shade_rastpos()
when lighting is turned on and if no other drawing precedes a call to
RasterPos2i(). Attached is a sample program which demonstrates the
problem. I'm using Mesa 3.5.1 on RedHat 7.1/i386.

Thanks,
Allen

[Mesa3d-dev] Segmentation Fault in shade_rastpos

[Allen B. <ba...@lo...>]

Hi,

I'm getting a segmentation fault in the Mesa function shade_rastpos()
when lighting is turned on and if no other drawing precedes a call to
RasterPos2i(). Attached is a sample program which demonstrates the
problem. I'm using Mesa 3.5.1 on RedHat 7.1/i386.

BTW, GL_RASTER_POSITION_UNCLIPPED_IBM works great! Thank you.

Thanks,
Allen

[Mesa3d-dev] XMesaSetFXMode causes problem

[I. P. <igo...@ma...>]

Hello.

XMesaSetFXMode on Voodoo2 under FreeBSD in Linux emulation causing signal 11
to be raised. May be somebody know about this problem?

Best regards
Igor Pokrovsky

Re: [Mesa3d-dev] [Fwd: Link problem for Mesa 3.5 - patch included]

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

On Mon, Jul 02, 2001 at 08:19:04AM -0600, Brian Paul wrote:
> > Hmmm, is libGL.so even supposed to link against -lMesaOS?
> 
> No.  The other way around: libOSMesa depends on libGL.

Hehe, oh of course. So now I've switched things around accordingly: libGL no
more depends, even knows, anything about libMesaOS. libMesaOS however is
linked against, and therefore depends on, the libGL built.

Looks here as if everything's correct, can you verify?


> > But libMesaOS is supposed to be installed, right?
> 
> Right.

OK. Set to be installed in libdir.


> The libOSMesa.so library contains the code which implements the OSMesa
> interface functions like OSMesaCreateContext(), OSMesaMakeCurrent(), etc.
> 
> I've split this off from the core GL library to be consistant with
> XFree86.  It's also a better design.  If an application has a dependency
> on the OSMesa interface, it should express that dependency in its
> library bindings.

I see now, thanks.
-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 problem

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

On Mon, Jul 02, 2001 at 04:05:40PM +0200, Marcelo E. Magallon wrote:
> AC_DEFUN(MESA_SYS_AS_FEATURE, [
>   AC_CACHE_CHECK(whether the assembler supports $1,
>                  mesa_cv_sys_as_$1,
>                  MESA_TRY_ASSEMBLE([#include "src/X86/assyntax.h"], $2,
>                                    mesa_cv_sys_as_$1=yes,
>                                    mesa_cv_sys_as_$1=no))
> ])

I changed that to [#include "assyntax.h"].


>  note the test program wants to include "src/X86/assyntax.h".  For this
>  to work, the command line has to read:
> 
>  $ cc [...] -I../.. [...]
> 
>  In config.log I find:
> 
> configure:7290: gcc -c -g -O2 -Wall -fomit-frame-pointer -ffast-math -fexpensive
> -optimizations -fstrict-aliasing -malign-loops=2 -malign-jumps=2 -malign-functio
> ns=2 -D_REENTRANT -DPTHREADS  -I../../src/X86 conftest.S >&5
> conftest.S:1: src/X86/assyntax.h: No such file or directory
> 
>  Note it's using -I../../src/X86
> 
>  MESA_TRY_ASSEMBLE looks like this:
> 
> AC_DEFUN(MESA_TRY_ASSEMBLE, [
>   cat > conftest.S <<EOF
> $1
> 
> $2
> EOF
>   save_ac_ext="$ac_ext"
>   ac_ext=S
>   if AC_TRY_EVAL(ac_compile); then
>     $3;
>   else
>     $4;
>   fi
>   ac_ext="$save_ac_ext"
>   rm -f conftest.S
> ])
> 
>  In the top configure.in file it reads:
> 
> dnl Necessary for assembler sources
> save_ac_ext="$ac_ext"
> save_CPPFLAGS="$CPPFLAGS"
> ac_ext=S
> CPPFLAGS="$CPPFLAGS -I$srcdir/src/X86"
> 
>  what I need there is an extra "-I$srcdir" like this:
> 
> -CPPFLAGS="$CPPFLAGS -I$srcdir/src/X86"
> +CPPFLAGS="$CPPFLAGS -I$srcdir/src/X86 -I$srcdir"

That CPPFLAGS addition "-I$srcdir/src/X86" was originally there for exactly
the purpose of enabling one to #include "assyntax.h". It just got under the
wheels when I pulled the ASM checks out into assembler.m4 and was merely still
lingering around. Now I've put it to use again by stripping the "src/X86/"
from the include line.

Therefore the cross-directory build should now work.

-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] Question about Mesa3D porting

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

On Mon, 2 Jul 2001, Brian Paul wrote:

> s.w...@if... wrote:
> > 
> > Hi,
> > I wondered what it would take to port Mesa3D on a new
> > 3D accelerated hardware (DreamCast).
> > Also is anyone aware of such a port? or perhaps is
> > someone interessed in helping?
>
> I haven't heard of anyone doing this project.
>
> I don't know any details about the DreamCast but I'd expect that a
> driver could be written.

The DreamCast is pretty well documented now - so there ought to be
enough information to go on...and it clearly does pretty good 3D
so I'd expect it to be physically capable of doing at least a
useful subset of OpenGL's rendering operations with hardware
accelleration.

Since there is now Linux and X-windows for Dreamcast - you can get
networking, keyboard and mouse - and you can pick one up for $99
now - it would certainly be *way* cool to be able to do this.

Also, putting one of my games + Linux onto a CD for Dreamcast would
give my kid *major* bragging rights at school.  So if you want to
make one little boy very happy, please contri...

I'm sorry - I went off the deep end there for a moment  :-)

----
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] Question about Mesa3D porting

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

s.w...@if... wrote:
> 
> Hi,
> I wondered what it would take to port Mesa3D on a new
> 3D accelerated hardware (DreamCast).
> Also is anyone aware of such a port? or perhaps is
> someone interessed in helping?

I haven't heard of anyone doing this project.

I don't know any details about the DreamCast but I'd expect that a
driver could be written.  Unfortunately, there isn't any documentation
for writing Mesa drivers (there's always more important things
to do).  I'd suggest looking that the XFree86 DRI drivers which are
based on Mesa (see the mesa-3-5-branch CVS branch in the DRI project).
That would be a good start.

-Brian

Re: [Mesa3d-dev] [Fwd: Link problem for Mesa 3.5 - patch included]

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

"Sven M. Hallberg" wrote:
> 
> On Fri, Jun 29, 2001 at 07:56:41AM -0600, Brian Paul wrote:
> >
> > Sven, can you look at this?
> >
> > -Brian
> >
> >
> > Lans Carstensen wrote:
> > >
> > > Greetings!
> > >
> > > There is a problem with the libMesaOS.la during builds, such that
> > > src/.libs/libGL.so.* get moved aside and not relinked on a "make
> > > install".  Instead of pointing at the .libs directory for linking, the
> > > build is pointing to /usr/lib when relinking with -lMesaOS.
> 
> Hmmm, is libGL.so even supposed to link against -lMesaOS?

No.  The other way around: libOSMesa depends on libGL.


> If I'm correct,
> I overlooked that when I changed libMesaOS from a convenience lib to a
> shared one. Please confirm!
> 
> > > Basically, a clean build on a clean machine won't work because of this.
> > > The patch below fixes this.  Looks like it was a typo.  I was able to
> > > rebuild Mesa 3.5 RPMs for RedHat 7.1 for some of our internal work with
> > > this patch.  If you'd like me to submit my Mesa 3.5 source RPM, I'd be
> > > happy to - just let me know where to FTP it.
> > >
> > > *** src/OSmesa/Makefile.am.orig Wed Jun 27 16:02:16 2001
> > > --- src/OSmesa/Makefile.am      Wed Jun 27 16:02:30 2001
> > > ***************
> > > *** 5,11 ****
> > >   INCLUDES = -I$(top_srcdir)/include -I$(top_srcdir)/src
> > >
> > >   if HAVE_OSMESA
> > > ! lib_LTLIBRARIES = libMesaOS.la
> > >   endif
> > >
> > >   libMesaOS_la_SOURCES = osmesa.c
> > > --- 5,11 ----
> > >   INCLUDES = -I$(top_srcdir)/include -I$(top_srcdir)/src
> > >
> > >   if HAVE_OSMESA
> > > ! noinst_LTLIBRARIES = libMesaOS.la
> > >   endif
> > >
> > >   libMesaOS_la_SOURCES = osmesa.c
> 
> But libMesaOS is supposed to be installed, right?

Right.


> Sorry if I'm complicated, my view of where and how libMesaOS should appear and
> how it is used is just a bit foggy, because I've never really looked at it.
> Enlightenment appreciated, though. :)

The libOSMesa.so library contains the code which implements the OSMesa
interface functions like OSMesaCreateContext(), OSMesaMakeCurrent(), etc.

I've split this off from the core GL library to be consistant with
XFree86.  It's also a better design.  If an application has a dependency
on the OSMesa interface, it should express that dependency in its
library bindings.

-Brian

[Mesa3d-dev] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

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

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

 >   * m4/assembler.m4 (MESA_SYS_AS_FEATURE): Include simply "assyntax.h".
 >   because configure.in already adds -I$srcdir/src/X86 to CPPFLAGS.

 or that... thanks!

-- 
Marcelo

Re: [Mesa3d-dev] libtool problem

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

Hi Sven,

 > :) Finally! As you can see from the above, configure.in already adds
 > -I$srcdir/src/X86 to CPPFLAGS.

 I don't think I expressed myself correctly.

 My problem is this (solution/pseudo patch at the end, if you want to
 skip all this).  I do:

 $ mkdir build/software
 $ cd build/software
 $ ../../configure

 configure says MMX and whatever are not supported and disables that.
 AFAICS it's because of this:

AC_DEFUN(MESA_SYS_AS_FEATURE, [
  AC_CACHE_CHECK(whether the assembler supports $1,
                 mesa_cv_sys_as_$1,
                 MESA_TRY_ASSEMBLE([#include "src/X86/assyntax.h"], $2,
                                   mesa_cv_sys_as_$1=yes,
                                   mesa_cv_sys_as_$1=no))
])

 note the test program wants to include "src/X86/assyntax.h".  For this
 to work, the command line has to read:

 $ cc [...] -I../.. [...]

 In config.log I find:

configure:7290: gcc -c -g -O2 -Wall -fomit-frame-pointer -ffast-math -fexpensive
-optimizations -fstrict-aliasing -malign-loops=2 -malign-jumps=2 -malign-functio
ns=2 -D_REENTRANT -DPTHREADS  -I../../src/X86 conftest.S >&5
conftest.S:1: src/X86/assyntax.h: No such file or directory

 Note it's using -I../../src/X86

 MESA_TRY_ASSEMBLE looks like this:

AC_DEFUN(MESA_TRY_ASSEMBLE, [
  cat > conftest.S <<EOF
$1

$2
EOF
  save_ac_ext="$ac_ext"
  ac_ext=S
  if AC_TRY_EVAL(ac_compile); then
    $3;
  else
    $4;
  fi
  ac_ext="$save_ac_ext"
  rm -f conftest.S
])

 In the top configure.in file it reads:

dnl Necessary for assembler sources
save_ac_ext="$ac_ext"
save_CPPFLAGS="$CPPFLAGS"
ac_ext=S
CPPFLAGS="$CPPFLAGS -I$srcdir/src/X86"

 what I need there is an extra "-I$srcdir" like this:

-CPPFLAGS="$CPPFLAGS -I$srcdir/src/X86"
+CPPFLAGS="$CPPFLAGS -I$srcdir/src/X86 -I$srcdir"

 TIA,

-- 
Marcelo

Re: [Mesa3d-dev] libtool problem

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

On Mon, Jun 25, 2001 at 10:55:08PM +0200, Marcelo E. Magallon wrote:
>  doesn't ac_compile already include all the necessary -I's?  I thought so but
>  on the config.log I have:
> 
> configure:7290: gcc -c -g -O2 -Wall -fomit-frame-pointer -ffast-math -fexpensive
> -optimizations -fstrict-aliasing -malign-loops=2 -malign-jumps=2 -malign-functio
> ns=2 -D_REENTRANT -DPTHREADS  -I../../src/X86 conftest.S >&5
> conftest.S:1: src/X86/assyntax.h: No such file or directory

:) Finally! As you can see from the above, configure.in already adds
-I$srcdir/src/X86 to CPPFLAGS. I had completely overlooked that. So now the
m4/assembler.m4 macro simply includes "assyntax.h" alone. I guess that should
work. Can you verify this?


>  I can fix this on the command line, but I'm wondering what's the nice
>  autoconf way of doing this...

Once again one of these cases, where the problem is actually already solved,
and one just has to find that out. :)


-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] Question about Mesa3D porting

[<s.w...@if...>]

Hi,
I wondered what it would take to port Mesa3D on a new
3D accelerated hardware (DreamCast).
Also is anyone aware of such a port? or perhaps is
someone interessed in helping?

Thanks anyway

=20
____________________________________________________________=
__________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur l=
e WAP...
http://www.ifrance.com/_reloc/email.emailif

Re: [Mesa3d-dev] libtool problem

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

On Mon, Jun 25, 2001 at 10:55:08PM +0200, Marcelo E. Magallon wrote:
> >> "Sven M. Hallberg" <pe...@gm...> writes:
> 
>  > Actually, I'm pretty sure that an explicit libtoolize is not needed,
>  >         automake -a -c
>  > does it itself (I think it says so in the docs, too).
> 
>  Oh, cool.

So, should I remove it again? It's explicit use is even discouraged when
using automake, IIRC.


>  Perhaps you know how to fix this one...  m4/assembler.m4 reads:
> 
> AC_DEFUN(MESA_SYS_AS_FEATURE, [
>   AC_CACHE_CHECK(whether the assembler supports $1,
>                  mesa_cv_sys_as_$1,
>                  MESA_TRY_ASSEMBLE([#include "src/X86/assyntax.h"], $2,
>                                    mesa_cv_sys_as_$1=yes,
>                                    mesa_cv_sys_as_$1=no))
> ])
> 
>  I need to get -I$(srcdir) on the command line because I use VPATH to
>  compile mesa (cd buld/software && ../../configure).  MESA_TRY_ASSEMBLE
>  looks like this:
> 
> AC_DEFUN(MESA_TRY_ASSEMBLE, [
>   cat > conftest.S <<EOF
> $1
> 
> $2
> EOF
>   save_ac_ext="$ac_ext"
>   ac_ext=S
>   if AC_TRY_EVAL(ac_compile); then
>     $3;
>   else
>     $4;
>   fi····
>   ac_ext="$save_ac_ext"
>   rm -f conftest.S
> ])
> 
>  doesn't ac_compile already include all the necessary -I's?  I thought so but
>  on the config.log I have:
> 
> configure:7290: gcc -c -g -O2 -Wall -fomit-frame-pointer -ffast-math -fexpensive
> -optimizations -fstrict-aliasing -malign-loops=2 -malign-jumps=2 -malign-functio
> ns=2 -D_REENTRANT -DPTHREADS  -I../../src/X86 conftest.S >&5
> conftest.S:1: src/X86/assyntax.h: No such file or directory

Look at that: '-I../../src/X86'. That's the correct include path to your
$(top_srcdir)/src/X86, correct? How did it get there? Right now I'm trying to
reproduce this, but I'm running into other problems myself... garrr. Hope I
can resolve this soon.


>  I can fix this on the command line, but I'm wondering what's the nice
>  autoconf way of doing this...

I'll first see where that -I switch came from and whether I can rely on it
being there (for whatever reason...), otherwise it's probably just a matter of
putting it manually into CFLAGS in the right place.


So long,
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] [Fwd: Link problem for Mesa 3.5 - patch included]

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

On Fri, Jun 29, 2001 at 07:56:41AM -0600, Brian Paul wrote:
> 
> Sven, can you look at this?
> 
> -Brian
> 
> 
> Lans Carstensen wrote:
> > 
> > Greetings!
> > 
> > There is a problem with the libMesaOS.la during builds, such that
> > src/.libs/libGL.so.* get moved aside and not relinked on a "make
> > install".  Instead of pointing at the .libs directory for linking, the
> > build is pointing to /usr/lib when relinking with -lMesaOS.

Hmmm, is libGL.so even supposed to link against -lMesaOS? If I'm correct,
I overlooked that when I changed libMesaOS from a convenience lib to a
shared one. Please confirm!


> > Basically, a clean build on a clean machine won't work because of this.
> > The patch below fixes this.  Looks like it was a typo.  I was able to
> > rebuild Mesa 3.5 RPMs for RedHat 7.1 for some of our internal work with
> > this patch.  If you'd like me to submit my Mesa 3.5 source RPM, I'd be
> > happy to - just let me know where to FTP it.
> > 
> > *** src/OSmesa/Makefile.am.orig Wed Jun 27 16:02:16 2001
> > --- src/OSmesa/Makefile.am      Wed Jun 27 16:02:30 2001
> > ***************
> > *** 5,11 ****
> >   INCLUDES = -I$(top_srcdir)/include -I$(top_srcdir)/src
> > 
> >   if HAVE_OSMESA
> > ! lib_LTLIBRARIES = libMesaOS.la
> >   endif
> > 
> >   libMesaOS_la_SOURCES = osmesa.c
> > --- 5,11 ----
> >   INCLUDES = -I$(top_srcdir)/include -I$(top_srcdir)/src
> > 
> >   if HAVE_OSMESA
> > ! noinst_LTLIBRARIES = libMesaOS.la
> >   endif
> > 
> >   libMesaOS_la_SOURCES = osmesa.c

But libMesaOS is supposed to be installed, right?


Sorry if I'm complicated, my view of where and how libMesaOS should appear and
how it is used is just a bit foggy, because I've never really looked at it.
Enlightenment appreciated, though. :)

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] [ mesa3d-Bugs-437667 ] libGL.la missing

[<no...@so...>]

Bugs item #437667, was opened at 2001-06-30 21:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=437667&group_id=3

Category: mesa-core
Group: Fatal Error
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: libGL.la missing

Initial Comment:
Recently compiled Mesa3.5 (both lib and demos), and 
when attempting to build kdebase2.1.1, compile errors 
out because libGL.la is missing.  I've reinstalled 
Mesa, and still no luck.  Any idea how I can get away 
from this problem, short of disabling GL support in 
KDE?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=437667&group_id=3

[Mesa3d-dev] libtool black magick for src-glu

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

Hi,

 configure.in reads:

 LIBGLU_VERSION_INFO=1:${MESA_VERSION}:1     # GLU 1.1

 it should be

 LIBGLU_VERSION_INFO=2:${MESA_VERSION}:1     # GLU 1.1
 
 the SI version correct.

-- 
Marcelo

[Mesa3d-dev] XMesaSetFXMode

[I. P. <igo...@ma...>]

Hello.

I'm using Mesa-3.4.2 on FreeBSD under Linux emulation. Mesa works fine under
FreeBSD, but one thing - Mesa reports, that signal 11 had been received,
when I tried to use XMesaSetFXmode to change between fullscreen and window
mode on fly. I'm very surprised that this feature don't work. Can
anyon help me?

===============================================================

 Saturday, June 30, 2001, 7:03:09 AM           I.Pokrovsky