Change large file support to more portable #2

I believe lseek64/off64_t is only supported for some platforms (glibc and solaris ?).

KDE_CHECK_LARGEFILE will set sufficient compiler flags to enable 64bit capable lseek/off_t,
so it is portable to use the autoconf macro and lseek/off_t instead of lseek64/off64_t with
-D_LARGEFILE64_SOURCE.

Please correct the commit log – WIP probably should not be part of the commit log and there is a typo chnage × change.

Talking about portability, shouldn't "-D_GNU_SOURCE" be changed for "-D_DEFAULT_SOURCE" in kttsd/players/alsaplayer/Makefile.am?

Replacing _BSD_SOURCE, _SVID_SOURCE, _GNU_SOURCE with _DEFAULT_SOURCE has already been done by Michele some time ago. Some occurrences appear to have been omitted. I leave this for @MicheleC to check.

_GNU_SOURCE was not replaced. During the replacement of _BSD_SOURCE and _SVID_SOURCE, I also tested replacing _GNU_SOURCE with _DEFAULT_SOURCE but this led to compile errors since _GNU_SOURCE makes GNU extensions available.
_GNU_SOURCE still needs to be used.

I tested build on Debian 10 (Buster) amd64, i386 and armhf – all successful.

There is a question: When building with CMake, there is no equivalent test for large files support. In some CMakeLists.txt we can see hard-coded _LARGEFILE64_SOURCE=1 – for example tdelibs/tdeio/CMakeLists.txt, but there is no test if some of the definitions like _LARGE_FILES, _LARGEFILE_SOURCE and _FILE_OFFSET_BITS=64 are needed. Should we add an equivalent test for large files to a common CMake module?

Should we add an equivalent test for large files to a common CMake module?

Sounds like a good idea.

@obache is it ok to merge? or is this PR marked WIP for a reason (e.g. are you planning more work on this)?

BTW, off64_t is also used in other parts of TDE. It could be a good idea to make similar changes to increase portability.

Adding "WIP" is just following the guide.

We use the WIP label to indicate that the author of PR will still be working on this. If the author thinks, that PR is ready, then will delete the WIP label. That's why it is our question, whether from your perspective PR is still WIP or ready.

You can remove WIP label if this PR is acceptable for you.

I don't know whether it is requested to replace _GNU_SOURCE and convert to cmake additionally.