You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Lucian Adrian Grijincu <lu...@avira.com> on 2007/01/17 16:01:15 UTC
_FILE_OFFSET_BITS=64 _LARGEFILE_SOURCE undefined when LFS enabled
when I compile APR with "--enable-lfs" only _LARGEFILE64_SOURCE gets
added to the CFLAGS.
my application depends on "_FILE_OFFSET_BITS=64" and "_LARGEFILE_SOURCE"
and I have some problems linking with the APR code.
apr_dir_read puts the returned data in and apr_finfo_t structure, which
has an apr_ino_t field. This field is 4 or 8 bytes in size dependent on
_FILE_OFFSET_BITS=64 being either undefined or defined.
now, if apr_ino_t would be an 8 bytes value on all platforms (using only
the lower 4 bytes on all platforms that only need those) this would not
be such an issue (I haven't seen any other problem yet coming from
compiling with a different set of flags ), but I'd like to know why APR
only defines _LARGEFILE64_SOURCE, and doesn't provide a means to specify
the rest of the flags.
--
Thanx,
Lucian Adrian Grijincu
Re: _FILE_OFFSET_BITS=64 _LARGEFILE_SOURCE undefined when LFS enabled
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
and 0.9.x's head
On 9/17/07, Lucian Adrian Grijincu <lu...@gmail.com> wrote:
> I've included a rechecked patch for trunk and one for 1.2.x's head.
>
> for 1.2.x I needed an autotools macro that I stole from trunk's
> build/apr_common.m4
>
> --
> Lucian
>
> On 9/17/07, Lucian Adrian Grijincu <lu...@gmail.com> wrote:
> > Sorry.
> > I obviously sent the wrong patch ...
> > Fixed.
> >
> >
> > --
> > Lucian
> >
> > On 9/17/07, Lucian Adrian Grijincu <lu...@gmail.com> wrote:
> > > I'm exercising my puny autotools skills now. this may be erroneous and
> > > should be tested on platforms other than Ubuntu Linux x86.
> > >
> > > Basically it's down to this: compare ino_t with the size of uint,
> > > ulong and ulonglong.
> > > Which ever matches gets to be defined in apr.h
> > > If none match it will fall back to ino_t.
> > >
> > > Windows gets the same value as the one in include/apr_file_info.h,
> > > namely apr_uint64_t.
> > >
> > > I hope that NETWARE uses autotools too :)
> > >
> > > Do we need a APR_INO_T_FMT ?
> > >
> > > On 9/17/07, Joe Orton <jo...@redhat.com> wrote:
> > > > On Sun, Sep 16, 2007 at 05:51:39PM +0300, Lucian Adrian Grijincu wrote:
> > > > > Currently APR still uses ino_t in apr_file_info.h in trunk:
> > > > > http://svn.apache.org/viewvc/apr/apr/trunk/include/apr_file_info.h?view=markup
> > > > > and compiling with _FILE_OFFSET_BITS=64 will change the ABI:
> > > > > sizeof(apr_ino_t) == sizeof(ino_t) == 4 or 8 depending on the
> > > > > compile time flags.
> > > > >
> > > > > Removing the dependency on the ino_t and using Peter's patch will
> > > > > preserve ABI regardless of _FILE_OFFSET_BITS=64 being defined or not.
> > > > >
> > > > > Is this not considered a bug of the header files?
> > > >
> > > > Hmmm, good point, yes, it is. I'm not sure why this doesn't render the
> > > > off_t==long changes completely useless. Do you have a patch?
> > > >
> > > > joe
> > > >
> > >
> > >
> >
> >
>
>
Re: _FILE_OFFSET_BITS=64 _LARGEFILE_SOURCE undefined when LFS enabled
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
I've included a rechecked patch for trunk and one for 1.2.x's head.
for 1.2.x I needed an autotools macro that I stole from trunk's
build/apr_common.m4
--
Lucian
On 9/17/07, Lucian Adrian Grijincu <lu...@gmail.com> wrote:
> Sorry.
> I obviously sent the wrong patch ...
> Fixed.
>
>
> --
> Lucian
>
> On 9/17/07, Lucian Adrian Grijincu <lu...@gmail.com> wrote:
> > I'm exercising my puny autotools skills now. this may be erroneous and
> > should be tested on platforms other than Ubuntu Linux x86.
> >
> > Basically it's down to this: compare ino_t with the size of uint,
> > ulong and ulonglong.
> > Which ever matches gets to be defined in apr.h
> > If none match it will fall back to ino_t.
> >
> > Windows gets the same value as the one in include/apr_file_info.h,
> > namely apr_uint64_t.
> >
> > I hope that NETWARE uses autotools too :)
> >
> > Do we need a APR_INO_T_FMT ?
> >
> > On 9/17/07, Joe Orton <jo...@redhat.com> wrote:
> > > On Sun, Sep 16, 2007 at 05:51:39PM +0300, Lucian Adrian Grijincu wrote:
> > > > Currently APR still uses ino_t in apr_file_info.h in trunk:
> > > > http://svn.apache.org/viewvc/apr/apr/trunk/include/apr_file_info.h?view=markup
> > > > and compiling with _FILE_OFFSET_BITS=64 will change the ABI:
> > > > sizeof(apr_ino_t) == sizeof(ino_t) == 4 or 8 depending on the
> > > > compile time flags.
> > > >
> > > > Removing the dependency on the ino_t and using Peter's patch will
> > > > preserve ABI regardless of _FILE_OFFSET_BITS=64 being defined or not.
> > > >
> > > > Is this not considered a bug of the header files?
> > >
> > > Hmmm, good point, yes, it is. I'm not sure why this doesn't render the
> > > off_t==long changes completely useless. Do you have a patch?
> > >
> > > joe
> > >
> >
> >
>
>
Re: _FILE_OFFSET_BITS=64 _LARGEFILE_SOURCE undefined when LFS enabled
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
Sorry.
I obviously sent the wrong patch ...
Fixed.
--
Lucian
On 9/17/07, Lucian Adrian Grijincu <lu...@gmail.com> wrote:
> I'm exercising my puny autotools skills now. this may be erroneous and
> should be tested on platforms other than Ubuntu Linux x86.
>
> Basically it's down to this: compare ino_t with the size of uint,
> ulong and ulonglong.
> Which ever matches gets to be defined in apr.h
> If none match it will fall back to ino_t.
>
> Windows gets the same value as the one in include/apr_file_info.h,
> namely apr_uint64_t.
>
> I hope that NETWARE uses autotools too :)
>
> Do we need a APR_INO_T_FMT ?
>
> On 9/17/07, Joe Orton <jo...@redhat.com> wrote:
> > On Sun, Sep 16, 2007 at 05:51:39PM +0300, Lucian Adrian Grijincu wrote:
> > > Currently APR still uses ino_t in apr_file_info.h in trunk:
> > > http://svn.apache.org/viewvc/apr/apr/trunk/include/apr_file_info.h?view=markup
> > > and compiling with _FILE_OFFSET_BITS=64 will change the ABI:
> > > sizeof(apr_ino_t) == sizeof(ino_t) == 4 or 8 depending on the
> > > compile time flags.
> > >
> > > Removing the dependency on the ino_t and using Peter's patch will
> > > preserve ABI regardless of _FILE_OFFSET_BITS=64 being defined or not.
> > >
> > > Is this not considered a bug of the header files?
> >
> > Hmmm, good point, yes, it is. I'm not sure why this doesn't render the
> > off_t==long changes completely useless. Do you have a patch?
> >
> > joe
> >
>
>
Re: _FILE_OFFSET_BITS=64 _LARGEFILE_SOURCE undefined when LFS enabled
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
I'm exercising my puny autotools skills now. this may be erroneous and
should be tested on platforms other than Ubuntu Linux x86.
Basically it's down to this: compare ino_t with the size of uint,
ulong and ulonglong.
Which ever matches gets to be defined in apr.h
If none match it will fall back to ino_t.
Windows gets the same value as the one in include/apr_file_info.h,
namely apr_uint64_t.
I hope that NETWARE uses autotools too :)
Do we need a APR_INO_T_FMT ?
On 9/17/07, Joe Orton <jo...@redhat.com> wrote:
> On Sun, Sep 16, 2007 at 05:51:39PM +0300, Lucian Adrian Grijincu wrote:
> > Currently APR still uses ino_t in apr_file_info.h in trunk:
> > http://svn.apache.org/viewvc/apr/apr/trunk/include/apr_file_info.h?view=markup
> > and compiling with _FILE_OFFSET_BITS=64 will change the ABI:
> > sizeof(apr_ino_t) == sizeof(ino_t) == 4 or 8 depending on the
> > compile time flags.
> >
> > Removing the dependency on the ino_t and using Peter's patch will
> > preserve ABI regardless of _FILE_OFFSET_BITS=64 being defined or not.
> >
> > Is this not considered a bug of the header files?
>
> Hmmm, good point, yes, it is. I'm not sure why this doesn't render the
> off_t==long changes completely useless. Do you have a patch?
>
> joe
>
Re: _FILE_OFFSET_BITS=64 _LARGEFILE_SOURCE undefined when LFS enabled
Posted by Joe Orton <jo...@redhat.com>.
On Sun, Sep 16, 2007 at 05:51:39PM +0300, Lucian Adrian Grijincu wrote:
> Currently APR still uses ino_t in apr_file_info.h in trunk:
> http://svn.apache.org/viewvc/apr/apr/trunk/include/apr_file_info.h?view=markup
> and compiling with _FILE_OFFSET_BITS=64 will change the ABI:
> sizeof(apr_ino_t) == sizeof(ino_t) == 4 or 8 depending on the
> compile time flags.
>
> Removing the dependency on the ino_t and using Peter's patch will
> preserve ABI regardless of _FILE_OFFSET_BITS=64 being defined or not.
>
> Is this not considered a bug of the header files?
Hmmm, good point, yes, it is. I'm not sure why this doesn't render the
off_t==long changes completely useless. Do you have a patch?
joe
Re: _FILE_OFFSET_BITS=64 _LARGEFILE_SOURCE undefined when LFS enabled
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
Currently APR still uses ino_t in apr_file_info.h in trunk:
http://svn.apache.org/viewvc/apr/apr/trunk/include/apr_file_info.h?view=markup
and compiling with _FILE_OFFSET_BITS=64 will change the ABI:
sizeof(apr_ino_t) == sizeof(ino_t) == 4 or 8 depending on the
compile time flags.
Removing the dependency on the ino_t and using Peter's patch will
preserve ABI regardless of _FILE_OFFSET_BITS=64 being defined or not.
Is this not considered a bug of the header files?
--
Lucian Adrian Grijincu
On 2/14/07, Peter Samuelson <pe...@p12n.org> wrote:
>
> [sorry for late reply, I'm catching up a bit on old list mail]
>
> [Lucian Adrian Grijincu]
> > apr_dir_read puts the returned data in and apr_finfo_t structure, which
> > has an apr_ino_t field. This field is 4 or 8 bytes in size dependent on
> > _FILE_OFFSET_BITS=64 being either undefined or defined.
>
> Indeed - but forcing every apr-using application to also use LFS is not
> optimal either.
>
> We ran into this issue in Debian, and kludged it by patching
> apr_file_info.h not to use ino_t at all, but instead 'unsigned int' or
> 'unsigned long' depending on platform. I also added a build-time test
> to ensure we're using the same field size on each platform that we did
> before the patch, so as not to change our ABI (so apps did not need to
> be recompiled).
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFF0imLXk7sIRPQRh0RApMDAJoCnvyRlxsR2SRaHOjwOOIC05BCmwCeKd9v
> /ZhhYgQVmW71UffTned5xWc=
> =z8Gf
> -----END PGP SIGNATURE-----
>
>
>
Re: _FILE_OFFSET_BITS=64 _LARGEFILE_SOURCE undefined when LFS enabled
Posted by Peter Samuelson <pe...@p12n.org>.
[sorry for late reply, I'm catching up a bit on old list mail]
[Lucian Adrian Grijincu]
> apr_dir_read puts the returned data in and apr_finfo_t structure, which
> has an apr_ino_t field. This field is 4 or 8 bytes in size dependent on
> _FILE_OFFSET_BITS=64 being either undefined or defined.
Indeed - but forcing every apr-using application to also use LFS is not
optimal either.
We ran into this issue in Debian, and kludged it by patching
apr_file_info.h not to use ino_t at all, but instead 'unsigned int' or
'unsigned long' depending on platform. I also added a build-time test
to ensure we're using the same field size on each platform that we did
before the patch, so as not to change our ABI (so apps did not need to
be recompiled).