Thread
-
snapshot and FreeBSD-2.2.7 not building
Hal Snyder <hal@enteract.com> — 1999-01-02T22:34:31Z
The blizzard hitting the Chicago area makes today ideal for hacking - as long as the power stays on! A thousand pardons if this is a known problem - I'm just getting started with the current CVS set. I grabbed postgresql.snapshot.tar.gz for 8 am, Jan 2 and am trying to build it on my FreeBSD-2.2.7 system in order to test some things for the web site. This seems to be the only source kit available from hub's anonymous FTP archive, BTW. Here's what happens: ... gmake[2]: Entering directory `/pgsql-src/pgsql/src/backend/utils' for i in adt cache error fmgr hash init misc mmgr sort time; do gmake -C $i SUBSYS.o; done gmake[3]: Entering directory `/pgsql-src/pgsql/src/backend/utils/adt' gcc -I../../../include -I../../../backend -O2 -m486 -pipe -Wall -Wmissing-prototypes -I../.. -c numeric.c -o numeric.o numeric.c: In function `numeric_float8': numeric.c:1729: incompatible types in assignment numeric.c: In function `numeric_float4': numeric.c:1783: incompatible types in assignment gmake[3]: *** [numeric.o] Error 1 gmake[3]: Leaving directory `/pgsql-src/pgsql/src/backend/utils/adt' ... gmake[2]: *** No rule to make target `adt/SUBSYS.o', needed by `SUBSYS.o'. Stop. gmake[2]: Leaving directory `/pgsql-src/pgsql/src/backend/utils' gmake[1]: *** [utils.dir] Error 2 gmake[1]: Leaving directory `/pgsql-src/pgsql/src/backend' gmake: *** [all] Error 2 I think the compiler is right in claiming incompatible types. In rev 1.3 of backend/utils/adt/numeric.c, line 1783 says *result = num; but "result" is a float32 (=*float), while "num" is Numeric (pointer to a custom PostgreSQL NumericData struct). What is intended here? Hal
-
Re: [HACKERS] snapshot and FreeBSD-2.2.7 not building
Bruce Momjian <maillist@candle.pha.pa.us> — 1999-01-03T02:41:56Z
> The blizzard hitting the Chicago area makes today ideal for hacking - > as long as the power stays on! A thousand pardons if this is a known > problem - I'm just getting started with the current CVS set. > > I grabbed postgresql.snapshot.tar.gz for 8 am, Jan 2 and am trying to > build it on my FreeBSD-2.2.7 system in order to test some things for > the web site. This seems to be the only source kit available from > hub's anonymous FTP archive, BTW. > > Here's what happens: > > ... > gmake[2]: Entering directory `/pgsql-src/pgsql/src/backend/utils' > for i in adt cache error fmgr hash init misc mmgr sort time; do gmake -C $i SUBSYS.o; done > gmake[3]: Entering directory `/pgsql-src/pgsql/src/backend/utils/adt' > gcc -I../../../include -I../../../backend -O2 -m486 -pipe -Wall -Wmissing-prototypes -I../.. -c numeric.c -o numeric.o > numeric.c: In function `numeric_float8': > numeric.c:1729: incompatible types in assignment > numeric.c: In function `numeric_float4': > numeric.c:1783: incompatible types in assignment > gmake[3]: *** [numeric.o] Error 1 > gmake[3]: Leaving directory `/pgsql-src/pgsql/src/backend/utils/adt' > ... > gmake[2]: *** No rule to make target `adt/SUBSYS.o', needed by `SUBSYS.o'. Stop. > gmake[2]: Leaving directory `/pgsql-src/pgsql/src/backend/utils' > gmake[1]: *** [utils.dir] Error 2 > gmake[1]: Leaving directory `/pgsql-src/pgsql/src/backend' > gmake: *** [all] Error 2 > > I think the compiler is right in claiming incompatible types. In rev > 1.3 of backend/utils/adt/numeric.c, line 1783 says > > *result = num; > > but "result" is a float32 (=*float), while "num" is Numeric (pointer > to a custom PostgreSQL NumericData struct). What is intended here? OK, I have applied a patch to the cvs tree. My old code was clearly wrong, now that I study it. I am now generating NAN by: double x; return (x-x)/(x-x); This seems to be the way my libm math library does it. The gcc2 -O4 compile does not seem to optimize it away, so looks like it will work. My guess is that the compiler can not optimize floating-point computations. Still waiting for Jan to give me his comments on my fixes, but it is holiday time. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
Re: [HACKERS] snapshot and FreeBSD-2.2.7 not building
Bruce Momjian <maillist@candle.pha.pa.us> — 1999-01-03T02:54:10Z
> I am now generating NAN by: > > double x=1; ^^ > > return (x-x)/(x-x); Forgot the =1. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 -
Re: [HACKERS] snapshot and FreeBSD-2.2.7 not building
Hal Snyder <hal@enteract.com> — 1999-01-03T03:50:57Z
Bruce Momjian <maillist@candle.pha.pa.us> writes: > I am now generating NAN by: > > double x; > > return (x-x)/(x-x); > > This seems to be the way my libm math library does it. The gcc2 -O4 > compile does not seem to optimize it away, so looks like it will work. > My guess is that the compiler can not optimize floating-point > computations. Thanks for the follow-up. Suggestion: At the top of numeric.c or in include/utils/numeric.h, put #ifndef NAN #define pgNAN (0.0/0.0) #endif Then in numeric.c, if NAN isn't defined, return pgNAN; -- Hal
-
Re: [HACKERS] snapshot and FreeBSD-2.2.7 not building
Bruce Momjian <maillist@candle.pha.pa.us> — 1999-01-03T05:30:09Z
> Thanks for the follow-up. Suggestion: > > At the top of numeric.c or in include/utils/numeric.h, put > > #ifndef NAN > #define pgNAN (0.0/0.0) > #endif > > Then in numeric.c, if NAN isn't defined, Done. Used: #ifndef NAN #define NAN (0.0/0.0) #endif at the top of numeric.c, and removed my other #ifdef's. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
Re: [HACKERS] snapshot and FreeBSD-2.2.7 not building
orion.sapserv.hamburg.dsh.de!wieck@sapserv.debis.de — 1999-01-04T08:33:27Z
> > > Thanks for the follow-up. Suggestion: > > > > At the top of numeric.c or in include/utils/numeric.h, put > > > > #ifndef NAN > > #define pgNAN (0.0/0.0) > > #endif > > > > Then in numeric.c, if NAN isn't defined, > > Done. Used: > > #ifndef NAN > #define NAN (0.0/0.0) > #endif > > at the top of numeric.c, and removed my other #ifdef's. I hope this is portable and none of our supported platforms throws in a SIGFPE for it (cross fingers). OTOH it might be good to have configure checks if NAN is defined somewhere and include that header. Only if it isn't defined we should fallback to the above. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] snapshot and FreeBSD-2.2.7 not building
Jan Wieck <jwieck@debis.com> — 1999-01-04T08:33:28Z
> > > Thanks for the follow-up. Suggestion: > > > > At the top of numeric.c or in include/utils/numeric.h, put > > > > #ifndef NAN > > #define pgNAN (0.0/0.0) > > #endif > > > > Then in numeric.c, if NAN isn't defined, > > Done. Used: > > #ifndef NAN > #define NAN (0.0/0.0) > #endif > > at the top of numeric.c, and removed my other #ifdef's. I hope this is portable and none of our supported platforms throws in a SIGFPE for it (cross fingers). OTOH it might be good to have configure checks if NAN is defined somewhere and include that header. Only if it isn't defined we should fallback to the above. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) #