mesa3d-dev

Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]

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

>> li...@th... writes:

 > So the 1.2 is "static"? Have you looked at -release? I don't know what
 > this will do to the SONAME though. It won't give you the name above
 > but close enough (libGL-1.2.xxyyzz.so).

 This is the problem.  In this case the soname *must* be libGL.so.1 (on
 Linux).  The problem is that the library is provided by several
 vendors, and a sane development environment is needed: if I compile foo
 with a particular vendor's version it must run with all the others.
 The exposed interface is well defined and this level of compatibility
 is achievable.  Mesa is unique in that it's available for a multitude
 of platforms.  Linux is the only one where this issue is critical (it'd
 be nice if Mesa used the native libgl's soname on every platfrom, but
 it's just a minor issue)

 What Mesa needs from libtool is libtool's knowledge about multiple
 platform's oddities regarding compilation and linking, but it also
 needs a way to be able to set the soname.  Yes, this is bad in general.
 It defeats the whole purpose of libtool, but the problem is that Mesa
 is providing another version of an existing library.  I can imagine
 things like Motif (lesstif), OpenInventor (Coin, mostly non issue now)
 are in the same situation.

-- 
Marcelo

Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]

[<li...@th...>]

On Thu, Jun 07, 2001 at 11:50:44AM -0600, Brian Paul wrote:
> I'm not going to put a lot of effort into explaining this but here's
> the story.
> 
> Mesa's used the convention libGL.so.1.2.xxyyzz for some years now.
> The "1.2" indicates the library implements the OpenGL 1.2 API.
> Anything else there would be VERY confusing for end users at this
> point.
> 
> The last part "xxyyzz" is usually something like 030402 to indicate
> Mesa version 3.4.2.  With this convention, people can look at their
> libGL.so.1.2.xxyyzz file and determine which version of Mesa they're
> using.  It also allows various versions of libGL.so.1.2.* to coexist.
> This very useful for the developers so we may easily switch between
> versions when doing regression testing.

So the 1.2 is "static"? Have you looked at -release? I don't know what
this will do to the SONAME though. It won't give you the name above
but close enough (libGL-1.2.xxyyzz.so).

-- 
albert chin (ch...@th...)

Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]

[Lars J. A. <la...@si...>]

On Thu, Jun 07, 2001 at 11:50:44AM -0600, Brian Paul wrote:
: I'm not going to put a lot of effort into explaining this but here's
: the story.
: 
: Mesa's used the convention libGL.so.1.2.xxyyzz for some years now.
: The "1.2" indicates the library implements the OpenGL 1.2 API.
: Anything else there would be VERY confusing for end users at this
: point.

You probably won't be able to use that scheme with libtool without
changing libtool.  libtool doesn't just pass the integers through the
system for library naming reasons.  Another thing is that how the
numbers are set up depends on the system (e.g. on IRIX, the age part
is dropped from the library filename, and the current part is
incremented by one).

  Lars J

Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]

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

Peter Eisentraut wrote:
> 
> Sven M. Hallberg writes:
> 
> > We use the formula
> >  version-info = Major+minor:Mesa_version:Minor
> > to compute proper libtool version-info from the OpenGL version number (1.2)
> > and our current Mesa release number (MM.Mm.Mt, e.g. 3.5.0). So, Mesa_version
> > is an integer derived from that release number. We'd like to use
> >  Mesa_version = MM * 10^4 + Mm * 10^2 + Mt
> > which would yield something like 30500. However libtool only accepts three
> > digits for the REVISION part of the version-info (as Marcelo mentions below).
> 
> You must have missed the part of the documentation that says:
> 
> :    *_Never_* try to set the interface numbers so that they correspond
> : to the release number of your package.  This is an abuse that only
> : fosters misunderstanding of the purpose of library versions.
> 
> (not my emphasis)
> 
> The documentation describes in detail how you are supposed to set the
> three version fields.  Anything else will be trouble.

I'm not going to put a lot of effort into explaining this but here's
the story.

Mesa's used the convention libGL.so.1.2.xxyyzz for some years now.
The "1.2" indicates the library implements the OpenGL 1.2 API.
Anything else there would be VERY confusing for end users at this
point.

The last part "xxyyzz" is usually something like 030402 to indicate
Mesa version 3.4.2.  With this convention, people can look at their
libGL.so.1.2.xxyyzz file and determine which version of Mesa they're
using.  It also allows various versions of libGL.so.1.2.* to coexist.
This very useful for the developers so we may easily switch between
versions when doing regression testing.

