FAQ
The following steps should fix the configure and
compile problems that was occuring with installing
Postgres 7.2 on HPUX 11.11. using the gcc compiler
(See below for reference posts)

for compiling postgres 7.2 or 7.2.1 on HPUX11.11
run ./configure
=> checking types of arguments for accept()...
configure: error: could not determine argument types
open configure file : vi configure
find this line :
cat >> confdefs.h <<EOF
#define PG_VERSION "$VERSION"
EOF
and repalce by
cat >> confdefs.h <<EOF
#define _XOPEN_SOURCE_EXTENDED
#define PG_VERSION "$VERSION"
EOF

and run agin ./configure
now open src/Makefile.global
find the line begin by CFLAGS=
and add in this line :
-D_XOPEN_SOURCE_EXTENDED

After this step you need to modify 3 files
->src/backend/libpq/pqformat.c
->src/interfaces/libpq/fe-misc.c
->src/interfaces/odbc/socket.c
for adding :
#include <arpa/inet.h>
#include <netinet/in.h>

and Run gmake...

-------------------------------------------------------

Re: Second call for platform testing

From: Joe Conway <[email protected]

To: [email protected]

Subject: Re: Second call for platform testing
Date: Thu, 29 Nov 2001 12:07:28 -0800

Thomas Lockhart wrote:
Are you still looking for HPUX 11.0+ ? I can arrange
for access to one
if we still need it (gcc though, I don't have access
to HP's compiler).
Yes, that would be great. 10.20 is pretty old afaik...
- Thomas

I ran into a problem on HPUX 11 right off with:

===============================
configure --enable-debug
.
.
.
checking for struct sockaddr_un... yes
checking for int timezone... yes
checking types of arguments for accept()... configure:
error: could not
determine argument types


===============================

I won't pretend to be very knowledgable about HPUX or
configure, but it
looks like the following in configure is where it
dies:

===============================

else
for ac_cv_func_accept_arg1 in 'int' 'unsigned
int'; do
for ac_cv_func_accept_arg2 in 'struct sockaddr
*' 'const struct
sockaddr *' 'void *'; do
for ac_cv_func_accept_arg3 in 'int' 'size_t'
'socklen_t'
'unsigned int' 'void'; do
cat > conftest.$ac_ext <<EOF

=======================================

and here's what the HPUX man page says:

=======================================
accept(2)

NAME
accept - accept a connection on a socket

SYNOPSIS
#include <sys/socket.h>

AF_CCITT only
#include <x25/x25addrstr.h>

int accept(int s, void *addr, int *addrlen);

_XOPEN_SOURCE_EXTENDED only (UNIX 98)
int accept(int s, struct sockaddr *addr,
socklen_t *addrlen);

=======================================

so it looks like configure expects the third argument
to be (int), when
on HPUX 11 the third argument is (int *).

Any ideas what I'm doing wrong?

-- Joe



__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

Search Discussions

  • Jack Bates at May 5, 2002 at 7:11 pm
    I'm using:

    CVSROOT=:pserver:[email protected]:/projects/cvsroot

    Still no tag for 7.2.1.

    Could I (again) request that a tag be set for the current public release
    of this product?

    Cheers.

    --

    Jack Bates
    Portland, OR, USA
    http://www.floatingdoghead.net

    Got privacy?
    My PGP key: http://www.floatingdoghead.net/pubkey.txt
  • Lamar Owen at May 6, 2002 at 1:21 am

    On Sunday 05 May 2002 02:46 pm, Jack Bates wrote:
    CVSROOT=:pserver:[email protected]:/projects/cvsroot
    Still no tag for 7.2.1.
    Could I (again) request that a tag be set for the current public release
    of this product?
    Why? There is typically a REL tag set for the major, then a REL PATCHES tag
    set for the minors as a collective. If you want to track the current stable,
    you get the PATCHES tag, if one is set...However, our tags have never been
    consistent, unfortunately. We have a right hodgepodge of tags, according to
    the web interface (http://developer.postgresql.org/cvsweb.cgi/pgsql/)
    --
    Lamar Owen
    WGCR Internet Radio
    1 Peter 4:11
  • Jack at May 6, 2002 at 10:23 pm

    On Sun, 5 May 2002, Lamar Owen wrote:
    On Sunday 05 May 2002 02:46 pm, Jack Bates wrote:
    CVSROOT=:pserver:[email protected]:/projects/cvsroot
    Still no tag for 7.2.1.
    Could I (again) request that a tag be set for the current public release
    of this product?
    Why? ...
    Aside from being a near-universal "best practice", it makes it easier for
    someone to analyze whether local patches to 7.2.1 conflict with work that
    the team has committed. This makes it easier for patches to be massaged
    and submitted to the maintainers successfully even if the patch is not
    originally written for CVS head. Not everyone wants to develop on the
    bleeding edge all the time. Code that has passed local acceptance testing
    needs to be supported carefully at its existing release level, if at all
    possible.

    There was a tag for the 7.1.2 release, which was my previous baseline. A
    bunch of BETAs leading to 7.2 are tagged. Why not the current public
    release?

    I'm not here to bully and I apologize if my tone irritated. I'm a
    seasoned software engineer, and I'm happy to help out a bit in areas where
    I am qualified to do so. I submitted a patch last week for an obscure SSL
    issue in libpq and I'm looking at enabling, generally, non-blocking client
    IO over SSL in that library.

    BTW - I _LOVE_ 7.2's non-locking VACUUM ANALYZE - many, many thanks!
    Recent murmurings about propogating "deadness" of tuples to reduce index
    scan time are quite interesting to me, as is point-in-time recovery.
    Even without these features, PostgreSQL works _very_ well and quite
    predictably for me. I beat on this DBMS very hard, and I have not been
    able to break 7.2[.1] (nor 7.1.2, previously). Real good stuff.

    Cheers.

    --

    Jack Bates
    Portland, OR, USA
    http://www.floatingdoghead.net

    Got privacy?
    My PGP key: http://www.floatingdoghead.net/pubkey.txt
  • Tom Lane at May 7, 2002 at 2:31 pm

    <[email protected]> writes:
    Aside from being a near-universal "best practice", it makes it easier for
    someone to analyze whether local patches to 7.2.1 conflict with work that
    the team has committed.
    There is a 7.2 branch, and I would think that the tip of that branch is
    generally what you are interested in if you do not want the HEAD tip.

    Applying a tag to indicate exactly what state of that branch got
    released as 7.2.1 would be good from a historical-documentation
    point of view, but I can't see that it has any direct relevance
    for either current development or maintenance work.

    Of course, the real answer to your question is that Marc Fournier does
    that work, and the rest of us long ago gave up trying to get him to be
    perfectly consistent in his tagging practices ;-)

    regards, tom lane
  • Shra at May 22, 2002 at 1:33 pm
    hi,
    can v define our own datatype n use it in PostgreSQL tables?
    Shra
  • Jan Wieck at May 22, 2002 at 2:38 pm

    Shra wrote:
    hi,
    can v define our own datatype n use it in PostgreSQL tables?
    Shra
    u can


    Jan

    --

    #======================================================================#
    # It's easier to get forgiveness for being wrong than for being right. #
    # Let's break this rule - forgive me. #
    #================================================== [email protected] #

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMay 1, '02 at 8:22p
activeMay 22, '02 at 2:38p
posts7
users7
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2023 Grokbase