Thread: Postgres 6.5.1 on Slackware 4.0
Hi, I just compiled and installed Postgres 6.5.1 on Slackware 4.0 (kernel 2.2.6, cpu: PIII@450) whithout changing anything on the code. The regression tests had some strange failures, so i'm sending you the .out and .diff files. Thanks for your efforts on Postgres, T. -- Theodore=J.=Soldatos=_\_="There=is=always=a=bug=somewhere",=said==HAL=to=the== = theodore@eexi.gr =_/_==Ultimate=Programmer,=and=turned=off=the=air=supply.= = bafh@hellug.gr =_\_="Everybody=knows=the=war=is=over,==================== ==== Scientific =====_/_==everybody=knows=the=good=guys=lost"===Leonard=Cohen= = Publications Ltd. =_\_============ http://w4u.eexi.gr/~theodore ============ ==== Finger: theodore@msfree.scientificpublications.gr or @aurora.eexi.gr =================== Notes... ================= postmaster must already be running for the regression tests to succeed. The time zone is now set to PST8PDT explicitly by this regression test client frontend. Please report any apparent problems to ports@postgresql.org See regress/README for more information. =============== destroying old regression database... ================= ERROR: destroydb: database 'regression' does not exist destroydb: database destroy failed on regression. =============== creating new regression database... ================= =============== installing PL/pgSQL... ================= =============== running regression queries... ================= boolean .. ok char .. ok name .. ok varchar .. ok text .. ok strings .. ok int2 .. failed int4 .. failed int8 .. ok oid .. ok float4 .. ok float8 .. ok numerology .. ok point .. ok lseg .. ok box .. ok path .. ok polygon .. ok circle .. ok geometry .. ok timespan .. ok datetime .. ok reltime .. ok abstime .. ok tinterval .. ok horology .. ok inet .. ok comments .. ok oidjoins .. ok type_sanity .. ok opr_sanity .. ok create_function_1 .. ok create_type .. ok create_table .. ok create_function_2 .. ok constraints .. ok triggers .. ok copy .. ok create_misc .. ok create_aggregate .. ok create_operator .. ok create_view .. ok create_index .. ok sanity_check .. ok errors .. ok select .. ok select_into .. ok select_distinct .. ok select_distinct_on .. ok select_implicit .. ok select_having .. ok subselect .. ok union .. ok case .. ok join .. ok aggregates .. ok transactions .. ok random .. failed portals .. ok misc .. ok arrays .. ok btree_index .. ok hash_index .. ok select_views .. ok alter_table .. ok portals_p2 .. ok rules .. ok limit .. ok plpgsql .. ok temp .. ok numeric .. ok *** expected/int2.out Thu Apr 15 05:15:35 1999 --- results/int2.out Tue Aug 31 17:15:35 1999 *************** *** 7,13 **** QUERY: INSERT INTO INT2_TBL(f1) VALUES ('32767'); QUERY: INSERT INTO INT2_TBL(f1) VALUES ('-32767'); QUERY: INSERT INTO INT2_TBL(f1) VALUES ('100000'); ! ERROR: pg_atoi: error reading "100000": Numerical result out of range QUERY: INSERT INTO INT2_TBL(f1) VALUES ('asdf'); ERROR: pg_atoi: error in "asdf": can't parse "asdf" QUERY: SELECT '' AS five, INT2_TBL.*; --- 7,13 ---- QUERY: INSERT INTO INT2_TBL(f1) VALUES ('32767'); QUERY: INSERT INTO INT2_TBL(f1) VALUES ('-32767'); QUERY: INSERT INTO INT2_TBL(f1) VALUES ('100000'); ! ERROR: pg_atoi: error reading "100000": Math result not representable QUERY: INSERT INTO INT2_TBL(f1) VALUES ('asdf'); ERROR: pg_atoi: error in "asdf": can't parse "asdf" QUERY: SELECT '' AS five, INT2_TBL.*; ---------------------- *** expected/int4.out Thu Apr 15 05:15:36 1999 --- results/int4.out Tue Aug 31 17:15:36 1999 *************** *** 7,13 **** QUERY: INSERT INTO INT4_TBL(f1) VALUES ('2147483647'); QUERY: INSERT INTO INT4_TBL(f1) VALUES ('-2147483647'); QUERY: INSERT INTO INT4_TBL(f1) VALUES ('1000000000000'); ! ERROR: pg_atoi: error reading "1000000000000": Numerical result out of range QUERY: INSERT INTO INT4_TBL(f1) VALUES ('asdf'); ERROR: pg_atoi: error in "asdf": can't parse "asdf" QUERY: SELECT '' AS five, INT4_TBL.*; --- 7,13 ---- QUERY: INSERT INTO INT4_TBL(f1) VALUES ('2147483647'); QUERY: INSERT INTO INT4_TBL(f1) VALUES ('-2147483647'); QUERY: INSERT INTO INT4_TBL(f1) VALUES ('1000000000000'); ! ERROR: pg_atoi: error reading "1000000000000": Math result not representable QUERY: INSERT INTO INT4_TBL(f1) VALUES ('asdf'); ERROR: pg_atoi: error in "asdf": can't parse "asdf" QUERY: SELECT '' AS five, INT4_TBL.*; ---------------------- *** expected/random.out Mon Aug 17 19:11:15 1998 --- results/random.out Tue Aug 31 17:17:13 1999 *************** *** 19,23 **** WHERE random NOT BETWEEN 80 AND 120; random ------ ! (0 rows) --- 19,25 ---- WHERE random NOT BETWEEN 80 AND 120; random ------ ! 125 ! 128 ! (2 rows) ----------------------
There is a problem with libpq++.so on IRIX 6.5 (MIPSpro 7.2.1, -n32).
If you compile and link a simple program like the following:
#include "libpq++/pgdatabase.h"
main(int argc, char **argv)
{
PgDatabase *db = new PgDatabase("dbname=mydb");
db->Exec("SELECT * FROM TEST");
db->PrintTuples();
delete db;
}
and run it, you'll get the following error:
46407:./a.out: rld: Error: unresolvable symbol in
/5xxRoot/ALG/pgsql/lib/libpq++.so.3.0:
__node_allocator_lock__Q2_3std45__default_alloc_template__pt__13_XCbL11XCiL10
46407:./a.out: rld: Error: unresolvable symbol in
/5xxRoot/ALG/pgsql/lib/libpq++.so.3.0:
free_list__Q2_3std45__default_alloc_template__pt__13_XCbL11XCiL10
46407:./a.out: rld: Fatal Error: this executable has unresolvable symbols
I think this has to do with some quirks of the SGI MIPSpro compiler when
creating libraries for C++. For shared library, instead of "ld -shared",
"CC -shared" should be used to enable pre-linking (for template
instantiation). And for static library, "CC -ar" should be used instead
of "ar" (although right now if I use the static library the run-time error
does not occur).
I'm not sure whether using "CC" to create libraries for the pure C
modules would work (my guess is it should and I'll try it). If it does
then it'll be easy to patch the IRIX makefile template. But then the
downside is people will be required to have the C++ compiler even if
they don't care about libpq++.
--Yu Cao
************
Yu Cao <yucao@falcon.kla-tencor.com> writes:
> I'm not sure whether using "CC" to create libraries for the pure C
> modules would work (my guess is it should and I'll try it). If it does
> then it'll be easy to patch the IRIX makefile template. But then the
> downside is people will be required to have the C++ compiler even if
> they don't care about libpq++.
Not necessarily. Since 6.4 or so, the "template" files are not just
static assignments of variable values --- they can actually contain
arbitrary fragments of shell script (see configure.in's code that
reads them). So you could do something like
if [ -x /usr/bin/CC ]
then
CC= CC
else
CC= cc
fi
in the IRIX template.
regards, tom lane
There is a problem with libpq++.so on IRIX 6.5 (MIPSpro 7.2.1, -n32).
If you compile and link a simple program like the following:
#include "libpq++/pgdatabase.h"
main(int argc, char **argv)
{
PgDatabase *db = new PgDatabase("dbname=mydb");
db->Exec("SELECT * FROM TEST");
db->PrintTuples();
delete db;
}
and run it, you'll get the following error:
46407:./a.out: rld: Error: unresolvable symbol in
/5xxRoot/ALG/pgsql/lib/libpq++.so.3.0:
__node_allocator_lock__Q2_3std45__default_alloc_template__pt__13_XCbL11XCiL10
46407:./a.out: rld: Error: unresolvable symbol in
/5xxRoot/ALG/pgsql/lib/libpq++.so.3.0:
free_list__Q2_3std45__default_alloc_template__pt__13_XCbL11XCiL10
46407:./a.out: rld: Fatal Error: this executable has unresolvable symbols
I think this has to do with some quirks of the SGI MIPSpro compiler when
creating libraries for C++. For shared library, instead of "ld -shared",
"CC -shared" should be used to enable pre-linking (for template
instantiation). And for static library, "CC -ar" should be used instead
of "ar" (although right now if I use the static library the run-time error
does not occur).
I'm not sure whether using "CC" to create libraries for the pure C
modules would work (my guess is it should and I'll try it). If it does
then it'll be easy to patch the IRIX makefile template. But then the
downside is people will be required to have the C++ compiler even if
they don't care about libpq++.
--Yu Cao
************
Hi Tom, thanks for the tip. I ended up just adding a few lines to
Makefile.shlib. Attached is the context diff. The patch has been
tested on IRIX 6.5.2 with MIPSpro C and C++ compiler version 7.2.1
using -n32 ABI.
--Yu Cao
On Sat, 4 Sep 1999, Tom Lane wrote:
> Yu Cao <yucao@falcon.kla-tencor.com> writes:
> > I'm not sure whether using "CC" to create libraries for the pure C
> > modules would work (my guess is it should and I'll try it). If it does
> > then it'll be easy to patch the IRIX makefile template. But then the
> > downside is people will be required to have the C++ compiler even if
> > they don't care about libpq++.
>
> Not necessarily. Since 6.4 or so, the "template" files are not just
> static assignments of variable values --- they can actually contain
> arbitrary fragments of shell script (see configure.in's code that
> reads them). So you could do something like
> if [ -x /usr/bin/CC ]
> then
> CC= CC
> else
> CC= cc
> fi
> in the IRIX template.
>
> regards, tom lane
>
> ************
>
>
>
*** Makefile.shlib.orig Sun Sep 5 23:30:36 1999
--- Makefile.shlib Sun Sep 5 23:41:09 1999
***************
*** 61,66 ****
--- 61,72 ----
shlib := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
LDFLAGS_SL := -shared
CFLAGS += $(CFLAGS_SL)
+ ifeq ($(NAME), pq++)
+ AR := CC
+ AROPT := -ar -o
+ LD := CC
+ LDFLAGS_SL := -shared
+ endif
endif
ifeq ($(PORTNAME), freebsd)
Yu Cao <yucao@falcon.kla-tencor.com> writes:
> Hi Tom, thanks for the tip. I ended up just adding a few lines to
> Makefile.shlib. Attached is the context diff. The patch has been
> tested on IRIX 6.5.2 with MIPSpro C and C++ compiler version 7.2.1
> using -n32 ABI.
That fix bothers me, because it would interfere with someone trying
to use gcc/g++, wouldn't it? Seems safer to just alter configure's
default...
regards, tom lane
That's a good point (about interfering with gcc/g++). But I'm still a bit hesitant about changing the default AR and LD for all other libraries (although in theory it shouldn't do any harm). And if we changed the default, gcc/g++ users (who happen to have CC installed on their system) would again have to find a way to override it. So attached is another try: I put the mods in interfaces/libpq++/Makefile.in. That file already had some checks on PORTNAME (for windows) and CXX (for g++), so it seems adding more checks (for irix5 and CC) doesn't make it uglier and also gets the job done with minimal impact on other things. --Yu Cao On Mon, 6 Sep 1999, Tom Lane wrote: > Yu Cao <yucao@falcon.kla-tencor.com> writes: > > Hi Tom, thanks for the tip. I ended up just adding a few lines to > > Makefile.shlib. Attached is the context diff. The patch has been > > tested on IRIX 6.5.2 with MIPSpro C and C++ compiler version 7.2.1 > > using -n32 ABI. > > That fix bothers me, because it would interfere with someone trying > to use gcc/g++, wouldn't it? Seems safer to just alter configure's > default... *** interfaces/libpq++/Makefile.in.orig Mon Sep 6 16:05:01 1999 --- interfaces/libpq++/Makefile.in Mon Sep 6 16:10:15 1999 *************** *** 48,53 **** --- 48,61 ---- SHLIB_LINK= -L../libpq -lpq endif + ifeq ($(PORTNAME), irix5) + ifeq ($(CXX), CC) + AR = CC + AROPT = -ar -o + LD = CC + endif + endif + # Shared library stuff, also default 'all' target include $(SRCDIR)/Makefile.shlib
Yu Cao <yucao@falcon.kla-tencor.com> writes:
> attached is another try: I put the mods in interfaces/libpq++/Makefile.in.
> That file already had some checks on PORTNAME (for windows) and CXX (for
> g++), so it seems adding more checks (for irix5 and CC) doesn't make it
> uglier and also gets the job done with minimal impact on other things.
That looks good to me; will commit it. Thanks.
regards, tom lane