I understand that libtool has a specific versioning convention and
we don't want you to change that.  It's just that if the REVISION
part could accomodate a 6-digit number (with leading zeros) we'd
be grateful.

-Brian

Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]

[Peter E. <pe...@gm...>]

Sven M. Hallberg writes:

> We use the formula
>  version-info = Major+minor:Mesa_version:Minor
> to compute proper libtool version-info from the OpenGL version number (1.2)
> and our current Mesa release number (MM.Mm.Mt, e.g. 3.5.0). So, Mesa_version
> is an integer derived from that release number. We'd like to use
>  Mesa_version = MM * 10^4 + Mm * 10^2 + Mt
> which would yield something like 30500. However libtool only accepts three
> digits for the REVISION part of the version-info (as Marcelo mentions below).

You must have missed the part of the documentation that says:

:    *_Never_* try to set the interface numbers so that they correspond
: to the release number of your package.  This is an abuse that only
: fosters misunderstanding of the purpose of library versions.

(not my emphasis)

The documentation describes in detail how you are supposed to set the
three version fields.  Anything else will be trouble.

-- 
Peter Eisentraut   pe...@gm...   http://funkturm.homeip.net/~peter

[marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]

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

Hi,

I'm working on the Mesa project's build system using autoconf, automake, and
libtool. We're running into the following problem:

We use the formula
 version-info = Major+minor:Mesa_version:Minor
to compute proper libtool version-info from the OpenGL version number (1.2)
and our current Mesa release number (MM.Mm.Mt, e.g. 3.5.0). So, Mesa_version
is an integer derived from that release number. We'd like to use
 Mesa_version = MM * 10^4 + Mm * 10^2 + Mt
which would yield something like 30500. However libtool only accepts three
digits for the REVISION part of the version-info (as Marcelo mentions below).
Is it possible to extend that limitation to five or six digits?

That would be greatly appreciated.
Thanks in advance,

Sven

PS: Libtool rocks!

----- Forwarded message from "Marcelo E. Magallon" <mar...@bi...> -----

From: "Marcelo E. Magallon" <mar...@bi...>
To: Brian Paul <br...@va...>
Cc: mes...@li...
Subject: Re: [Mesa3d-dev] Re: libtool (was CVS and SSE)
Date: Mon, 21 May 2001 23:41:40 +0200

>> 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...

-- 
Marcelo

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


----- End forwarded message -----

-- 
"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!

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

On Wed, Jun 06, 2001 at 12:56:40PM -0600, Brian Paul wrote:
> 
> Picking up this thread again from two weeks ago...
> 
> [ ... snip ... ]
> > > > 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??
> 
> 
> As I said, there should be a libOSMesa.so.3.5.030500 or libOSMesa.so.3.5
> library.  The SONAME should probably be "libOSMesa.so.3".
> 
> Can you do this?

No problem, done. I used the same formula to make a libtool version-info as
with libGL and friends. Note, that I still have to use libOSMesa.so.3.5.305.

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: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

[David S. M. <da...@re...>]

Brian Paul writes:
 > As it is now, the __glapi_sparc_icache_flush code is in the
 > SPARC/glapi_sparc.S file.  Can that file be compiled with a non-GCC
 > assembler (such as the Solaris assembler)?  Just curious.

Yes, it most certainly should build and work with any Sparc assembler.

Later,
David S. Miller
da...@re...

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

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

"David S. Miller" wrote:
> 
> Brian Paul writes:
>  > David, one comment: I see that glapi.c now has a dependency on
>  > the SPARC/sparc.h header file.  One of my goals for the gl*.[ch]
>  > dispatch files is that they're a self-contained group and have
>  > no dependencies on any other Mesa source files since they're
>  > also used by libGL (which has no dependencies on Mesa).
>  >
>  > Is is possible to remove this dependency?
> 
> I have to flush the instruction cache of the processor when I relocate
> the data references in the instructions of the glapi sparc table.
> 
> There is no standard library call to do this.
> 
> I could use GCC inline assembly when that is the compiler being used,
> but then this would still need a solution when a compiler other than
> GCC is used.

As it is now, the __glapi_sparc_icache_flush code is in the
SPARC/glapi_sparc.S file.  Can that file be compiled with a non-GCC
assembler (such as the Solaris assembler)?  Just curious.

