Re: 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/

Andrew Chernow <ac(at)esilo(dot)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(at)esilo(dot)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/

Andrew Chernow <ac(at)esilo(dot)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(at)esilo(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)gmail(dot)com> writes:
> On Sun, Nov 16, 2008 at 12:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)gmail(dot)com> writes:
>
>> On Sun, Nov 16, 2008 at 12:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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/