Re: Undefined identifiers for alphaev6-dec-osf4.0e

[Tim Mooney <mooney at dogbert dot cc dot ndsu dot nodak dot edu>]

In regard to: Re: Undefined identifiers for alphaev6-dec-osf4.0e, Brian...:

>The man pages for read_rnd and write_rnd might give some
>information... I would expect the macros to be defined somewhere in
>#include <machine/fpu.h>. I have cc'ed this message the original
>author of the fp-tru64.c file.

Thanks for cc'ing me Brian!

Ramin-

The definitions for FP_RND_R{N,M,P,Z} are in /usr/include/float.h on all
the Digital Unix and Tru64 Unix machines I have access to.  fp-tru64.c is
including that file.  Do you have that file?  It's part of OSFINCLUDE440
(440 == 4.0f, which is what I run on my workstation).

You're using gcc, so the most likely problem is that gcc's "fixed" (yeah,
right) header directories contain a float.h that does *not* have the necessary
definitions.  Because gcc searches its "fixed" headers first, it won't
find /usr/include/float.h (assuming you have that installed, but I have
to believe you do or you wouldn't have gotten this far) if there's a float.h
under the gcc fixed headers dir.

When I wrote fp-tru64.c, I tested both with Compaq's compiler and with gcc.
At the time, that was gcc 2.8.1.  Everything I tested (mainly the build)
worked correctly.  On my machine with 2.8.1 there is no "fixed" float.h,
so gcc finds /usr/include/float.h and all is well.

I just looked at gcc 2.95.1 and gcc 2.95.2, and both of them have a "fixed"
float.h, though based on what I see I don't think the float.h was even
generated from the system float.h, which seems pretty weird.  In any case,
the float.h that 2.95.1 and 2.95.2 provide does *not* include *many*
defines that are part of /usr/include/float.h, so it's quite clear that
any routine that requires anything beyond the bare minimum of defines from
float.h will *not* work with the float.h that is generated as part of the
gcc 2.95.1 or 2.95.2 build.  Compare float.h from gcc's header files to
/usr/include/float.h to see what I mean.

Perhaps this is a problem in the way that I (and you too, apparently) have
built gcc 2.95.N, or maybe it's a bug in gcc's build process.  In any case,
the problem isn't with gsl, it's with the headers that are part of gcc.

After investigating your system, do you agree with my conclusion?

>
>regards
>Brian Gough
>
>Nakisa, Ramin writes:
> > Hi,
> > 
> > I'm using the latest CVS version of gsl (although I tried gsl-0.5 too) and
> > got the following compilation error:
> > 
> > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./.. -I./../err -mieee
> > -mfp-rounding-mode=d -g -O2 -Wp,-MD,.deps/fp.pp -c  -DPIC fp.c -o
> > .libs/fp.lo
> > In file included from fp.c:14:
> > fp-tru64.c: In function `gsl_ieee_set_mode':
> > fp-tru64.c:60: `FP_RND_RN' undeclared (first use in this function)
> > fp-tru64.c:60: (Each undeclared identifier is reported only once
> > fp-tru64.c:60: for each function it appears in.)
> > fp-tru64.c:64: `FP_RND_RM' undeclared (first use in this function)
> > fp-tru64.c:68: `FP_RND_RP' undeclared (first use in this function)
> > fp-tru64.c:72: `FP_RND_RZ' undeclared (first use in this function)
> > make[2]: *** [fp.lo] Error 1
> > 
> > Nobody else seems to have mentioned this in the gsl-discuss mailing list. I
> > can't seem to find definitions for FP_RND_RN in any header files. Where are
> > these defined?
> > 
> > Thanks,
> > 
> > Ramin Nakisa.
> > 
>

-- 
Tim Mooney                              mooney@dogbert.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J1, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164