Don't fret too much over this.  Since the assembly code is optional
there's not a hard dependency.

-Brian

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

[David S. M. <da...@re...>]

Brian Paul writes:
 > David, one comment: I see that glapi.c now has a dependency on
 > the SPARC/sparc.h header file.  One of my goals for the gl*.[ch]
 > dispatch files is that they're a self-contained group and have
 > no dependencies on any other Mesa source files since they're
 > also used by libGL (which has no dependencies on Mesa).
 > 
 > Is is possible to remove this dependency?

I have to flush the instruction cache of the processor when I relocate
the data references in the instructions of the glapi sparc table.

There is no standard library call to do this.

I could use GCC inline assembly when that is the compiler being used,
but then this would still need a solution when a compiler other than
GCC is used.

Later,
David S. Miller
da...@re...

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

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

Picking up this thread again from two weeks ago...


> > > > 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??


As I said, there should be a libOSMesa.so.3.5.030500 or libOSMesa.so.3.5
library.  The SONAME should probably be "libOSMesa.so.3".

Can you do this?

-Brian

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

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

"Marcelo E. Magallon" wrote:
> 
> >> "Sven M. Hallberg" <pe...@gm...> writes:
> 
>  > As far as autoconf is concerned, a simple test case will find out
>  > whether fpstate.magic is defined. The code would use an #ifdef. The
>  > usual way, really.
> 
>  Yes, the problem is doing this with Imakefiles.  You depend on whatever
>  the
> 
>  I have looked a bit more into this...
> 
>  The solution Brian is looking for looks like:
> 
> #include <signal.h>
> /* ... */
> #if defined(USE_KATMAI_ASM) && defined(X86_FXSR_MAGIC)
> /* ... */
> #endif
> 
>  this compiles the SSE support only if the glibc kernel headers are 2.4
>  headers (or patched 2.2 ones).  I don't like it, it's ugly.

I've committed this solution (basically).  I don't think it's ugly.


>  The proper solution is teaching config/imake/imake.c about
>  DefaultHasKatmaiSupport.  Include signal.h and define this as YES if
>  X86_FXSR_MAGIC is defined, and NO in other case.  Massage other files
>  to use this.  Of course this doesn't solve the case where the user
>  intentionally sets HasKatmaiSupport to YES but doesn't have the correct
>  headers.  With the imake system you can't solve that.
> 
>  This is Linux specific, I have no idea how to handle this in other X86
>  OS.  Anyone with a clue?

I think simply patching the source file with the test for X86_FXSR_MAGIC
is sufficient.

-Brian

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

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

"David S. Miller" wrote:
> 
> CVSROOT:        /cvsroot/mesa3d
> Module name:    Mesa
> Repository:     Mesa/src/SPARC/
> Changes by:     davem69@usw-pr-cvs1.    01/06/05 16:54:01
> 
> Log message:
>   Sparc optimized GLAPI dispatch table.
> 
> Modified files:
>       Mesa/bin/:
>         glsparcasm.py
>       Mesa/src/:
>         context.c dispatch.c glapi.c
>       Mesa/src/SPARC/:
>         Makefile.am glapi_sparc.S sparc.c sparc.h sparc_matrix.h
>         xform.S
> 
>   Revision      Changes    Path
>   1.2           +10 -4     Mesa/bin/glsparcasm.py
>   1.141         +7 -1      Mesa/src/context.c
>   1.23          +2 -2      Mesa/src/dispatch.c
>   1.55          +53 -2     Mesa/src/glapi.c
>   1.2           +3 -1      Mesa/src/SPARC/Makefile.am
>   1.2           +1363 -1223Mesa/src/SPARC/glapi_sparc.S
>   1.3           +31 -2     Mesa/src/SPARC/sparc.c
>   1.2           +3 -1      Mesa/src/SPARC/sparc.h
>   1.2           +40 -154   Mesa/src/SPARC/sparc_matrix.h
>   1.2           +2 -25     Mesa/src/SPARC/xform.S

David, one comment: I see that glapi.c now has a dependency on
the SPARC/sparc.h header file.  One of my goals for the gl*.[ch]
dispatch files is that they're a self-contained group and have
no dependencies on any other Mesa source files since they're
also used by libGL (which has no dependencies on Mesa).

Is is possible to remove this dependency?

-Brian

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

[David D. <da...@XF...>]

