On Tue, Sep 29, 2009 at 8:24 PM, Bojan Smojver <[email protected]> wrote:
> On Tue, 2009-09-29 at 09:35 -0700, Jeff Barnes wrote:
> > Can someone point out some error or provide some guidance?
>
> Looks like your generated C file is missing some includes. Have a look
> at the generated file and try to compile it by hand. Also, I'm guessing
> @LIBAPR@ is not blank, right?
I hypothosize that it's also possible that his includes are correct, but
that the right CPPFLAGS for largefile support on his platform are not in
use. Notice that the complaint is centered around the availability of
off64_t.
I haven't read any sources, but this change might help things:
y.tab.o: y.tab.c
$(CC) -g $(CFLAGS) $(CPPFLAGS) -c y.tab.c -...@libapr@/include
If that doesn't, you could also try adding
y.tab.o: CPPFLAGS += -DPOSIX_SOURCE -DPOSIX_C_SOURCE=200112L
or maybe
y.tab.o: CPPFLAGS += -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
or maybe
y.tab.o: CFLAGS += -std=gnu99
Note, that XOPEN_SOURCE=500 mandates large files, and probably SUSv2 &
SUSv3. The source-compatibility defines, e.g. the POSIX_SOURCE stuff,
should be defined somewhere by APR but for some reason isn't being specified
when building the scanner. This is a bug in the makefile IMHO; I just
haven't had the chance to dig for the right solution.
Note also that the fellow with the changing behaviour when he moves to g++
may be inadvertenly changing C standards or related but invisible version
selectioning stuff in his platform's feature test macros. For example, a
SUSv3 build normally requires C99 and 200112L posix source. But g++ is not
C99, although it can have posix 20012L source semantics. Yes, I know, this
crap is all horribly confusing.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
