apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyler MacDonald <ty...@yi.org>
Subject Re: apr_stat / apr_file_info_get misbehaving?
Date Wed, 17 May 2006 15:48:12 GMT
William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> First, assure us finfo is an apr_fileinfo_t and not a unixish finfo_t?

	Well, an apr_finfo_t actually. :)

> >    printf("APR: file is %lu bytes\n", finfo.size);
> You might be interested in APR_OFF_T_FMT (I think that's the name)

	I'll check into that, thanks!

> Are you sure apr_off_t fits in %lu in your ./configure'ation?

	Yup. I did %llu the first time, but "-Wall -Werror" wouldn't let me.
:-)

> Uhm - need to tell us if finfo.valid & APR_FINFO_SIZE is set or not.
> 
> _NORM includes _SIZE fwiw.

	... after some more testing, I've found the problem: I'm compiling
my application with large file support, but libapr-0 was *not* compiled with
large file support. APR's headers seem to have some problem with having
"-D_FILE_OFFSET_BITS=64" passed into them if apr support was not enabled.
This really sucks!

	I've attached the test I used to prove this.

	If I compile it with this:

$ make apr_stat.t LDFLAGS=-lapr-0 CPPFLAGS='-I/usr/include/apr-0 -D_FILE_OFFSET_BITS=64' CFLAGS='-Werror
-Wall'

	I get this running it:

$ ./apr_stat.t /home/faraway/test.torrent
1..2
not ok 1 - stat and apr_stat return same size (21296 != 0)
ok 2 - finfo.valid includes APR_FINFO_SIZE

	If I compile it with this (and change the %llu on line 75 to a %lu):

$ make apr_stat.t LDFLAGS=-lapr-0 CPPFLAGS='-I/usr/include/apr-0' CFLAGS='-Werror -Wall'

	I get this instead:

$ ./apr_stat.t /home/faraway/test.torrent
1..2
ok 1 - stat and apr_stat return same size (21296)
ok 2 - finfo.valid includes APR_FINFO_SIZE

	I guess this is a small bug in the apr header files, where they
listen to the environment of the application they're being compiled against,
instead of just the environment of APR when *it* was compiled.

	I'm working on porting a lot of glibc code over to APR right now;
the APR_OFF_T_FMT mentioned above will probably help me work around this
problem.

	It seems like apr_stat() is the only function that can't deal with
the application needing large file support (whether or not APR has it), but
I'm a bit concerned; could anything else in APR break because of this?

	Thanks,
		Tyler



Mime
View raw message