On Tue, Jun 05, 2001 at 09:56:44AM -0600, Brian Paul wrote:
>"Marcelo E. Magallon" wrote:
>> 
>> >> 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.
>
>
>I'd like to see a solution that doesn't interupt compilation.  That
>is, if we can't use SSE at compile time, it should just be disabled,
>perhaps with a warning.
>
>The trick is there was a patch to Linux 2.2.x that added SSE so just
>testing for kernel >= 2.4.0 isn't enough.  Does the presense of
>X86_FXSR_MAGIC ensure that the _fpstate.magic field exists?

For builds within XFree86, linux.cf already has the kernel version check:

#ifndef HasKatmaiSupport
#  ifdef i386Architecture
#    if OSMajorVersion > 2 || (OSMajorVersion == 2 && OSMinorVersion >= 4)
#      define HasKatmaiSupport          YES
#    else
#      define HasKatmaiSupport          NO
#    endif
#  else
#    define HasKatmaiSupport            NO
#  endif
#endif

It assumes that the kernel headers will be found for the build though.

David
--
David Dawes                                      Email: da...@XF...
Founder/President, The XFree86 Project, Inc      Phone: +1 510 687 6857
http://www.xfree86.org/

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

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

>> "Marcelo E. Magallon" <mar...@bi...> writes:

 >  The proper solution is teaching config/imake/imake.c about
 >  DefaultHasKatmaiSupport.  Include signal.h and define this as YES if
 >  X86_FXSR_MAGIC is defined, and NO in other case.  Massage other
 >  files to use this.  Of course this doesn't solve the case where the
 >  user intentionally sets HasKatmaiSupport to YES but doesn't have the
 >  correct headers.  With the imake system you can't solve that.

 I just uploaded a patch that does this.  (#403332)

-- 
Marcelo

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

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

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

 > As far as autoconf is concerned, a simple test case will find out
 > whether fpstate.magic is defined. The code would use an #ifdef. The
 > usual way, really.

 Yes, the problem is doing this with Imakefiles.  You depend on whatever
 the 

 I have looked a bit more into this...

 The solution Brian is looking for looks like:

#include <signal.h>
/* ... */
#if defined(USE_KATMAI_ASM) && defined(X86_FXSR_MAGIC)
/* ... */
#endif

 this compiles the SSE support only if the glibc kernel headers are 2.4
 headers (or patched 2.2 ones).  I don't like it, it's ugly.

 The proper solution is teaching config/imake/imake.c about
 DefaultHasKatmaiSupport.  Include signal.h and define this as YES if
 X86_FXSR_MAGIC is defined, and NO in other case.  Massage other files
 to use this.  Of course this doesn't solve the case where the user
 intentionally sets HasKatmaiSupport to YES but doesn't have the correct
 headers.  With the imake system you can't solve that.

 This is Linux specific, I have no idea how to handle this in other X86
 OS.  Anyone with a clue?

-- 
Marcelo

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

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

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

 > Then in order to use SSE on a machine at runtime, one must have
 > an SSE capable machine to build on?  I don't like the sound of
 > that, even if my box has SSE.  IMHO, the build host should be
 > independant of the runtime host.

 No, you must have a machine with the correct kernel headers, that is,
 with a glibc that provides the correct headers.

-- 
Marcelo

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

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

On Tue, Jun 05, 2001 at 08:47:07AM -0600, Brian Paul wrote:
> 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.

As far as autoconf is concerned, a simple test case will find out whether
fpstate.magic is defined. The code would use an #ifdef. The usual way, really.

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: mesa assuming glibc 2.2? (Cannot compile4.

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

Am Mittwoch, 6. Juni 2001 04:55 schrieb Dieter Nützel:
> It would be more complicated soon as more and more people start using the
> new Athlon 4/MP / Duron mobile 'cause they support 3DNow! Professional
> (full Intel SSE). The configure script (the user?) have to decide which one
> to use (3DNow!/3DNow! enhanced or SSE).
>
> Gareth which perform better on Athlon / Duron?
> If I remember right you found that 3DNow! on your Duron 600 was faster then
> SSE on your PIII 700 mobile?
>
> Regards,
> 	Dieter

Ups, sorry wrong List...;-)

-Dieter

Re: [Mesa3d-dev] Re: mesa assuming glibc 2.2? (Cannot compile4.1 on RedHat 6.2)

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

On Tue, 5 Jun 2001, Brian Paul wrote:

>> Then in order to use SSE on a machine at runtime, one must have
>> an SSE capable machine to build on?  I don't like the sound of
>> that, even if my box has SSE.  IMHO, the build host should be
>> independant of the runtime host.
>>
>> Perhaps I am misunderstanding the above comments?
>
>Perhaps so.  At runtime, the Mesa code tries to execute some SSE
>instructions and checks if it works or not.  It might fail because
>there's no kernel support or you're using a CPU without SSE
>instructions.  This is done with an exception handler.
>
>Now at compile time we need at least a certain version of the system
>headers in order to compile the exception handler code.
>If we don't have the right headers, we can't compile the code.  I'm
>just saying that I'd rather the compilation continued without SSE
>capability rather than bomb out.
>
>If you've got the right headers but compiling on a non-SSE CPU you
>can certainly compile in the SSE support.  You just won't be able to
>use it on that system.

Ok, that all makes sense then.  An autoconf check ala:

checking if proper headers for SSE support exist... no

That would be ok I suppose, as the build environment really
should match the end-use environment IMHO for stable packaging,
however the CPU may differ at runtime, so the above should be ok.



----------------------------------------------------------------------
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] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile4.1 on RedHat 6.2)

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

"Mike A. Harris" wrote:
> 
> On Tue, 5 Jun 2001, Brian Paul wrote:
> 
> >>  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.
> >
> >
> >I'd like to see a solution that doesn't interupt compilation.  That
> >is, if we can't use SSE at compile time, it should just be disabled,
> >perhaps with a warning.
> 
> Then in order to use SSE on a machine at runtime, one must have
> an SSE capable machine to build on?  I don't like the sound of
> that, even if my box has SSE.  IMHO, the build host should be
> independant of the runtime host.
> 
> Perhaps I am misunderstanding the above comments?

Perhaps so.  At runtime, the Mesa code tries to execute some SSE
instructions and checks if it works or not.  It might fail because
there's no kernel support or you're using a CPU without SSE
instructions.  This is done with an exception handler.

Now at compile time we need at least a certain version of the system
headers in order to compile the exception handler code.
If we don't have the right headers, we can't compile the code.  I'm
just saying that I'd rather the compilation continued without SSE
capability rather than bomb out.

If you've got the right headers but compiling on a non-SSE CPU you
can certainly compile in the SSE support.  You just won't be able to
use it on that system.

-Brian

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

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

On Tue, 5 Jun 2001, Brian Paul wrote:

>>  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.
>
>
>I'd like to see a solution that doesn't interupt compilation.  That
>is, if we can't use SSE at compile time, it should just be disabled,
>perhaps with a warning.

Then in order to use SSE on a machine at runtime, one must have
an SSE capable machine to build on?  I don't like the sound of
that, even if my box has SSE.  IMHO, the build host should be
independant of the runtime host.

Perhaps I am misunderstanding the above comments?



----------------------------------------------------------------------
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] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile 4.1 on RedHat 6.2)

[Gareth H. <gar...@ac...>]

Brian Paul wrote:
> 
> 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.

It's a rather nasty problem.  The solutions you proposed seems to be
okay, but I'll dig around and get back to you.  There may be other
issues that I've forgotten about, which I why I didn't just test for the
kernel version when I did that work.

-- Gareth

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:

 > The trick is there was a patch to Linux 2.2.x that added SSE so just
 > testing for kernel >= 2.4.0 isn't enough.  Does the presense of
 > X86_FXSR_MAGIC ensure that the _fpstate.magic field exists?

 Looking at the patch (2.4.0-test2), yes.  magic and X86_FXSR_MAGIC
 where introduced at the same time.

 I agree with you, stopping in the middle of the compilation isn't nice.
 The problem is you can't run something while generating the Makefiles
 from the Imakefiles, can you?  You just need to check that:

#include <signal.h>

#if defined(SSE_CHECK) && !defined(X86_FXSR_MAGIC)
#error "X86_FXSR_MAGIC not defined"
#endif

 doesn't produce an error.

-- 
Marcelo

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

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

"Marcelo E. Magallon" wrote:
> 
> >> 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.


I'd like to see a solution that doesn't interupt compilation.  That
is, if we can't use SSE at compile time, it should just be disabled,
perhaps with a warning.

The trick is there was a patch to Linux 2.2.x that added SSE so just
testing for kernel >= 2.4.0 isn't enough.  Does the presense of
X86_FXSR_MAGIC ensure that the _fpstate.magic field exists?

-Brian