I just tried to build today's CVS checkout, and got a compilation
failure in r.in.xyz on my FreeBSD system. The problem is the last
commit changed the type of the "filesize" variable to off_t, but on
FreeBSD it is necessary to have an explicit include of <sys/types.h>
to get the off_t typedef.
Inserting a #include <sys/types.h>
immediately before the include of <stdio.h> fixed the problem.
ok, I guess that wasn't as safe as I though it was.
should the "#include <sys/types.h>" be included in <grass/config.h> or
placed by hand in each module that uses "off_t"?
On Sun, Nov 05, 2006 at 04:23:50PM +1300, we recorded a bogon-computron collision of the <hamish_nospam@yahoo.com> flavor, containing:
Tom Russo wrote:
> I just tried to build today's CVS checkout, and got a compilation
> failure in r.in.xyz on my FreeBSD system. The problem is the last
> commit changed the type of the "filesize" variable to off_t, but on
> FreeBSD it is necessary to have an explicit include of <sys/types.h>
> to get the off_t typedef.
>
> Inserting a
> #include <sys/types.h>
> immediately before the include of <stdio.h> fixed the problem.
ok, I guess that wasn't as safe as I thought it was.
should the "#include <sys/types.h>" be included in <grass/config.h> or
placed by hand in each module that uses "off_t"?
I dunno, I guess it'd be safe to include sys/types.h in config.h, but
perhaps it would be better to probe for off_t in "configure", so
that the include is really only pulled in on systems that require it?
--
Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
one trick, rational thinking, but when you're good and crazy, oooh, oooh,
oooh, the sky is the limit!" --- The Tick
> I just tried to build today's CVS checkout, and got a compilation
> failure in r.in.xyz on my FreeBSD system. The problem is the last
> commit changed the type of the "filesize" variable to off_t, but on
> FreeBSD it is necessary to have an explicit include of <sys/types.h>
> to get the off_t typedef.
>
> Inserting a
> #include <sys/types.h>
> immediately before the include of <stdio.h> fixed the problem.
ok, I guess that wasn't as safe as I though it was.
should the "#include <sys/types.h>" be included in <grass/config.h> or
placed by hand in each module that uses "off_t"?
The latter. OTOH, if we add G_fseek/G_ftell functions which
take/return off_t, then it would need to go into <gisdefs.h>.
On Sat, 2006-11-04 at 21:05 -0700, Tom Russo wrote:
On Sun, Nov 05, 2006 at 04:23:50PM +1300, we recorded a bogon-computron collision of the <hamish_nospam@yahoo.com> flavor, containing:
> Tom Russo wrote:
> > I just tried to build today's CVS checkout, and got a compilation
> > failure in r.in.xyz on my FreeBSD system. The problem is the last
> > commit changed the type of the "filesize" variable to off_t, but on
> > FreeBSD it is necessary to have an explicit include of <sys/types.h>
> > to get the off_t typedef.
> >
> > Inserting a
> > #include <sys/types.h>
> > immediately before the include of <stdio.h> fixed the problem.
>
>
> ok, I guess that wasn't as safe as I thought it was.
>
> should the "#include <sys/types.h>" be included in <grass/config.h> or
> placed by hand in each module that uses "off_t"?
I dunno, I guess it'd be safe to include sys/types.h in config.h, but
perhaps it would be better to probe for off_t in "configure", so
that the include is really only pulled in on systems that require it?
No. config.h is only used to define whether specific functions/features
exist. Defining include files there is not appropriate. It enables us
to conditionally define sections in source (eg.):
config.h is a result of the 'configure' script. There is no need to
"probe" for off_t. It is part of the POSIX specification and I believe
'configure' has sufficient support to determine the size of off_t.
All POSIX systems that want largefile support must use off_t and use the
appropriate compile macros for that arch. 'int' and 'long' are not of
sufficient length.
--
Brad Douglas <rez touchofmadness com> KB8UYR/6
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785