With regards to earlier post I have been able to get a successful make
by defining NOFILES in ./src/includes/ports/sco.h
eg #define NOFILE 110
Not ideal as this value is defined in the kernel and so there is
probablly a
function to look it up. I'll look in that if I can get it working.

My problem now is gmake check fails and gmake install doesn't

============== creating temporary installation ==============

pg_regress: installation failed
Examine ./log/install.log for the reason.

gmake[2]: *** [check] Error 2
rm regress.o
gmake[2]: Leaving directory
`/u/Download/SQL/postgresql-7.1.3/src/test/regress'
gmake[1]: *** [check] Error 2
gmake[1]: Leaving directory `/u/Download/SQL/postgresql-7.1.3/src/test'
gmake: *** [check] Error 2

gmake --version
GNU Make version 3.78.1, by Richard Stallman and Roland McGrath.
Built for i686-pc-sco3.2v5.0.5

attached install.log

Thanks again for any help.

Steve
===================================================
CUSTOMWARE, 27 Cookes Road, Windsor Gardens SA 5087
Phone +61 8 8369 2287 Fax +61 8 8369 1121
Email steve@customware.aust.com
===================================================

Search Discussions

  • Tom Lane at Oct 23, 2001 at 6:27 pm

    Steve Burger writes:
    /bin/sh ../../../config/install-sh -c -m 644 libpq.a /u/Download/SQL/postgresql-7.1.3/src/test/regress/./tmp_check/install/usr/local/pgsql/lib/libpq.a
    /bin/sh ../../../config/install-sh -c -m 755 /u/Download/SQL/postgresql-7.1.3/src/test/regress/./tmp_check/install/usr/local/pgsql/lib/
    install: no destination specified
    I think it's trying to install the shared-library version of libpq, and
    is failing because the $(shlib) macro is expanding to empty.

    What is PORTNAME set to in src/Makefile.global? $(shlib) should be set
    in src/Makefile.shlib; if PORTNAME isn't "sco" or one of the other
    recognized names, this might happen.

    regards, tom lane
  • Peter Eisentraut at Oct 23, 2001 at 8:36 pm

    Steve Burger writes:

    pg_regress: installation failed
    Examine ./log/install.log for the reason.

    gmake[2]: *** [check] Error 2
    rm regress.o
    gmake[2]: Leaving directory
    `/u/Download/SQL/postgresql-7.1.3/src/test/regress'
    gmake[1]: *** [check] Error 2
    gmake[1]: Leaving directory `/u/Download/SQL/postgresql-7.1.3/src/test'
    gmake: *** [check] Error 2
    You should configure --disable-shared because shared libraries aren't
    supported on SCO yet.

    --
    Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
  • Tom Lane at Oct 24, 2001 at 4:15 am

    Peter Eisentraut writes:
    You should configure --disable-shared because shared libraries aren't
    supported on SCO yet.
    If that's the answer, meseems it should be mentioned in doc/FAQ_SCO.
    Or even enforced in template/sco. But since neither is the case,
    I wonder whether the previous users of the SCO port haven't managed
    to make it work.

    regards, tom lane
  • Steve Burger at Oct 24, 2001 at 4:53 am
    Thanks for the previous responces they have helped me in the right
    direction.

    I am playing with it at the moment.
    So far I've edited
    ./src/include/port/sco.h and added
    #define NOFILE 110
    ./src/Makefile.shlib and added
    ifeq ($(PORTNAME), sco)
    shlib := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_
    VERSION)
    LINK.shared = $(COMPILER) -G -Kpic -belf
    endif
    This gets me a compile and an install. Postmaster works and I can create
    dbases and tables.
    pgaccess does not work although I did have it working prior to changing
    Makefile.shlib
    but it was not using libpgtcl.so.

    I would like to be able to use libpgtcl from my bltwish when I
    load /usr/local/pgsql/lib/libpgsql.so I get the following error

    couldn't load file "/usr/local/pgsql/lib/libpgtcl.so": dynamic linker :
    /usr/local/bin/bltwish : error opening libpq.so

    Figuring this looks like a pathing issue I

    ln /usr/local/pgsql/lib/libpq.so /usr/lib

    and the error changes to
    couldn't load file "/usr/local/pgsql/lib/libpgtcl.so": dynamic linker:
    /usr/local/bin/bltwish: relocation error: symbol not found: crypt

    Now I've read something about crypt inrelation to this I cann't think
    where.
    I'll keep chipping away, if you can shed any light let me know.


    Regards Steve Burger

    Tom Lane wrote:
    Peter Eisentraut <peter_e@gmx.net> writes:
    You should configure --disable-shared because shared libraries aren't
    supported on SCO yet.
    If that's the answer, meseems it should be mentioned in doc/FAQ_SCO.
    Or even enforced in template/sco. But since neither is the case,
    I wonder whether the previous users of the SCO port haven't managed
    to make it work.

    regards, tom lane
  • Tom Lane at Oct 24, 2001 at 5:15 am

    Steve Burger writes:
    and the error changes to
    couldn't load file "/usr/local/pgsql/lib/libpgtcl.so": dynamic linker:
    /usr/local/bin/bltwish: relocation error: symbol not found: crypt
    Is libcrypt in your shared-library search path?

    regards, tom lane
  • Steve Burger at Oct 24, 2001 at 5:25 am
    Tom,

    libcrypt.so and libcrpyt_i.so are in /usr/lib
    I am compiling with the following script
    CCFLAGS=
    CC=/usr/bin/cc
    export CC CCFLAGS
    ./configure --with-libs="/usr/lib /usr/local/lib"
    --with-includes="/usr/include
    /usr/local/include" --with-tcl --with-tclconfig=/usr/local/lib
    --with-tkconfig=/
    usr/local/lib
    gmake

    man cc
    -l name
    Search a library libname.a (and preferentially libname.so if any
    user-specified objects are in ELF format or if the option -b elf is

    used without -dn) for unresolved function references. By default,
    cc directs ld to search libcrypt, libgen, and libc, in that order,
    for any still unresolved function references.
    so I assume libcrypt should get linked in automatically.

    regards Steve

    Tom Lane wrote:
    Steve Burger <steve@customware.aust.com> writes:
    and the error changes to
    couldn't load file "/usr/local/pgsql/lib/libpgtcl.so": dynamic linker:
    /usr/local/bin/bltwish: relocation error: symbol not found: crypt
    Is libcrypt in your shared-library search path?

    regards, tom lane
    --
    ===================================================
    CUSTOMWARE, 27 Cookes Road, Windsor Gardens SA 5087
    Phone +61 8 8369 2287 Fax +61 8 8369 1121
    Email steve@customware.aust.com
    ===================================================
  • Steve Burger at Oct 24, 2001 at 9:35 am
    Thanks for the help to date.
    I can get a statically link version to run now, but it would be
    nice to able to dynamical load libpgtcl so I will keep trying.

    libcrypt.so and libcrpyt_i.so are in /usr/lib
    I am compiling with the following script
    CCFLAGS=
    CC=/usr/bin/cc
    export CC CCFLAGS
    ./configure --with-libs="/usr/lib /usr/local/lib"
    --with-includes="/usr/include /usr/local/include" --with-tcl
    --with-tclconfig=/usr/local/lib --with-tkconfig=usr/local/lib
    gmake

    man cc
    -l name
    Search a library libname.a (and preferentially libname.so if any
    user-specified objects are in ELF format or if the option -b elf is

    used without -dn) for unresolved function references. By default,
    cc directs ld to search libcrypt, libgen, and libc, in that order,
    for any still unresolved function references.

    so I assume libcrypt should get linked in automatically.

    regards Steve

    Tom Lane wrote:
    Steve Burger <steve@customware.aust.com> writes:
    and the error changes to
    couldn't load file "/usr/local/pgsql/lib/libpgtcl.so": dynamic linker:
    /usr/local/bin/bltwish: relocation error: symbol not found: crypt
    Is libcrypt in your shared-library search path?

    regards, tom lane

    ---------------------------(end of broadcast)---------------------------
    TIP 3: if posting/reading through Usenet, please send an appropriate
    subscribe-nomail command to majordomo@postgresql.org so that your
    message can get through to the mailing list cleanly
    --
    ===================================================
    CUSTOMWARE, 27 Cookes Road, Windsor Gardens SA 5087
    Phone +61 8 8369 2287 Fax +61 8 8369 1121
    Email steve@customware.aust.com
    ===================================================
  • Peter Eisentraut at Oct 24, 2001 at 7:01 pm

    Tom Lane writes:

    Peter Eisentraut <peter_e@gmx.net> writes:
    You should configure --disable-shared because shared libraries aren't
    supported on SCO yet.
    If that's the answer, meseems it should be mentioned in doc/FAQ_SCO.
    Or even enforced in template/sco. But since neither is the case,
    I wonder whether the previous users of the SCO port haven't managed
    to make it work.
    The current Makefile.shlib will fail in the install target if the platform
    has no shared library support. This is a bug because Makefile.shlib
    should provide transparent library building. However, it might have been
    that the installation would silently proceed if the local version of
    'install' was sufficiently ill-behaved. But we don't use that anymore.

    In any case, the 7.2 release will have shared library support on SCO (at
    least theoretically), and I'll make sure that Makefile.shlib gets fixed.

    --
    Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
  • Steve Burger at Oct 25, 2001 at 3:35 am
    Just to recap I'm currently compiling with the following lines added to
    Makefile.shlib
    ifeq ($(PORTNAME), sco)
    shlib := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_
    VERSION)
    LINK.shared = $(COMPILER) -G -Kpic -belf
    endif
    postmaster and psql seem to work ok. but libpgtcl.so dies with the following

    couldn't load file "/usr/local/pgsql/lib/libpgtcl.so": dynamic linker :
    /usr/local/bin/bltwish : error opening libpq.so

    Figuring this looks like a pathing issue so I

    ln /usr/local/pgsql/lib/libpq.so /usr/lib

    and the error changes to
    couldn't load file "/usr/local/pgsql/lib/libpgtcl.so": dynamic linker:
    /usr/local/bin/bltwish: relocation error: symbol not found: crypt

    It would be great to get this working.

    Regards Steve Burger

    Peter Eisentraut wrote:
    Tom Lane writes:
    Peter Eisentraut <peter_e@gmx.net> writes:
    You should configure --disable-shared because shared libraries aren't
    supported on SCO yet.
    If that's the answer, meseems it should be mentioned in doc/FAQ_SCO.
    Or even enforced in template/sco. But since neither is the case,
    I wonder whether the previous users of the SCO port haven't managed
    to make it work.
    The current Makefile.shlib will fail in the install target if the platform
    has no shared library support. This is a bug because Makefile.shlib
    should provide transparent library building. However, it might have been
    that the installation would silently proceed if the local version of
    'install' was sufficiently ill-behaved. But we don't use that anymore.

    In any case, the 7.2 release will have shared library support on SCO (at
    least theoretically), and I'll make sure that Makefile.shlib gets fixed.

    --
    Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

    ---------------------------(end of broadcast)---------------------------
    TIP 3: if posting/reading through Usenet, please send an appropriate
    subscribe-nomail command to majordomo@postgresql.org so that your
    message can get through to the mailing list cleanly

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-ports @
categoriespostgresql
postedOct 20, '01 at 12:28p
activeOct 25, '01 at 3:35a
posts10
users3
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase