Thread: [Plib-devel] [Fwd: [TuxKart-users] I have a compilation problem]
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
|
From: Steve B. <sjb...@ai...> - 2000-07-06 04:45:55
|
Steve Baker wrote:
>
> al wrote:
> Mandrake 7.1
> Glide_V3-2.60.15-3mdk.rpm & devel rpm
> Mesa3.2(compiled from source)
> plib-1.2.0-i586.rpm (NOT source)
> freeglut-alpha-1.3(source)
> VooDoo3 1000 AGP
...
> /usr/include/plib/sg.h:842: `FLT_MAX' undeclared (first use this function)
...
This seems to be related to the problem with FLT_EPSILON being undefined in some
places and <float.h> being "missing" sometimes.
Dunno if anyone can shed any light on this - but indeed, the classic C header
"/usr/include/float.h" is not present under my SuSE 6.4 system...and none of
the other headers in /usr/include or and of it's subdirectories seem to have
a definition for FLT_MAX.
In desperation, I wrote:
#include <math.h>
float x = FLT_MAX ;
...and ran:
% cpp test.c
...which suggested that the definition of FLT_MAX was in
"/usr/lib/gcc-lib/i486-suse-linux/2.95.2/include/float.h"
A SuSE specific directory?!? Yuck!
Can *anyone* tell me why this might be fouling up under
Mandrake 7.1?
The first couple of lines of /usr/include/plib/sg.h are:
#include <limits.h>
#include <math.h>
I've had to avoif doing a:
#include <float.h>
...under Linux *because* that file has ceased to exist in the 'normal' places.
My head hurts...somebody make it stop!
There must be some weird kind of magic going on inside the compiler
somewhere.
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Norman V. <nh...@ca...> - 2000-07-06 05:21:22
|
Steve Baker writes: >> > >> /usr/include/plib/sg.h:842: `FLT_MAX' undeclared (first use >this function) > >... > >This seems to be related to the problem with FLT_EPSILON being >undefined in some places and <float.h> being "missing" sometimes. > >Dunno if anyone can shed any light on this - but indeed, the >classic C header >"/usr/include/float.h" is not present under my SuSE 6.4 >system...and none of >the other headers in /usr/include or and of it's >subdirectories seem to have >a definition for FLT_MAX. > Steve, I went through this torment of not seeing float.h when I first started using gcc. Then one day I noticed that a program was complaining about conflicting with <float.h> after much searching I finally found it hiding in / lib / gcc-lib / i686-pc-cygwin / 2.95.2 / include I think that this is standard for gcc ( substitute your machine type for i686-pc-cygwin and 2.95.2 for your version of gcc in the above ) and that you can just include <float.h> and it will be automagically picked up. I believe the rationale behind this is that float.h is very compiler and machine specific and by doing it this way gcc can support cross-compiling and native-compiling on the same host :-) Cheers Norman |
|
From: Steve B. <sjb...@ai...> - 2000-07-06 06:19:50
|
Norman Vine wrote:
>
> Steve Baker writes:
> >>
> >
> >> /usr/include/plib/sg.h:842: `FLT_MAX' undeclared (first use
> >this function)
> >
> >...
> >
> >This seems to be related to the problem with FLT_EPSILON being
> >undefined in some places and <float.h> being "missing" sometimes.
> >
> >Dunno if anyone can shed any light on this - but indeed, the
> >classic C header
> >"/usr/include/float.h" is not present under my SuSE 6.4
> >system...and none of
> >the other headers in /usr/include or and of it's
> >subdirectories seem to have
> >a definition for FLT_MAX.
> >
>
> Steve,
>
> I went through this torment of not seeing float.h when I first started
> using gcc. Then one day I noticed that a program was complaining
> about conflicting with <float.h> after much searching I finally found
> it hiding in
>
> / lib / gcc-lib / i686-pc-cygwin / 2.95.2 / include
>
> I think that this is standard for gcc
> ( substitute your machine type for i686-pc-cygwin
> and 2.95.2 for your version of gcc in the above )
> and that you can just include <float.h> and it will be
> automagically picked up.
>
> I believe the rationale behind this is that float.h is very
> compiler and machine specific and by doing it this way
> gcc can support cross-compiling and native-compiling
> on the same host :-)
Yep - that make sense - so the compiler should know where the
magic include directory is. In your case it knows to look
in i686-pc-cygwin/2.95.2 - and in my case, it knows about
/usr/lib/gcc-lib/i486-suse-linux/2.95.2/include/float.h
...but how does it know that this is a SuSE Linux machine?
Our friend over on TuxKart-users (who is unfortunately
not a programmer) is getting complaints that you and I
don't see.
Perhaps this is a screwup in the Mandrake distro?
I hope not.
Are there any Mandrake users listening who could
check this out?
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Norman V. <nh...@ca...> - 2000-07-06 11:40:48
|
Steve Baker writes: > >Norman Vine wrote: >> > >> >> /usr/include/plib/sg.h:842: `FLT_MAX' undeclared (first use >> >this function) >> > <snip> >> >> I believe the rationale behind this is that float.h is very >> compiler and machine specific and by doing it this way >> gcc can support cross-compiling and native-compiling >> on the same host :-) > >Yep - that make sense - so the compiler should know where the >magic include directory is. In your case it knows to look >in i686-pc-cygwin/2.95.2 - and in my case, it knows about > >/usr/lib/gcc-lib/i486-suse-linux/2.95.2/include/float.h > >...but how does it know that this is a SuSE Linux machine? The machine type and version of the compiler is hardwired wired in at compile time. strings /bin/gcc.exe > jnk head -n 2 jnk // Not sure if these are always the first two strings 2.95.2 i686-pc-cygwin and gcc uses these to find the actual compiler tools and libc ect based on their path >Our friend over on TuxKart-users (who is unfortunately >not a programmer) is getting complaints that you and I >don't see. Isn't this problem solved if we just add to <sg.h> #include <float.h> ANSII guarantees that the compiler will be able to find <float.h> Cheers Norman |
|
From: Bernie B. <bb...@bi...> - 2000-07-06 11:45:43
|
Steve Baker wrote: > > Norman Vine wrote: > > > > Steve Baker writes: > > >> > > > > > >> /usr/include/plib/sg.h:842: `FLT_MAX' undeclared (first use > > >this function) > > > > > >... [snip] > > > > Steve, > > > > I went through this torment of not seeing float.h when I first started > > using gcc. Then one day I noticed that a program was complaining > > about conflicting with <float.h> after much searching I finally found > > it hiding in > > > > / lib / gcc-lib / i686-pc-cygwin / 2.95.2 / include > > [snip] > > Yep - that make sense - so the compiler should know where the > magic include directory is. In your case it knows to look > in i686-pc-cygwin/2.95.2 - and in my case, it knows about > > /usr/lib/gcc-lib/i486-suse-linux/2.95.2/include/float.h > > ...but how does it know that this is a SuSE Linux machine? > > Our friend over on TuxKart-users (who is unfortunately > not a programmer) is getting complaints that you and I > don't see. > > Perhaps this is a screwup in the Mandrake distro? > > I hope not. > > Are there any Mandrake users listening who could > check this out? Under my Mandrake 7.1 installation <float.h> is /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/include/float.h. Just updated my CVS source and it compiles fine. Bernie |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X