Hi,
Am 28.04.2012 16:25, schrieb Olivier Teuliere:
> 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:
> http://comments.gmane.org/gmane.comp.apache.apr.devel/12331
>
> The macro APR_OFF_T_STRFN is defined like this for win32:
>
> #if APR_HAS_LARGE_FILES
> #ifdef APR_INT64_STRFN
> #define APR_OFF_T_STRFN         APR_INT64_STRFN
> #else
> #define APR_OFF_T_STRFN         apr_strtoi64
> #endif
> #else
> #if defined(_WIN32_WCE)
> #define APR_OFF_T_STRFN         strtol
> #else
> #define APR_OFF_T_STRFN         strtoi
> #endif
> #endif
>
> 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
>      aprlfs=1
>      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
>      aprlfs=1
> else
>      aprlfs=0
> fi
>
>
> 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...
I can confirm this - just came over this failure few days ago;
but I hadnt the time to look closer into it ...

Günter.