Re: Getting it to all work on HPUX

On Feb 9,  4:41pm, [email protected] (Frediano Ziglio) wrote:
-- Subject: Re: [freetds] Getting it to all work on HPUX

| 2009/2/9 Christos Zoulas <[email protected]>:
| > On Feb 9, 11:34am, [email protected] (Frediano Ziglio) wrote:
| > -- Subject: Re: [freetds] Getting it to all work on HPUX
| >
| > | 2009/2/7 Christos Zoulas <[email protected]>:
| > | > On Feb 6,  9:45pm, [email protected] ("James K. Lowden") wrote:
| > | > -- Subject: Re: [freetds] Getting it to all work on HPUX
| > | >
| > | > | Frediano Ziglio wrote:
| > | > | > > I think we should use an autoconf test to detect the presence of
| > | > | > > socklen_t instead of resorting to such ugliness .
| > | > | > >
| > | > | >
| > | > | > We already test for socklen_t. The problem is that HP-UX use
| > | > | > socklen_t* for last getsockopt argument in some cases and int in some
| > | > | > others (giving different defines).
| > | > |
| > | > | It reminds me of the gethostbyname_r fiasco.  Solvable with autoconf, but
| > | > | not pretty.  Perhaps another project has already written the approprite
| > | > | m4?
| > | >
| > | > Look in the tcsh's configure.in. Thank you HP *again*!
| > | >
| > | > christos
| > |
| > | I don't see nothing about getsockopt in tcsh's configure.in, only
| > | about socklen_t (which we already test in our configure script). The
| > | problem is not socklen_t but the use of it in getsockopt !!
| > | Yes, my workaround is ugly...
| >
| > And it will not work for big-endian _LP64 machines where socklen_t is 32bits.
| > I don't know if any such beasts exist. Let me try to find a getsockopt test.
| >
| > christos
| 
| Just to make you smyle....
| 

So, does this work?
 
#if defined(__hpux) && !defined(_XOPEN_SOURCE_EXTENDED) 
	int socklen;
#else 
	socklen_t socklen;
#endif 

Sorry,^WThankfully I don't have HP/UX so I can't test. Having the same
symbol in two different libraries with different ABI is not the best
solution. Why aren't they using symbol renaming?

christos