FAQ

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 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.
(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/

Search Discussions

  • Peter Eisentraut at May 21, 2001 at 2:58 pm

    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
  • Tom Lane at May 21, 2001 at 3:52 pm

    Peter Eisentraut 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
  • Bruce Momjian at May 22, 2001 at 4:33 am

    Peter Eisentraut 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
  • Tegge, Bernd at May 22, 2001 at 10:27 am

    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.
  • Bruce Momjian at May 22, 2001 at 12:08 pm

    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
  • Tegge, Bernd at May 21, 2001 at 4:02 pm

    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
  • Bruce Momjian at May 22, 2001 at 4:33 am
    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 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.
    (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
  • Tegge, Bernd at May 22, 2001 at 1:30 pm

    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.
  • Bruce Momjian at May 22, 2001 at 1:32 pm
    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
  • Peter Eisentraut at May 22, 2001 at 2:51 pm

    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
  • Tegge, Bernd at May 22, 2001 at 3:49 pm

    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
  • Peter Eisentraut at May 22, 2001 at 8:56 pm

    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
  • Tegge, Bernd at May 23, 2001 at 10:47 am

    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
  • Leandro Medina at May 23, 2001 at 8:04 pm
    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)
  • Tom Lane at May 23, 2001 at 8:30 pm

    "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
  • Tegge, Bernd at May 28, 2001 at 9:38 am

    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
  • Leandro Medina at May 30, 2001 at 8:15 pm
    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
  • Tegge, Bernd at May 31, 2001 at 7:49 am

    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.
  • Bruce Momjian at May 24, 2001 at 3:53 pm
    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
  • Bruce Momjian at May 24, 2001 at 3:53 pm
    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 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.
    (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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-ports @
categoriespostgresql
postedMay 21, '01 at 11:58a
activeMay 31, '01 at 7:49a
posts21
users5
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase