search

estraier / tkrzw

a set of implementations of DBM
Apache License 2.0
164 stars 20 forks source link

GCC < 9 incompatibility #17

Closed tieugene closed 3 years ago

tieugene commented 3 years ago

Readme.md:

To build the library, GCC 7.3 or later version is required.

Build for CentOS8 (gcc 8.3.1):

g++ -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -std=c++17 -pthread -fPIC -fsigned-char -o tkrzw_build_util tkrzw_build_util.o -Wl,-z,relro  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L. -L/usr/lib64 -Wl,-rpath-link,.:/usr/local/lib:.:/usr/local/lib: -Wl,--as-needed -L. -L/usr/lib64 -ltkrzw -lstdc++ -lrt -lpthread -lm -lc 
./libtkrzw.so: undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
./libtkrzw.so: undefined reference to `std::filesystem::resize_file(std::filesystem::__cxx11::path const&, unsigned long)'
collect2: error: ld returned 1 exit status
make: *** [Makefile:662: tkrzw_build_util] Error 1

(full log)

estraier commented 3 years ago

This is a tricky problem. There's no other way than std::filesystem::resize_file to truncate files in the range of C++ standard. I don't want to use the std::filesystem component because its support by GCC is limited. The concept of the StdFile class is to ensure portability of the file class on every platform which support the C++17 standard. However, ironically, no platform supports C++17 fully so the existence of StdFile restricts portability. I'll write a fall back function which internally use native system calls.

On Wed, May 12, 2021 at 8:32 PM Eugene @.***> wrote:

Readme.md:

To build the library, GCC 7.3 or later version is required.

Build for CentOS8 (gcc 8.3.1):

g++ -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -std=c++17 -pthread -fPIC -fsigned-char -o tkrzw_build_util tkrzw_build_util.o -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L. -L/usr/lib64 -Wl,-rpath-link,.:/usr/local/lib:.:/usr/local/lib: -Wl,--as-needed -L. -L/usr/lib64 -ltkrzw -lstdc++ -lrt -lpthread -lm -lc ./libtkrzw.so: undefined reference to std::filesystem::__cxx11::path::_M_split_cmpts()' ./libtkrzw.so: undefined reference tostd::filesystem::resize_file(std::filesystem::__cxx11::path const&, unsigned long)' collect2: error: ld returned 1 exit status make: *** [Makefile:662: tkrzw_build_util] Error 1

(full log https://koji.fedoraproject.org/koji/taskinfo?taskID=67758191)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/estraier/tkrzw/issues/17, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQGJVRBTKAWNEPKKCW25S3DTNJRNRANCNFSM44YNIJXA .

tieugene commented 3 years ago

I worked around this for CentOS8 enabling GCC10 instead of 8.3 normally used. But the sentence "GCC 7.3 or later" is not actual.

estraier commented 3 years ago

I committed a change to remove dependency on std::filesystem.

tieugene commented 3 years ago

I committed a change to remove dependency on std::filesystem.

May be this is too strict solution. 'filesystem' is very usual thing and filesystem::path is highly recommended instead of char * for file/folder names. I solved this problem in CentOS8 and seems nobody else interesting in. Just note in Readme.md "GCC 7.3 9.0 or later" (or something like "C++17 less or more compatible compiler")

estraier commented 3 years ago

In Tkrzw, only the truncating function used std::filesystem feature. Other operations related to path and the file system are implemented as utilities in tkrzw_file_util.h. Considering portability on systems including Windows and other Unix-like systems than Linux/Mac, the current policy is practical. I agree that the path object is smarter than char*, though.

tieugene commented 3 years ago

0.9.16 @ RH8 (GCC 8.3.1) ok