fseeko on Stratus VOS (was: Stupid newbie question/ramble: Install?)

[Jay Levitt]

On 11/14/2007 9:51 PM, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Jay Levitt on 11/14/2007 7:30 PM:
> > I'm caught in a bit of a dependency loop where I tried
> > upgrading bison, which needs m4, which (1.4.10) doesn't build properly
> > at the moment (but 1.4.0 built at one point), so I started patching it
> > but of course autoreconf doesn't like old m4... etc.
> >
> > The root of the m4 problem seems to be fseeko, which VOS doesn't
> > support.  m4 pulls that in from gnulib, but gives a very odd error:
>
> OK, so we need to port the fseeko module to VOS.  And since you are the
> first person that seems to be porting to this platform, you will have to
> do much of the legwork.

Results of my forensic analysis...

The following message:

  bind: Undefined entry point: fseeko, first referenced by fseeko.

is, in fact, true.  fseeko.o does NOT define fseeko(); it of course 
defines rpl_fseeko(). and stdio.h does a #define fseeko rpl_fseeko. 
(And of course the tests really use libgnu.a, not fseeko.o, but 
everything I'm saying here about fseeko.o applies to ligbnu.a as well.)

So here's the funny thing: the object wrongly looking for fseeko() is 
not, as you'd expect, test-fseeko.o; it's fseeko.o itself!  Somehow - 
and I don't quite get this yet - when fseeko.c is built, HAVE_FSEEKO is 
true, so it just goes ahead and calls fseeko() in the "else" of its if 
statement.

test-fseeko.c, on the other hand, gets the stdio.h redefine, and is 
perfectly happy - the preprocessor output verifies that it's calling 
rpl_fseeko().  But test-fseeko.pm (the executable) can't be built, since 
it links fseeko.o which needs fseeko() which doesn't exist.

The top-level config.log says:

  configure:4830: checking for fseeko
  configure:4881: result: no
  ...
  gl_cv_func_fseeko=no
  GNULIB_FSEEKO='1'
  HAVE_FSEEKO='0'
  REPLACE_FSEEKO='1'

The generated config.h says:

  #define HAVE_FSEEKO 1

I'm not an m4 guru, but I think the last is set by stdio_h.m4?

So now I'm confused, and I'm not sure exactly how it's *supposed* to 
work - I don't have another system that's missing fseeko.  I took a look 
at how argp builds on Ubuntu, but that does things differently - the 
autoconf script never tests for the presence of argp.  Likewise, 
although getaddrinfo's script does test for getaddrinfo, getaddrinfo.c 
on Cygwin doesn't depend on HAVE_GETADDRINFO.

So I can't quite find a working analogue that's built the way fseeko is. 
 Any pointers?

Jay Levitt