config: remove CURL_SIZEOF_CURL_OFF_T use only SIZEOF_CURL_OFF_T

[bagder]

Make the code consistently use a single name for the size of the curl_off_t type.

[bagder]

The travis cmake build now fails to set the largefile bit, but it works fine for me locally. 😕

[mback2k]

The same is true for these AppVeyor builds due to:

test 1014...[Compare curl --version with curl-config --features]
  Mismatch in features lists:
  curl:        alt-svc asynchdns ipv6 ntlm
  curl-config: alt-svc asynchdns ipv6 largefile ntlm
   postcheck FAILED

This is the same issue as I experienced with my attempt in #6277. I don't understand this issue, because the condition should end up being the same as in the adjusted CMake file:

curl/lib/curl_setup.h

Line 154 in 246399a

#define CURL_SIZEOF_CURL_OFF_T SIZEOF_CURL_OFF_T

curl/lib/version.c

Lines 402 to 405 in b899cb0

	#if (CURL_SIZEOF_CURL_OFF_T > 4) && \
	( (SIZEOF_OFF_T > 4) || defined(USE_WIN32_LARGE_FILES) )
	| CURL_VERSION_LARGEFILE
	#endif

[mback2k]

I would actually consider this a fix instead of a tidy-up, because previously Largefile support was not detected at all with CMake, because CURL_SIZEOF_CURL_OFF_T is not available in that, just SIZEOF_CURL_OFF_T.

[bagder]

@snikulov Can you bring any lights to this issue?

[jay]

Alternative take at #6704

[bagder]

With the new debug output in the cmake travis CI build showing all the SIZEOF sizes after cmake has run shows they're present in lib/curl_config.h all right...

[mback2k]

What about USE_WIN32_LARGE_FILES? Is that present? Can you please link the output in the travis jobs? And I looked at the AppVeyor jobs and unfortunately they either failed, because #warn is not understood or CMake build is hiding the output of that.

Looking at the code in version.c it should be working... 😞

[bagder]

The travis CI cmake output from the grep.

[bagder]

I wanted to focus on getting the travis cmake build to work first, because that's on Linux and I feel at home there (contrary to anything Windows). But since not even that works even if the two important size defines are set in the include file, it really puzzles me.

[snikulov]

To be honest, I unable to help with this issue, because I'm not familiar with this code. Perhaps I did something for Windows, but definitely not touch this code for Linux. And looks like it either was broken or not worked since the beginning. But you're right feature Largefile is not enabled by default on x86_64 on current HEAD.

…

On Mon, Mar 8, 2021 at 5:49 PM Daniel Stenberg ***@***.***> wrote: @snikulov <https://github.com/snikulov> Can you bring any lights to this issue? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6702 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABCWKZCPM66H3C47IA6L3TTCTPXFANCNFSM4YZHP44A> .

-- Best Regards, Sergei Nikulov

[bagder]

Even when I reversed the conditional check in lib/version.c test 1014 fails the same way on both travis and appveyor!

[bagder]

The irony here is of course that I doubt we ever build on systems these days that don't support "large files"...

[bagder]

I figured it out and it was sillier than you'd expect:

Largefile is not generated as a feature for curl-config by configure, so therefore, the test 1014 scripts removes the word from the curl -V output before it compares it with the curl-config --features output...

[mback2k]

Wouldn't it be better to fix it the other way around then?

[bagder]

Yes, but I think I'll work on that separately once this is fixed, as I believe that provides another opportunity for falling down a bottomless pit! 😆

Nah, let's do it right at once.

[mback2k]

So only travis CI is still failing now, but:

• https://travis-ci.org/github/curl/curl/jobs/762229525 timeout seems unrelated
• https://travis-ci.org/github/curl/curl/jobs/762229531 tests 1561 and 1562 failing seems unrelated

both issues are also happening in current master for some reason.

[bagder]

Yes, they seem unrelated

#6705 works on the torture test fails
The arm64 tests are flaky since before

[bagder]

@jay filed #6704 in the mean time which partly goes in a contrary direction than this so we need to decide.

I like this PR because it both simplifies and unifies the sizeof defines for curl_off_t.