Thread: Re: pgsql + qnx
Am 09:47 21.05.01 +0200 schrieb Kamil Parkanyi: >Hello, > >I hope this e-mail will find you... Yes, I' here :-; > > >---------- >I sent e-mail to <mailto:kardos@repas-aeg.de>kardos@repas-aeg.de but it >returned as undeliverable >---- Recipients of this delivery ---- Anreas has left and is no longer involved with postgres on QNX4. ><<mailto:kardos@dragon.dr.repas.de>kardos@dragon.dr.repas.de> (bounced) > >---------- >I've tried to port postgresql-7.1 to my QNX 4.25 system. >I read FAQ_QNX. >I have Watcom 10.6, Bison 1.28, Flex 2.5.4, Perl 5.6.0, TCP/IP 4.25 for QNX >/usr/local/ld is link to wlink >so I run >./configure --enable-odbc >make I haven't tried building postgres with the Watcom compiler for 7.1 because it does not support 64bit integers. AFAIK that's the default data type for OIDs, so I am not surprised that this does not work. Use gcc instead. BTW., 7.1 does not compile as is with gcc either, I believed the required patches made it into the 7.1.1 release but obviously I missed the deadline. Since the ports mailing list does not seem to be archived I have attached a copy of the patch (for 7.1 and 7.1.1). Are you trying to use odbc on qnx ? If so, I'd be interested in the results. I am not aware of anyone having done this before. > >/usr/watcom/10.6/bin/wcc386 -zq -i=../../../../src/include -ms -4r >-i=/usr/watcom/10.6/usr/include -i=/usr/include tuptoaster.c >tuptoaster.c(892): Error! E1011: Symbol 'F_OIDEQ' has not been declared >tuptoaster.c(983): Error! E1011: Symbol 'F_OIDEQ' has not been declared >cc: /usr/watcom/10.6/bin/wcc386 exited 2 >make[4]: *** [tuptoaster.o] Error 2 >make[4]: Leaving directory >`/home/Parkanyi/Skusobne/postgresql-7.1/src/backend/access/heap' > >***** >I found on the Internet that this is often compilation error and that in >fmgr.h should be >#define F_OIDEQ 184 >I have only one fmgr.h file in src/include directory so I've added it there >***** > >make > >cc -I../../../src/include -c bootstrap.c >/usr/watcom/10.6/bin/wcc386 -zq -i=../../../src/include -ms -4r >-i=/usr/watcom/10.6/usr/include -i=/usr/include bootstrap.c >bootstrap.c(103): Error! E1011: Symbol 'F_BOOLIN' has not been declared <snip> >bootstrap.c(107): Error! E1011: Symbol 'F_INT2OUT' has not been declared >bootstrap.c(107): Error! E1054: Expression must be constant >bootstrap.c(108): Error! E1147: Too many errors: compilation aborted >cc: /usr/watcom/10.6/bin/wcc386 exited 1 >make[3]: *** [bootstrap.o] Error 1 >make[3]: Leaving directory >`/home/Parkanyi/Skusobne/postgresql-7.1/src/backend/bootstrap' > >Untill bootstrap.c the compilation was with no error. >Where I made mistake? >Why there is not definition of symbols above? These constants should be defined in fmgroids.h which should have been generated by src/backend/utils/Gen_fmgrtab.sh. I don't know why it did not work. PS: you can find a plain vanilla binary at http://pweb.uunet.de/tegge.h/
Attachment
Tegge, Bernd writes: > I haven't tried building postgres with the Watcom compiler for 7.1 because > it does not support 64bit integers. AFAIK that's the default data type for > OIDs, Oids are 32 bits, 'unsigned int' to be precise. Support for 64 bit integers is completely optional in PostgreSQL. > BTW., 7.1 does not compile as is with gcc either, I believed the > required patches made it into the 7.1.1 release but obviously I missed > the deadline. I don't think they made that one either. > Since the ports mailing list does not seem to be archived I have attached > a copy of the patch (for 7.1 and 7.1.1). http://www.ca.postgresql.org/mhonarc/pgsql-ports/ > >cc -I../../../src/include -c bootstrap.c > >/usr/watcom/10.6/bin/wcc386 -zq -i=../../../src/include -ms -4r > >-i=/usr/watcom/10.6/usr/include -i=/usr/include bootstrap.c > >bootstrap.c(103): Error! E1011: Symbol 'F_BOOLIN' has not been declared I keep seeing these. If anyone got a clue, let us know. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut <peter_e@gmx.net> writes:
> cc -I../../../src/include -c bootstrap.c
> /usr/watcom/10.6/bin/wcc386 -zq -i=../../../src/include -ms -4r
> -i=/usr/watcom/10.6/usr/include -i=/usr/include bootstrap.c
> bootstrap.c(103): Error! E1011: Symbol 'F_BOOLIN' has not been declared
> I keep seeing these. If anyone got a clue, let us know.
F_BOOLIN should be supplied from fmgroids.h, which is built on-the-fly
by backend/utils/Gen_fmgrtab.sh. Probably what we have here is (a)
platform dependent failure of that script ('cat' not installed, or
some such), and (b) insufficient error checking in the script, so
it doesn't realize it's failed to build the file.
regards, tom lane
At 16:59 21.05.01 +0200, Peter Eisentraut wrote: >Tegge, Bernd writes: > > > I haven't tried building postgres with the Watcom compiler for 7.1 because > > it does not support 64bit integers. AFAIK that's the default data type for > > OIDs, > >Oids are 32 bits, 'unsigned int' to be precise. Support for 64 bit >integers is completely optional in PostgreSQL. I was under the impression that OIDs and SEQUENCEs are required to be 64 bit and 32 bit versions are not really supported. I may have a look at using the Watcom compiler again. > > BTW., 7.1 does not compile as is with gcc either, I believed the > > required patches made it into the 7.1.1 release but obviously I missed > > the deadline. > >I don't think they made that one either. > > > Since the ports mailing list does not seem to be archived I have attached > > a copy of the patch (for 7.1 and 7.1.1). > >http://www.ca.postgresql.org/mhonarc/pgsql-ports/ Thanks, I started at http://www.postgresql.org/search.mpl or http://www.ca.postgresql.org/devel-corner/index.html and couldn't find a path to the archive. > > >cc -I../../../src/include -c bootstrap.c > > >/usr/watcom/10.6/bin/wcc386 -zq -i=../../../src/include -ms -4r > > >-i=/usr/watcom/10.6/usr/include -i=/usr/include bootstrap.c > > >bootstrap.c(103): Error! E1011: Symbol 'F_BOOLIN' has not been declared > >I keep seeing these. If anyone got a clue, let us know. Maybe Kamil can tell us more. >-- >Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it withing the next 48 hours.
> Am 09:47 21.05.01 +0200 schrieb Kamil Parkanyi:
> >Hello,
> >
> >I hope this e-mail will find you...
>
> Yes, I' here :-;
>
> >
> >
> >----------
> >I sent e-mail to <mailto:kardos@repas-aeg.de>kardos@repas-aeg.de but it
> >returned as undeliverable
> >---- Recipients of this delivery ----
>
> Anreas has left and is no longer involved with postgres on QNX4.
>
> ><<mailto:kardos@dragon.dr.repas.de>kardos@dragon.dr.repas.de> (bounced)
> >
> >----------
> >I've tried to port postgresql-7.1 to my QNX 4.25 system.
> >I read FAQ_QNX.
> >I have Watcom 10.6, Bison 1.28, Flex 2.5.4, Perl 5.6.0, TCP/IP 4.25 for QNX
> >/usr/local/ld is link to wlink
> >so I run
> >./configure --enable-odbc
> >make
>
> I haven't tried building postgres with the Watcom compiler for 7.1 because
> it does not support 64bit integers. AFAIK that's the default data type for
> OIDs, so I am not surprised that this does not work. Use gcc instead.
> BTW., 7.1 does not compile as is with gcc either, I believed the
> required patches made it into the 7.1.1 release but obviously I missed
> the deadline.
> Since the ports mailing list does not seem to be archived I have attached
> a copy of the patch (for 7.1 and 7.1.1).
>
> Are you trying to use odbc on qnx ? If so, I'd be interested in the
> results. I am not aware of anyone having done this before.
>
> >
> >/usr/watcom/10.6/bin/wcc386 -zq -i=../../../../src/include -ms -4r
> >-i=/usr/watcom/10.6/usr/include -i=/usr/include tuptoaster.c
> >tuptoaster.c(892): Error! E1011: Symbol 'F_OIDEQ' has not been declared
> >tuptoaster.c(983): Error! E1011: Symbol 'F_OIDEQ' has not been declared
> >cc: /usr/watcom/10.6/bin/wcc386 exited 2
> >make[4]: *** [tuptoaster.o] Error 2
> >make[4]: Leaving directory
> >`/home/Parkanyi/Skusobne/postgresql-7.1/src/backend/access/heap'
> >
> >*****
> >I found on the Internet that this is often compilation error and that in
> >fmgr.h should be
> >#define F_OIDEQ 184
> >I have only one fmgr.h file in src/include directory so I've added it there
> >*****
> >
> >make
> >
> >cc -I../../../src/include -c bootstrap.c
> >/usr/watcom/10.6/bin/wcc386 -zq -i=../../../src/include -ms -4r
> >-i=/usr/watcom/10.6/usr/include -i=/usr/include bootstrap.c
> >bootstrap.c(103): Error! E1011: Symbol 'F_BOOLIN' has not been declared
>
> <snip>
>
> >bootstrap.c(107): Error! E1011: Symbol 'F_INT2OUT' has not been declared
> >bootstrap.c(107): Error! E1054: Expression must be constant
> >bootstrap.c(108): Error! E1147: Too many errors: compilation aborted
> >cc: /usr/watcom/10.6/bin/wcc386 exited 1
> >make[3]: *** [bootstrap.o] Error 1
> >make[3]: Leaving directory
> >`/home/Parkanyi/Skusobne/postgresql-7.1/src/backend/bootstrap'
> >
> >Untill bootstrap.c the compilation was with no error.
> >Where I made mistake?
> >Why there is not definition of symbols above?
>
> These constants should be defined in fmgroids.h which should have
> been generated by src/backend/utils/Gen_fmgrtab.sh. I don't know why
> it did not work.
>
> PS: you can find a plain vanilla binary at http://pweb.uunet.de/tegge.h/
[ Attachment, skipping... ]
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
--
Bruce Momjian | http://candle.pha.pa.us
pgman@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
> Peter Eisentraut <peter_e@gmx.net> writes:
> > cc -I../../../src/include -c bootstrap.c
> > /usr/watcom/10.6/bin/wcc386 -zq -i=../../../src/include -ms -4r
> > -i=/usr/watcom/10.6/usr/include -i=/usr/include bootstrap.c
> > bootstrap.c(103): Error! E1011: Symbol 'F_BOOLIN' has not been declared
>
> > I keep seeing these. If anyone got a clue, let us know.
>
> F_BOOLIN should be supplied from fmgroids.h, which is built on-the-fly
> by backend/utils/Gen_fmgrtab.sh. Probably what we have here is (a)
> platform dependent failure of that script ('cat' not installed, or
> some such), and (b) insufficient error checking in the script, so
> it doesn't realize it's failed to build the file.
I just checked Gen_fmgrtab.sh and it has error checking all over the
place. I would be curious to know how it could fail and not exit with
non-zero.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@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
At 00:33 22.05.01 -0400, Bruce Momjian wrote:
> > Peter Eisentraut <peter_e@gmx.net> writes:
> > > cc -I../../../src/include -c bootstrap.c
> > > /usr/watcom/10.6/bin/wcc386 -zq -i=../../../src/include -ms -4r
> > > -i=/usr/watcom/10.6/usr/include -i=/usr/include bootstrap.c
> > > bootstrap.c(103): Error! E1011: Symbol 'F_BOOLIN' has not been declared
> >
> > > I keep seeing these. If anyone got a clue, let us know.
> >
> > F_BOOLIN should be supplied from fmgroids.h, which is built on-the-fly
> > by backend/utils/Gen_fmgrtab.sh. Probably what we have here is (a)
> > platform dependent failure of that script ('cat' not installed, or
> > some such), and (b) insufficient error checking in the script, so
> > it doesn't realize it's failed to build the file.
>
>I just checked Gen_fmgrtab.sh and it has error checking all over the
>place. I would be curious to know how it could fail and not exit with
>non-zero.
The Watcom preprocessor adds a space at the start of each line. Therefore
the output of "egrep '^[0-9]' " is empty. Changing the pattern to
"egrep '^[ ]*[0-9]" generates the correct file.
> >I just checked Gen_fmgrtab.sh and it has error checking all over the > >place. I would be curious to know how it could fail and not exit with > >non-zero. > > The Watcom preprocessor adds a space at the start of each line. Therefore > the output of "egrep '^[0-9]' " is empty. Changing the pattern to > "egrep '^[ ]*[0-9]" generates the correct file. Makes sense and seems safe enough. Applied. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
At 00:33 22.05.01 -0400, Bruce Momjian wrote: >Subject: Re: [PORTS] Re: pgsql + qnx >To: "Tegge, Bernd" <tegge@repas-aeg.de> >CC: Kamil Parkanyi <parkanyi@procaut.sk>, pgsql-ports@postgresql.org > > >Your patch has been added to the PostgreSQL unapplied patches list at: > > http://candle.pha.pa.us/cgi-bin/pgpatches > >I will try to apply it withing the next 48 hours. I've just performed a build of a Watcom compiled version and found a couple of bugs in the watcom specific part of that patch. Please use the attached version instead. The watcom version fails 3 additional regression tests, at least one (int8) expected; I have not looked at the other ones.
Attachment
Got it. > At 00:33 22.05.01 -0400, Bruce Momjian wrote: > >Subject: Re: [PORTS] Re: pgsql + qnx > >To: "Tegge, Bernd" <tegge@repas-aeg.de> > >CC: Kamil Parkanyi <parkanyi@procaut.sk>, pgsql-ports@postgresql.org > > > > > >Your patch has been added to the PostgreSQL unapplied patches list at: > > > > http://candle.pha.pa.us/cgi-bin/pgpatches > > > >I will try to apply it withing the next 48 hours. > I've just performed a build of a Watcom compiled version and found a couple > of bugs in the watcom specific part of that patch. Please use the attached > version instead. > The watcom version fails 3 additional regression tests, at least one (int8) > expected; I have not looked at the other ones. [ Attachment, skipping... ] -- Bruce Momjian | http://candle.pha.pa.us pgman@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
Tegge, Bernd writes: > I've just performed a build of a Watcom compiled version and found a couple > of bugs in the watcom specific part of that patch. Please use the attached > version instead. > The watcom version fails 3 additional regression tests, at least one (int8) > expected; I have not looked at the other ones. I don't like the Makefile.qnx4 and plpgsql/Makefile parts of this patch: ! override CXXFLAGS +=-I/usr/local/include/g++ ! override CFLAGS +=-I/usr/local/include The first line looks like a broken compiler installation. The second line should, if at all, go into the template file. But I don't like us using arbitrary include paths. If the compiler vendor decides to not go there by default they had a reason. In any case there would be an equivalent LDFLAGS setting missing. Also, -I options should go into CPPFLAGS. The plpgsql issue should be fixed by making the ifneq ($(enable_shared),yes) sections in plpgsql/src/Makefile cover the parts you don't want to execute. That's what it is for, it just hasn't been exercised yet. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
At 16:51 22.05.01 +0200, Peter Eisentraut wrote: >Tegge, Bernd writes: > > > I've just performed a build of a Watcom compiled version and found a couple > > of bugs in the watcom specific part of that patch. Please use the attached > > version instead. > > The watcom version fails 3 additional regression tests, at least one (int8) > > expected; I have not looked at the other ones. > >I don't like the Makefile.qnx4 and plpgsql/Makefile parts of this patch: > >! override CXXFLAGS +=-I/usr/local/include/g++ >! override CFLAGS +=-I/usr/local/include > >The first line looks like a broken compiler installation. The second line >should, if at all, go into the template file. But I don't like us using >arbitrary include paths. If the compiler vendor decides to not go there >by default they had a reason. In any case there would be an equivalent >LDFLAGS setting missing. Also, -I options should go into CPPFLAGS. Could you elaborate ? I am not sure which template file you refer to. In case you are thinking of the gcc installation, I guess they could be scrapped. However, Watcom does not search these directories by default. In fact, IIRC a OOB QNX4 install does not even *have* a '/usr/local'. I have included this because TCL and zlib install their headers there. >The plpgsql issue should be fixed by making the ifneq >($(enable_shared),yes) sections in plpgsql/src/Makefile cover the parts >you don't want to execute. That's what it is for, it just hasn't been >exercised yet. Not really, it's because building the static library kills wlib. It is a platform specific problem similar to the hack in backend/Makefile. Of course I could make this dependant on enable_shared, but I don't like using two different flags to work around the same bug. >-- >Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Tegge, Bernd writes: > >The first line looks like a broken compiler installation. The second line > >should, if at all, go into the template file. But I don't like us using > >arbitrary include paths. If the compiler vendor decides to not go there > >by default they had a reason. In any case there would be an equivalent > >LDFLAGS setting missing. Also, -I options should go into CPPFLAGS. > > Could you elaborate ? I am not sure which template file you refer to. src/template/qnx4 > In case you are thinking of the gcc installation, I guess they could be > scrapped. However, Watcom does not search these directories by default. > In fact, IIRC a OOB QNX4 install does not even *have* a '/usr/local'. I > have included this because TCL and zlib install their headers there. Only if you tell them to install them there. Which is probably a reasonable thing to do, but since /usr/local is not considered an integral part of the system we shouldn't force it upon the user. It's just a matter of keeping things clean. > >The plpgsql issue should be fixed by making the ifneq > >($(enable_shared),yes) sections in plpgsql/src/Makefile cover the parts > >you don't want to execute. That's what it is for, it just hasn't been > >exercised yet. > > Not really, it's because building the static library kills wlib. It is > a platform specific problem similar to the hack in backend/Makefile. > Of course I could make this dependant on enable_shared, but I don't like > using two different flags to work around the same bug. I see. But the static lib is kind of useless in this case, so we could turn it all off and get rid of the wlib problem at the same time? -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
At 22:57 22.05.01 +0200, Peter Eisentraut wrote: >Tegge, Bernd writes: > > > >The first line looks like a broken compiler installation. The second line > > >should, if at all, go into the template file. But I don't like us using > > >arbitrary include paths. If the compiler vendor decides to not go there > > >by default they had a reason. In any case there would be an equivalent > > >LDFLAGS setting missing. Also, -I options should go into CPPFLAGS. > > > > Could you elaborate ? I am not sure which template file you refer to. > >src/template/qnx4 Yes, I agree. That looks like a better place. > > In case you are thinking of the gcc installation, I guess they could be > > scrapped. However, Watcom does not search these directories by default. > > In fact, IIRC a OOB QNX4 install does not even *have* a '/usr/local'. I > > have included this because TCL and zlib install their headers there. > >Only if you tell them to install them there. Which is probably a >reasonable thing to do, but since /usr/local is not considered an integral >part of the system we shouldn't force it upon the user. It's just a >matter of keeping things clean. Well, if there is no /usr/local the flag will be silently ignored. If someone really wants to install perl, tcl and zlib in non standard locations he'll have to fiddle with the setup anyway. I wanted to provide reasonable defaults that work with the rest of the binary packages mentioned in the FAQ. The correct way imho would be to let configure figure it out, but have I have no idea how to implement that. > > >The plpgsql issue should be fixed by making the ifneq > > >($(enable_shared),yes) sections in plpgsql/src/Makefile cover the parts > > >you don't want to execute. That's what it is for, it just hasn't been > > >exercised yet. > > > > Not really, it's because building the static library kills wlib. It is > > a platform specific problem similar to the hack in backend/Makefile. > > Of course I could make this dependant on enable_shared, but I don't like > > using two different flags to work around the same bug. > >I see. But the static lib is kind of useless in this case, so we could >turn it all off and get rid of the wlib problem at the same time? That is exactly what I wanted to achieve. There is no reason to even compile the plpgsql sources at the moment on QNX4. I suppose I could move the hack into the plpgsql Makefile but that is somewhat tricky because the all-lib target for building the static lib is in $src/Makefile.shlib: *** postgresql-7.1.1/src/pl/plpgsql/src/Makefile Fri Apr 6 16:36:36 2001 --- postgresql-7.1.1.qnx4/src/pl/plpgsql/src/Makefile Wed May 23 11:13:50 2001 *************** *** 21,32 **** OBJS = pl_parse.o pl_handler.o pl_comp.o pl_exec.o pl_funcs.o all: all-lib # Shared library stuff include $(top_srcdir)/src/Makefile.shlib ! ! # In order to use Makefile.shlib, we allow it to build a static # library libplpgsql.a, which we just ignore, as well as a shared # library that it will insist on naming $(shlib). We don't want to --- 21,37 ---- OBJS = pl_parse.o pl_handler.o pl_comp.o pl_exec.o pl_funcs.o + ifeq ($(PORTNAME), qnx4) all: all-lib # Shared library stuff include $(top_srcdir)/src/Makefile.shlib ! else ! all: ! @echo "*****"; \ ! echo "* PL/pgSQL was not built due to library manager problems."; \ ! echo "*****" ! endif # In order to use Makefile.shlib, we allow it to build a static # library libplpgsql.a, which we just ignore, as well as a shared # library that it will insist on naming $(shlib). We don't want to *** postgresql-7.1.1/src/template/qnx4 Tue Oct 31 19:16:20 2000 --- postgresql-7.1.1.qnx4/src/template/qnx4 Wed May 23 11:30:55 2001 *************** *** 1,2 **** ! CFLAGS= LIBS=-lunix --- 1,2 ---- ! CFLAGS=-I/usr/local/include LIBS=-lunix
Hello,
I'm porting posgresql for QNX RTP. Compiling is ok, but
"/usr/local/pqsql/bin/initdb -D data" command say:
FATAL: s_lock(0x081e6029) at spin.c:162, stuck spinlock. Aborting.
FATAL: s_lock(0x081e6029) at spin.c:162, stuck spinlock. Aborting.
sed: couldn't write 86 items to {standard output}: Broken pipe
Abort (core dumped)
initdb failed.
Data directory dat will not be removed at user's reques
I review sem_'s family functions and use de QNX sem function, except
S_LOCK_FREE:
It is in src/include/storing/s_lock.h
#define S_LOCK_FREE(lock) s_lock_free_x86(lock)
#define TAS(lock) (sem_trywait((lock)) < 0)
#define S_UNLOCK(lock) sem_post((lock))
#define S_INIT_LOCK(lock) sem_init((lock), 1, 1)
It is in src/backend/port/x86/sem.c and make for my
int
s_lock_free_x86(sem_t *lock) {
int value;
sem_getvalue(lock, &value);
return value;
};
The testing program "s_lock_test" (is inside in s_lock.c) working properly.
Any idea. Sorry for my english.
Thanks,
Leandro Medina
(Ingdesi Group - R&D)
"Leandro Medina" <lmedina@ingdesi.com> writes:
> I'm porting posgresql for QNX RTP. Compiling is ok, but
> "/usr/local/pqsql/bin/initdb -D data" command say:
> FATAL: s_lock(0x081e6029) at spin.c:162, stuck spinlock. Aborting.
Hm. The existing QNX spinlock functions do work for some people.
Is the slock_t datatype declared correctly for your platform in the
port header file?
regards, tom lane
Patch applied, but newer version. Thanks. > Am 09:47 21.05.01 +0200 schrieb Kamil Parkanyi: > >Hello, > > > >I hope this e-mail will find you... > > Yes, I' here :-; > > > > > > >---------- > >I sent e-mail to <mailto:kardos@repas-aeg.de>kardos@repas-aeg.de but it > >returned as undeliverable > >---- Recipients of this delivery ---- > > Anreas has left and is no longer involved with postgres on QNX4. > > ><<mailto:kardos@dragon.dr.repas.de>kardos@dragon.dr.repas.de> (bounced) > > > >---------- > >I've tried to port postgresql-7.1 to my QNX 4.25 system. > >I read FAQ_QNX. > >I have Watcom 10.6, Bison 1.28, Flex 2.5.4, Perl 5.6.0, TCP/IP 4.25 for QNX > >/usr/local/ld is link to wlink > >so I run > >./configure --enable-odbc > >make > > I haven't tried building postgres with the Watcom compiler for 7.1 because > it does not support 64bit integers. AFAIK that's the default data type for > OIDs, so I am not surprised that this does not work. Use gcc instead. > BTW., 7.1 does not compile as is with gcc either, I believed the > required patches made it into the 7.1.1 release but obviously I missed > the deadline. > Since the ports mailing list does not seem to be archived I have attached > a copy of the patch (for 7.1 and 7.1.1). > > Are you trying to use odbc on qnx ? If so, I'd be interested in the > results. I am not aware of anyone having done this before. > > > > >/usr/watcom/10.6/bin/wcc386 -zq -i=../../../../src/include -ms -4r > >-i=/usr/watcom/10.6/usr/include -i=/usr/include tuptoaster.c > >tuptoaster.c(892): Error! E1011: Symbol 'F_OIDEQ' has not been declared > >tuptoaster.c(983): Error! E1011: Symbol 'F_OIDEQ' has not been declared > >cc: /usr/watcom/10.6/bin/wcc386 exited 2 > >make[4]: *** [tuptoaster.o] Error 2 > >make[4]: Leaving directory > >`/home/Parkanyi/Skusobne/postgresql-7.1/src/backend/access/heap' > > > >***** > >I found on the Internet that this is often compilation error and that in > >fmgr.h should be > >#define F_OIDEQ 184 > >I have only one fmgr.h file in src/include directory so I've added it there > >***** > > > >make > > > >cc -I../../../src/include -c bootstrap.c > >/usr/watcom/10.6/bin/wcc386 -zq -i=../../../src/include -ms -4r > >-i=/usr/watcom/10.6/usr/include -i=/usr/include bootstrap.c > >bootstrap.c(103): Error! E1011: Symbol 'F_BOOLIN' has not been declared > > <snip> > > >bootstrap.c(107): Error! E1011: Symbol 'F_INT2OUT' has not been declared > >bootstrap.c(107): Error! E1054: Expression must be constant > >bootstrap.c(108): Error! E1147: Too many errors: compilation aborted > >cc: /usr/watcom/10.6/bin/wcc386 exited 1 > >make[3]: *** [bootstrap.o] Error 1 > >make[3]: Leaving directory > >`/home/Parkanyi/Skusobne/postgresql-7.1/src/backend/bootstrap' > > > >Untill bootstrap.c the compilation was with no error. > >Where I made mistake? > >Why there is not definition of symbols above? > > These constants should be defined in fmgroids.h which should have > been generated by src/backend/utils/Gen_fmgrtab.sh. I don't know why > it did not work. > > PS: you can find a plain vanilla binary at http://pweb.uunet.de/tegge.h/ [ Attachment, skipping... ] [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl -- Bruce Momjian | http://candle.pha.pa.us pgman@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
This was the one actually applied. > At 00:33 22.05.01 -0400, Bruce Momjian wrote: > >Subject: Re: [PORTS] Re: pgsql + qnx > >To: "Tegge, Bernd" <tegge@repas-aeg.de> > >CC: Kamil Parkanyi <parkanyi@procaut.sk>, pgsql-ports@postgresql.org > > > > > >Your patch has been added to the PostgreSQL unapplied patches list at: > > > > http://candle.pha.pa.us/cgi-bin/pgpatches > > > >I will try to apply it withing the next 48 hours. > I've just performed a build of a Watcom compiled version and found a couple > of bugs in the watcom specific part of that patch. Please use the attached > version instead. > The watcom version fails 3 additional regression tests, at least one (int8) > expected; I have not looked at the other ones. [ Attachment, skipping... ] -- Bruce Momjian | http://candle.pha.pa.us pgman@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
At 16:30 23.05.01 -0400, Tom Lane wrote: >"Leandro Medina" <lmedina@ingdesi.com> writes: > > I'm porting posgresql for QNX RTP. Compiling is ok, but > > "/usr/local/pqsql/bin/initdb -D data" command say: > > > FATAL: s_lock(0x081e6029) at spin.c:162, stuck spinlock. Aborting. > >Hm. The existing QNX spinlock functions do work for some people. >Is the slock_t datatype declared correctly for your platform in the >port header file? Just to throw in my $0.02 : - from the source snippet it looks like it is using semaphores for spinlocks. This is one of the quirks that my patch corrected. See http://www.ca.postgresql.org/mhonarc/pgsql-ports/2001-05/msg00069.html and http://www.ca.postgresql.org/mhonarc/pgsql-ports/2001-05/msg00078.html Without it 7.1 failed with a similar problem on QNX4. - RTP is probably more different from QNX4 than Solaris 2 from SunOS 4, so code that works on QNX4 may fail on RTP. It is much closer to modern unices and supports shared libraries, elf executables, etc. . AFAIK no SysV IPC interface, though. The RTP version could be much more fully featured that the QNX4 version. - QNX (both versions) is a RTOS. If you were to use RR or FIFO scheduling, spinlocks probably won't work. > regards, tom lane
Hi Bernd,
I find the solution for one problem, but others appear. Why spinlock
doesn't works with FIFO or RR scheduling?
Thanks,
Leandro Medina
(Ingdesi Group - R&D)
----- Original Message -----
From: "Tegge, Bernd" <tegge@repas-aeg.de>
To: "Tom Lane" <tgl@sss.pgh.pa.us>; "Leandro Medina" <lmedina@ingdesi.com>
Cc: <pgsql-ports@postgresql.org>
Sent: Monday, May 28, 2001 6:37 AM
Subject: Re: [PORTS] lock in qnx rtp.
> At 16:30 23.05.01 -0400, Tom Lane wrote:
> >"Leandro Medina" <lmedina@ingdesi.com> writes:
> > > I'm porting posgresql for QNX RTP. Compiling is ok, but
> > > "/usr/local/pqsql/bin/initdb -D data" command say:
> >
> > > FATAL: s_lock(0x081e6029) at spin.c:162, stuck spinlock. Aborting.
> >
> >Hm. The existing QNX spinlock functions do work for some people.
> >Is the slock_t datatype declared correctly for your platform in the
> >port header file?
> Just to throw in my $0.02 :
>
> - from the source snippet it looks like it is using semaphores for
> spinlocks. This is one of the quirks that my patch corrected. See
> http://www.ca.postgresql.org/mhonarc/pgsql-ports/2001-05/msg00069.html
> and
> http://www.ca.postgresql.org/mhonarc/pgsql-ports/2001-05/msg00078.html
> Without it 7.1 failed with a similar problem on QNX4.
>
> - RTP is probably more different from QNX4 than Solaris 2 from SunOS 4,
> so code that works on QNX4 may fail on RTP. It is much closer to
> modern unices and supports shared libraries, elf executables, etc. .
> AFAIK no SysV IPC interface, though. The RTP version could be much
> more fully featured that the QNX4 version.
>
> - QNX (both versions) is a RTOS. If you were to use RR or FIFO
> scheduling, spinlocks probably won't work.
>
>
> > regards, tom lane
>
>
Am 17:19 30.05.01 -0300 schrieb Leandro Medina: >Hi Bernd, > I find the solution for one problem, but others appear. Why spinlock >doesn't works with FIFO or RR scheduling? Sorry, I had a different implementation in mind, where spinlocks did not sleep during the wait. Postgres spinlocks should be fine for RR and FIFO scheduling. >Thanks, > >Leandro Medina >(Ingdesi Group - R&D) >----- Original Message ----- >From: "Tegge, Bernd" <tegge@repas-aeg.de> >To: "Tom Lane" <tgl@sss.pgh.pa.us>; "Leandro Medina" <lmedina@ingdesi.com> >Cc: <pgsql-ports@postgresql.org> >Sent: Monday, May 28, 2001 6:37 AM >Subject: Re: [PORTS] lock in qnx rtp. <snip> > > > > - QNX (both versions) is a RTOS. If you were to use RR or FIFO > > scheduling, spinlocks probably won't work. > >