#2 Change large file support to more portable

Merged
SlavekB merged 1 commits from feat/portable-large-file-support into master 8 months ago
obache commented 9 months ago

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.

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.
SlavekB commented 9 months ago
Owner

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

Please correct the commit log – WIP probably should not be part of the commit log and there is a typo chnage × change.
cethyel commented 9 months ago
Collaborator

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

Talking about portability, shouldn't "-D_GNU_SOURCE" be changed for "-D_DEFAULT_SOURCE" in kttsd/players/alsaplayer/Makefile.am?
SlavekB commented 9 months ago
Owner

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.

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.
MicheleC commented 9 months ago
Owner

_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.

_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.
SlavekB commented 9 months ago
Owner

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?

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](../tdelibs/src/branch/master/tdeio/CMakeLists.txt#L13), 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?
MicheleC commented 9 months ago
Owner

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

Sounds like a good idea.

```Should we add an equivalent test for large files to a common CMake module?``` Sounds like a good idea.
MicheleC commented 9 months ago
Owner

@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.

@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.
obache commented 8 months ago
Poster

Adding “WIP” is just following the guide.

Adding "WIP" is just following the guide.
SlavekB commented 8 months ago
Owner

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.

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.
obache commented 8 months ago
Poster

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.

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.
SlavekB changed title from WIP: change large file support to more portable to Change large file support to more portable 8 months ago
SlavekB deleted branch feat/portable-large-file-support 8 months ago
SlavekB added this to the R14.0.6 release milestone 8 months ago
The pull request has been merged.
Sign in to join this conversation.
Loading…
Cancel
Save
There is no content yet.