Compiling on HP-UX 10.20 fails
I am trying to compile libpq on HP-UX 10.20 using gcc 2.95.3, cpu is a
400MHz PA8500. I'm using the 8.3.5 tarball.
[full make output is attached]
Outside of the failure to build...
I am getting a huge amount of "implicit declaration of function"
warnings from gcc, mostly about 64-bit interface functions like
__getrlimit64, __stat64, __fstat64, etc...
I'm pretty sure, from a glance at the sys headers and google'n, that
this version of hp-ux has large file support. Although, it appears the
sys headers clash with older versions of gcc ... I think.
Has anyone seem this issue before? BTW, I didn't see any defines like
_LARGEFILE64_SOURCE or _FILE_OFFSET_BITS in the CFLAGS or CPPFLAGS. I
don't think libpq needs large file support so maybe that's why they are
not defined.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Attachments:
Andrew Chernow <ac@esilo.com> writes:
I am trying to compile libpq on HP-UX 10.20 using gcc 2.95.3, cpu is a
400MHz PA8500. I'm using the 8.3.5 tarball.
Yeah, 10.20 is a bit old and creaky, and the system headers are shy of a
load in a few places. I currently use the attached fixes.
regards, tom lane
Tom Lane wrote:
Andrew Chernow <ac@esilo.com> writes:
I am trying to compile libpq on HP-UX 10.20 using gcc 2.95.3, cpu is a
400MHz PA8500. I'm using the 8.3.5 tarball.Yeah, 10.20 is a bit old and creaky, and the system headers are shy of a
load in a few places. I currently use the attached fixes.regards, tom lane
That got rid of all warnings. Although, it still fails to compile due
to gethostbyname_r:
thread.c:141: too many arguments to function `gethostbyname_r'
hpux 10.20, hpux 11 and aix (maybe more) use a 3 argument version, not 5:
int
gethostbyname_r(const char *name, struct hostent *result,
struct hostent_data *buffer);
I supplied a patch that includes a configure check. NOTE: the hpux
platform check at the top of thread.c may not be cross-compiler, I think
they are from gcc. Does the postgresql config system define platform
somewhere so I can #ifdef PG_HPUX?
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Attachments:
gethostbyname_r.patchtext/plain; name=gethostbyname_r.patchDownload
Index: configure.in
===================================================================
RCS file: /projects/cvsroot/pgsql/configure.in,v
retrieving revision 1.571
diff -C6 -r1.571 configure.in
*** configure.in 30 Oct 2008 12:28:51 -0000 1.571
--- configure.in 16 Nov 2008 05:15:59 -0000
***************
*** 1363,1374 ****
--- 1363,1392 ----
if test "$PORTNAME" != "win32"; then
AC_CHECK_HEADER(pthread.h, [], [AC_MSG_ERROR([pthread.h not found, required for --enable-thread-safety])])
fi
AC_CHECK_FUNCS([strerror_r getpwuid_r gethostbyname_r])
+ # determines if the system has a 3 or 5 argument gethostbyname_r, only needed with threads
+ # there is also a 6 arg version used by linux
+ if test "$enable_thread_safety" = yes ; then
+ AC_MSG_CHECKING([gethostbyname_r argument count])
+ AC_TRY_COMPILE(
+ [#undef _XOPEN_SOURCE_EXTENDED
+ #ifndef _REENTRANT
+ #define _REENTRANT
+ #endif
+ #ifndef _THREAD_SAFE
+ #define _THREAD_SAFE
+ #endif
+ #include <netdb.h>],
+ [gethostbyname_r((void *)0, (void *)0, (void *)0)],
+ [AC_DEFINE(GETHOSTBYNAME_R_ARGCNT, 3, [Define to the number of arguments gethostbyname_r accepts]) AC_MSG_RESULT(3)],
+ [AC_DEFINE(GETHOSTBYNAME_R_ARGCNT, 5, [Define to the number of arguments gethostbyname_r accepts]) AC_MSG_RESULT(5)])
+ fi
+
# Do test here with the proper thread flags
PGAC_FUNC_GETPWUID_R_5ARG
PGAC_FUNC_STRERROR_R_INT
CFLAGS="$_CFLAGS"
LIBS="$_LIBS"
Index: src/port/thread.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/port/thread.c,v
retrieving revision 1.39
diff -C6 -r1.39 thread.c
*** src/port/thread.c 22 Apr 2008 13:06:57 -0000 1.39
--- src/port/thread.c 16 Nov 2008 05:16:00 -0000
***************
*** 9,20 ****
--- 9,27 ----
*
* $PostgreSQL: pgsql/src/port/thread.c,v 1.39 2008/04/22 13:06:57 mha Exp $
*
*-------------------------------------------------------------------------
*/
+ /* When _XOPEN_SOURCE_EXTENDED is defined, struct hostent_data does
+ * not get declared. This structure is needed by hpux gethostbyname_r.
+ */
+ #if defined(FRONTEND) && defined(ENABLE_THREAD_SAFETY) && (defined(__hpux) || defined(__hpux__) || defined(hpux))
+ #undef _XOPEN_SOURCE_EXTENDED
+ #endif
+
#include "c.h"
#include <pwd.h>
#if defined(FRONTEND) && defined(ENABLE_THREAD_SAFETY)
#endif
***************
*** 126,142 ****
--- 133,171 ----
char *buffer, size_t buflen,
struct hostent ** result,
int *herrno)
{
#if defined(FRONTEND) && defined(ENABLE_THREAD_SAFETY) && defined(HAVE_GETHOSTBYNAME_R)
+ #if GETHOSTBYNAME_R_ARGCNT == 3
+ *result = NULL;
+
+ if (buflen < sizeof(struct hostent_data))
+ {
+ /* linux man page says this gets set when buffer is too small */
+ *herrno = ERANGE;
+ return -1;
+ }
+
+ if (gethostbyname_r(name, resultbuf, (struct hostent_data *)buffer))
+ {
+ *herrno = h_errno;
+ return -1;
+ }
+
+ *result = resultbuf;
+
+ /* 5 argument version. There is also a 6 arg version found on linux. */
+ #else
/*
* broken (well early POSIX draft) gethostbyname_r() which returns 'struct
* hostent *'
*/
*result = gethostbyname_r(name, resultbuf, buffer, buflen, herrno);
+ #endif /* GETHOSTBYNAME_R_ARGCNT */
+
return (*result == NULL) ? -1 : 0;
#else
/* no gethostbyname_r(), just use gethostbyname() */
*result = gethostbyname(name);
Andrew Chernow <ac@esilo.com> writes:
That got rid of all warnings. Although, it still fails to compile due
to gethostbyname_r:
thread.c:141: too many arguments to function `gethostbyname_r'
Hmm, did you override the fact that --enable-thread-safety fails?
I've always assumed that the userland thread support in 10.20 is too
broken to be worth troubling with.
regards, tom lane
Tom Lane wrote:
Andrew Chernow <ac@esilo.com> writes:
That got rid of all warnings. Although, it still fails to compile due
to gethostbyname_r:
thread.c:141: too many arguments to function `gethostbyname_r'Hmm, did you override the fact that --enable-thread-safety fails?
I've always assumed that the userland thread support in 10.20 is too
broken to be worth troubling with.regards, tom lane
Aaaahhh ... Apparently GNU Portable Threads
(http://www.gnu.org/software/pth/) was manually installed on this box,
so --enable-thread-safety worked fine for me.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
On Sun, Nov 16, 2008 at 12:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I've always assumed that the userland thread support in 10.20 is too
broken to be worth troubling with.
Using GNU Pth 2.07 on hpux 10.20 all tests provided with the library
pass when built via gcc 2.95.3. hpux is definitely a capricious
platform on a lot of levels, but Andrew's patch does technically fix
the build. PostgreSQL's threading tests pass as well. The
alternative is to have configure error out if threading is requested
for this platform.
merlin
"Merlin Moncure" <mmoncure@gmail.com> writes:
On Sun, Nov 16, 2008 at 12:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I've always assumed that the userland thread support in 10.20 is too
broken to be worth troubling with.
Using GNU Pth 2.07 on hpux 10.20 all tests provided with the library
pass when built via gcc 2.95.3. hpux is definitely a capricious
platform on a lot of levels, but Andrew's patch does technically fix
the build. PostgreSQL's threading tests pass as well. The
alternative is to have configure error out if threading is requested
for this platform.
Configure already does error out if threading is requested for this
platform ;-). The question in my mind is if we want to take any
additional trouble for an OS version long out of support by its maker.
I'd vote not, even though I still use it ...
regards, tom lane
Tom Lane wrote:
"Merlin Moncure" <mmoncure@gmail.com> writes:
On Sun, Nov 16, 2008 at 12:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I've always assumed that the userland thread support in 10.20 is too
broken to be worth troubling with.Using GNU Pth 2.07 on hpux 10.20 all tests provided with the library
pass when built via gcc 2.95.3. hpux is definitely a capricious
platform on a lot of levels, but Andrew's patch does technically fix
the build. PostgreSQL's threading tests pass as well. The
alternative is to have configure error out if threading is requested
for this platform.Configure already does error out if threading is requested for this
platform ;-). The question in my mind is if we want to take any
additional trouble for an OS version long out of support by its maker.
I'd vote not, even though I still use it ...
No. It's been out of support for more than 5 years, and was released
about the time that RedHat 4.0 was current. We shouldn't be wasting time
on dinosaurs.
cheers
andrew
Configure already does error out if threading is requested for this
platform ;-).
We are not seeing that behavior; at least for 8.3.5 tarball. configure
succeeds and with my patch, libpq builds and runs just fine.
The question in my mind is if we want to take any
additional trouble for an OS version long out of support by its maker.
I'd vote not, even though I still use it ...
We still find this old fart in the field, not a couple of them but quite
a few.
We shouldn't be wasting time
on dinosaurs.
Nobody had to, a patch was tested and provided by a brilliant engineer ;-)
I'm actually quite indifferent to this. I just think the configure
should fail with "unsupported option for platform" error, which Tom says
it should be doing, or something like my patch be applied.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/