Fix 32-bit ABI bugs of android

[LilyWangLL]

What does this change do?
Fixes #204, fix 32-bit ABI bugs of android: https://android.googlesource.com/platform/bionic/+/master/docs/32-bit-abi.md#32_bit-and

The description of this bug:

Android does not require the _LARGEFILE_SOURCE macro to be used to make fseeko and ftello available. Instead they're always available from API level 24 where they were introduced, and never available before then.

The related error message:

[1/3] /android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ -Isrc/libtomlplusplus.a.p -Isrc -I../src/v3.3.0-055894c820.clean/src -Iinclude -I../src/v3.3.0-055894c820.clean/include -I/mnt/vcpkg-ci/installed/arm-neon-android/include -fvisibility=hidden -fcolor-diagnostics -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++17 -O0 -g --target=armv7-none-linux-androideabi21 -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -march=armv7-a -mthumb -Wformat -Werror=format-security -frtti -fexceptions -fPIC --sysroot=/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot -fno-limit-debug-info -fPIC -ferror-limit=5 -Wno-unused-command-line-argument -Wno-reserved-macro-identifier -fchar8_t -D_HAS_EXCEPTIONS=1 -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-documentation -Wno-documentation-unknown-command -Wno-switch-enum -Wno-covered-switch-default -Wno-padded -Wno-float-equal -DTOML_HEADER_ONLY=0 -MD -MQ src/libtomlplusplus.a.p/toml.cpp.o -MF src/libtomlplusplus.a.p/toml.cpp.o.d -o src/libtomlplusplus.a.p/toml.cpp.o -c ../src/v3.3.0-055894c820.clean/src/toml.cpp
FAILED: src/libtomlplusplus.a.p/toml.cpp.o 
/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ -Isrc/libtomlplusplus.a.p -Isrc -I../src/v3.3.0-055894c820.clean/src -Iinclude -I../src/v3.3.0-055894c820.clean/include -I/mnt/vcpkg-ci/installed/arm-neon-android/include -fvisibility=hidden -fcolor-diagnostics -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++17 -O0 -g --target=armv7-none-linux-androideabi21 -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -march=armv7-a -mthumb -Wformat -Werror=format-security -frtti -fexceptions -fPIC --sysroot=/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot -fno-limit-debug-info -fPIC -ferror-limit=5 -Wno-unused-command-line-argument -Wno-reserved-macro-identifier -fchar8_t -D_HAS_EXCEPTIONS=1 -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-documentation -Wno-documentation-unknown-command -Wno-switch-enum -Wno-covered-switch-default -Wno-padded -Wno-float-equal -DTOML_HEADER_ONLY=0 -MD -MQ src/libtomlplusplus.a.p/toml.cpp.o -MF src/libtomlplusplus.a.p/toml.cpp.o.d -o src/libtomlplusplus.a.p/toml.cpp.o -c ../src/v3.3.0-055894c820.clean/src/toml.cpp
In file included from ../src/v3.3.0-055894c820.clean/src/toml.cpp:13:
In file included from ../src/v3.3.0-055894c820.clean/include/toml++/toml.h:69:
In file included from ../src/v3.3.0-055894c820.clean/include/toml++/impl/parser.inl:26:
/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/fstream:952:20: error: use of undeclared identifier 'ftello'; did you mean 'ftell'?
    pos_type __r = ftello(__file_);
                   ^
/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/cstdio:141:9: note: 'ftell' declared here
using ::ftell;
        ^
In file included from ../src/v3.3.0-055894c820.clean/src/toml.cpp:13:
In file included from ../src/v3.3.0-055894c820.clean/include/toml++/toml.h:69:
In file included from ../src/v3.3.0-055894c820.clean/include/toml++/impl/parser.inl:26:
/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/fstream:950:9: error: use of undeclared identifier 'fseeko'
    if (fseeko(__file_, __width > 0 ? __width * __off : 0, __whence))
        ^
/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/fstream:213:5: note: in instantiation of member function 'std::basic_filebuf<char>::seekoff' requested here
    basic_filebuf();
    ^
/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/fstream:1142:5: note: in instantiation of member function 'std::basic_filebuf<char>::basic_filebuf' requested here
    basic_ifstream();

Is it related to an exisiting bug report or feature request?

Pre-merge checklist

• I've read CONTRIBUTING.md
• I've rebased my changes against the current HEAD of origin/master (if necessary)
• I've added new test cases to verify my change
• I've regenerated toml.hpp (how-to)
• I've updated any affected documentation
• I've rebuilt and run the tests with at least one of:
  • Clang 8 or higher
  • GCC 8 or higher
  • MSVC 19.20 (Visual Studio 2019) or higher
• I've added my name to the list of contributors in README.md

[marzer]

You have crossed out the "regenerating toml.hpp" step, but also ticked yes that you have read CONTRIBUTING.hpp. One belies the other; it is clearly stated in CONTRIBUTING.md that you must regenerate the single-header version of the library (you can see that your CI checks have failed because of it). Not a great look, tbh.

Aside from that, I am suspicious of this 'fix' more generally. You're stuffing what should be a build-system-wide macro definition into a specific library? Surely there's a better solution, one that doesn't involve polluting TOML++ with something that has nothing to do with it.

This issue seems to indicate the best course of action should be determined per-project, according to the needs of the user. Which supports my suspicion that this should be a build-system-level fix.

Please don't bother me with this again. This bug has nothing to do with my library, and since fixing it requires a global #define (which is not OK for a header-only library), TOML++ is not the right place to fix it. Adding -Dftello=ftell and -Dfseeko=fseek to your project's compile arguments should do the trick.

[marzer]

@LilyWangLL Note that you can probably side-step this issue entirely if you use the single-header version of the library directly, that way there's no global symbols to define and you don't need to worry about separately compiling a library binary.