apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Teuliere <ipk...@gmail.com>
Subject Incorrect value of APR_HAS_LARGE_FILES on win32
Date Sat, 28 Apr 2012 14:25:00 GMT

When cross-compiling a program for win32 (on linux, using mingw32),
the linking with apr-2 (svn version as of today) failed with the
following error:
/some/path/lib/libapr-2.a(apr_strings.o): In function `apr_strtoff@16':
/some/other/path/apr/strings/apr_strings.c:240: undefined reference to `_strtoi'

The error is very similar to the one in this old thread, which was
apparently never solved:

The macro APR_OFF_T_STRFN is defined like this for win32:

#ifdef APR_INT64_STRFN
#define APR_OFF_T_STRFN         APR_INT64_STRFN
#define APR_OFF_T_STRFN         apr_strtoi64
#if defined(_WIN32_WCE)
#define APR_OFF_T_STRFN         strtol
#define APR_OFF_T_STRFN         strtoi

APR_HAS_LARGE_FILES is set to 0, so the last define is used and
APR_OFF_T_STRFN is defined to strtoi.

If I understand correctly, APR_HAS_LARGE_FILES should be set to 1
instead. This variable is set in include/apr.h, itself generated from
include/apr.h.in, using the autoconf variable aprlfs.

The following lines in configure.in (starting at line 1690) define aprlfs:

APR_CHECK_SIZEOF_EXTENDED([#include <sys/types.h>], off_t, 8)

if test "${ac_cv_sizeof_off_t}${apr_cv_use_lfs64}" = "4yes"; then
    # Enable LFS
    AC_CHECK_FUNCS([mmap64 sendfile64 sendfilev64 mkstemp64 readdir64_r])
elif test "${ac_cv_sizeof_off_t}" != "${ac_cv_sizeof_size_t}"; then
    # unsure of using -gt above is as portable, can can't forsee where
    # off_t can legitimately be smaller than size_t

Here are the relevant values in my case:
ac_cv_sizeof_off_t = 8
ac_cv_sizeof_size_t = 8
apr_cv_use_lfs64 = yes

So with these tests, aprlfs is set to 0. Patching configure.in to set
it to 1 unconditionally defines APR_HAS_LARGE_FILES to 1, and it
solves my link problem, but I thought I would tell you, so you can
implement a more subtle fix to this problem. In particular, the
hard-coded "4yes" seems a bit strange to me, but I don't understand
the logic enough to propose a fix myself...

Best regards,
Olivier Teulière

View raw message