Re: Getting it to all work on HPUX

2009/2/9 Christos Zoulas <[email protected]>:
> 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

obviously it depends on linker options :(
However a __getsockopt seems defined in xnet and use always socklen_t

freddy77