[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jay Levitt
Subject: fseeko on Stratus VOS (was: Stupid newbie question/ramble: Install?)
Date: Fri, 16 Nov 2007 21:33:44 -0500
User-agent: Thunderbird (Windows/20071031)

On 11/14/2007 9:51 PM, Eric Blake wrote:
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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]