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...@gmail.com> on 2007/09/16 16:51:39 UTC
Re: _FILE_OFFSET_BITS=64 _LARGEFILE_SOURCE undefined when LFS enabled
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 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