You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Dzonatas <dz...@dzonux.net> on 2007/04/01 21:17:17 UTC

APR defaults to "strtoi" instead of "strtoi64" with MinGW

I'm have used the APR 1.3.0 branch. My link came up with a undefined 
reference to "_strtoi."

Does MSVC automatically fudge "strtoi" to "strtoi64"? That is the way it 
is found in msvcr71.

With the section shown below, a quick hack may be to define on cppflags 
"-Dstrtoi=stroi64" or "-Dstrtoi=_strtoi64". However, I thought I show 
you this for your review.

In apr/include/arch/win32/apr_private.h, there is this section (about 
line 160):

/* MSVC 7.0 introduced _strtoi64 */
#if _MSC_VER >= 1300 && _INTEGRAL_MAX_BITS >= 64
#define APR_INT64_STRFN       _strtoi64
#endif

#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
#define APR_OFF_T_STRFN         strtoi
#endif

Re: APR_HAS_LARGE_FILES

Posted by Dzonatas <dz...@dzonux.net>.
I compiled for an i686. From the config.log:

ac_cv_sizeof_char=1
ac_cv_sizeof_int=4
ac_cv_sizeof_long=4
ac_cv_sizeof_long_long=8
ac_cv_sizeof_off_t=8  
ac_cv_sizeof_pid_t=8
ac_cv_sizeof_short=2  
ac_cv_sizeof_size_t=4
ac_cv_sizeof_ssize_t=4

I did manually set ac_cv_sizeof_size_t and ssize_t since configure can't 
run a cross-compiled program.

William A. Rowe, Jr. wrote:
> What's your sizeof(int)?
>
> If int is the sizeof off_t at 64 bits this would explain allot.
>
> But AFAIK, int on win32 always is never 32 bits, being a 64LP platform.
>
>

Re: APR_HAS_LARGE_FILES

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
What's your sizeof(int)?

If int is the sizeof off_t at 64 bits this would explain allot.

But AFAIK, int on win32 always is never 32 bits, being a 64LP platform.

Dzonatas wrote:
> That is an interesting note.
> 
> My config.log reports:
> ac_cv_sizeof_off_t=8
> apr_cv_use_lfs64=yes
> aprlfs='0'
> 
> Do also note that I run a modern paravirtualized OS of Linux and
> Microsoft. My cross-compilations happen on Linux, which was compiled by
> MinGW. The two OSs cooperate nicely for their share of a processor. I'm
> not biased. =)
> 
> I'll see if I can find the right bit to hack... I mean... configure.
> 
> Thank you.
> 
> William A. Rowe, Jr. wrote:
>> It's sort of an academic question, since the crux of the problem is that
>> the Win32 API supports large files in all situations, and any additional
>> layer (e.g. MinGW) which doesn't use the Win32 API, or doesn't provide
>> APR_HAS_LARGE_FILES, is fundementally broken as a compilation to this
>> modern operating system ;-)
>>   
> 
> 
>

Re: APR_HAS_LARGE_FILES (was: "strtoi"... with MinGW)

Posted by Dzonatas <dz...@dzonux.net>.
That is an interesting note.

My config.log reports:
ac_cv_sizeof_off_t=8
apr_cv_use_lfs64=yes
aprlfs='0'

Do also note that I run a modern paravirtualized OS of Linux and 
Microsoft. My cross-compilations happen on Linux, which was compiled by 
MinGW. The two OSs cooperate nicely for their share of a processor. I'm 
not biased. =)

I'll see if I can find the right bit to hack... I mean... configure.

Thank you.

William A. Rowe, Jr. wrote:
> It's sort of an academic question, since the crux of the problem is that
> the Win32 API supports large files in all situations, and any additional
> layer (e.g. MinGW) which doesn't use the Win32 API, or doesn't provide
> APR_HAS_LARGE_FILES, is fundementally broken as a compilation to this
> modern operating system ;-)
>

Re: APR defaults to "strtoi" instead of "strtoi64" with MinGW

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
It's sort of an academic question, since the crux of the problem is that
the Win32 API supports large files in all situations, and any additional
layer (e.g. MinGW) which doesn't use the Win32 API, or doesn't provide
APR_HAS_LARGE_FILES, is fundementally broken as a compilation to this
modern operating system ;-)



Dzonatas wrote:
> I'm have used the APR 1.3.0 branch. My link came up with a undefined
> reference to "_strtoi."
> 
> Does MSVC automatically fudge "strtoi" to "strtoi64"? That is the way it
> is found in msvcr71.
> 
> With the section shown below, a quick hack may be to define on cppflags
> "-Dstrtoi=stroi64" or "-Dstrtoi=_strtoi64". However, I thought I show
> you this for your review.
> 
> In apr/include/arch/win32/apr_private.h, there is this section (about
> line 160):
> 
> /* MSVC 7.0 introduced _strtoi64 */
> #if _MSC_VER >= 1300 && _INTEGRAL_MAX_BITS >= 64
> #define APR_INT64_STRFN       _strtoi64
> #endif
> 
> #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
> #define APR_OFF_T_STRFN         strtoi
> #endif
> 
> 
>