At 2:54 PM +0100 2/1/01, Jean-Marc Lasgouttes wrote:
> >>>>> "Bruce" == Bruce Foster <[EMAIL PROTECTED]> writes:
>
>Bruce> If the operating system is hp-ux, then they do it. If you want
>Bruce> to be specific to HPUX 10.20, then configure shows my host
>Bruce> system type to be hppa1.1-hp-hpux10.20
>
>The autoconf way of doing things is rather to look at functionality,
>not versions. I'll see what I can do, unless albert beats me to it :)
>
>JMarc
I just searched HP's Developer's Resource web site
(http://devresource.hp.com) and from what I found, I'll offer my own
(unverified) interpretation on the situation.
I'm running HPUX 10.20, which is not the most recent HPUX release.
It's a stable release, and is in widespread use.
It appears that snprintf, vsnprintf and so forth were introduced into
HPUX 10.30 (a specialized release, not in common use) and HPUX 11.x,
but not HPUX 10.20.
The gcc compiler we use is built on HPUX 11.x and backfit into HPUX
10.20. I think that's why the (v)snprintf routines are not fully
integrated into my release. Gcc thinks it knows about the routines,
but the underlying HPUX 10.20 OS doesn't properly provide everything
needed.
There _may_ be similar problems with HP's aCC product, their
proprietary C++, when working across different HPUX versions.
Perhaps we could add a symbol definition to force the use the
portable version of (v)snprintf, no matter what the LyX configure
script thinks it finds. That would keep us HPUX 10.20 people in
business, and might help others whose operating systems don't have
these routines.
Bruce
