Skip site navigation (1) Skip section navigation (2)

Re: Compiling on 8.1.3 on Openserver 5.05

From: Mark Campbell <mark(dot)campbell(at)ucs-software(dot)co(dot)za>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-ports(at)postgresql(dot)org
Subject: Re: Compiling on 8.1.3 on Openserver 5.05
Date: 2006-05-11 19:11:03
Message-ID: 44638C47.6010707@ucs-software.co.za (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackerspgsql-ports
Thx Tom

I edited the /usr/include/arpa/inet.h and added the following : #include 
<sys/byteorder.h>

Looks correct as some of the errors seem to be gone, however where would 
I have to add/include the "h_errno" and the "warning: unreachable code 
at beginning of switch statement" worries me

gmake command as follows:

ksh# gmake
gmake -C doc all
gmake[1]: Entering directory `/tmp/mdc_postgres8.1.3/postgresql-8.1.3/doc'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory `/tmp/mdc_postgres8.1.3/postgresql-8.1.3/doc'
gmake -C src all
gmake[1]: Entering directory `/tmp/mdc_postgres8.1.3/postgresql-8.1.3/src'
gmake -C port all
gmake[2]: Entering directory 
`/tmp/mdc_postgres8.1.3/postgresql-8.1.3/src/port'gcc -b elf -O2 -Wall 
-Wmissing-prototypes -Wpointer-arith -Winline -fno-strict-aliasing 
-I../../src/port -DFRONTEND-I../../src/include   -c -o getaddrinfo.o 
getaddrinfo.c
getaddrinfo.c: In function `pg_getaddrinfo':
getaddrinfo.c:211: `h_errno' undeclared (first use in this function)
getaddrinfo.c:211: (Each undeclared identifier is reported only once
getaddrinfo.c:211: for each function it appears in.)
getaddrinfo.c:215: warning: unreachable code at beginning of switch 
statement
gmake[2]: *** [getaddrinfo.o] Error 1
gmake[2]: Leaving directory 
`/tmp/mdc_postgres8.1.3/postgresql-8.1.3/src/port'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/tmp/mdc_postgres8.1.3/postgresql-8.1.3/src'
gmake: *** [all] Error 2
ksh#

Regards

Mark

Tom Lane wrote:

>Mark Campbell <mark(dot)campbell(at)ucs-software(dot)co(dot)za> writes:
>  
>
>>I found the following:
>>    
>>
>
>  
>
>>u_long ntohl __P((u_long)), htonl __P((u_long));
>>u_short ntohs __P((u_short)), htons __P((u_short));
>>#define htonl(x)        (x)
>>#define ntohs(x)        (x)
>>#define htons(x)        (x)
>>in /usr/include/sys/byteorder.h
>>    
>>
>
>Hmm ... you could add "#include <sys/byteorder.h>" but I fear you're
>going to need that in a lot of places.  The Single Unix Spec specifies
>that these functions are to be declared in <arpa/inet.h>, and that
>seems to be where most systems put 'em, because I can't recall having
>heard many previous complaints about this sort of failure.  The shortest
>route to success might be to modify your local copy of 
>/usr/include/arpa/inet.h to include sys/byteorder.h, instead.
>
>BTW, it could be that arpa/inet.h already does include sys/byteorder.h,
>but only when some configuration symbol is defined.  In that case you
>might want to force the configuration symbol instead.  Compare HPUX,
>where we do
>	CPPFLAGS="-D_XOPEN_SOURCE_EXTENDED"
>in order to get access to a reasonable set of predefined symbols ...
>
>			regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 9: In versions below 8.0, the planner will ignore your desire to
>       choose an index scan if your joining column's datatypes do not
>       match
>  
>

In response to

Responses

pgsql-ports by date

Next:From: Alan StangeDate: 2006-05-11 19:17:55
Subject: solaris build problem with Sun compilers
Previous:From: Tom LaneDate: 2006-05-11 17:22:57
Subject: Re: Compiling on 8.1.3 on Openserver 5.05

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-05-11 19:24:55
Subject: Re: Compiling on 8.1.3 on Openserver 5.05
Previous:From: Josh BerkusDate: 2006-05-11 19:04:20
Subject: Re: hashagg, statistisics and excessive memory allocation

pgsql-general by date

Next:From: Tom LaneDate: 2006-05-11 19:24:55
Subject: Re: Compiling on 8.1.3 on Openserver 5.05
Previous:From: Richard YenDate: 2006-05-11 19:07:04
Subject: SIGSEGV happens over once a day

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group