Using <filesystem> on macOS 10.13 with clang++-mp-13

[Ruben Di Battista]

More context:

basically it fills up (+ add the right library to link against) the `
filesystem.h.in` header template with the right #include and namespace
based on what is found on the platform. The idea was to use <filesystem> or
<experimental/filesystem> where available, and fallback to
https://github.com/gulrak/filesystem where not available.

On Wed, Jul 6, 2022 at 10:24 PM Ruben Di Battista <rubendibattista at gmail.com>
wrote:

> A partial solution I implemented using `cmake` for a project of mine:
>
> 1.
> https://gitlab.com/rdbisme/mercurve/-/blob/master/cmake/ConfigureFilesystemHeader.cmake
> 2. https://gitlab.com/rdbisme/mercurve/-/blob/master/src/filesystem.h.in
> 3.
> https://gitlab.com/rdbisme/mercurve/-/blob/master/src/apps/CMakeLists.txt#L20
>
>
>
> That can be improved for the use case here mentioned? The check for macOS
> is commented in the ConfigureFilesystemHeader, but maybe it can be
> completed to make it work.
>
>
> On Sun, Jul 3, 2022 at 8:38 PM Ken Cunningham <
> ken.cunningham.webuse at gmail.com> wrote:
>
>> This is an issue that will need solving, otherwise as filesystem is used
>> more (and it seems popular) all the systems prior to 10.15 will be left
>> behind.
>>
>> Filesystem uses features in libc++.dylib that are only present in 10.15
>> and newer. You are blocked from trying to use them on 10.14 and below by a
>> blocker in the clang "__config" header, that is easy to override, but when
>> you try to use filesystem, it will not find the libc++.dylib features and
>> will fail.
>>
>> You can (sometimes) use macports-libcxx to get past this. This however
>> introduces two versions of libc++.dylib into the softare mixture, and this
>> sometimes causes errors due to incompatibilities between libc++ versions
>> (ODR errors). If you are taking this route, linking in the newer libc++.a
>> statically has a higher chance of working properly (that is what Chrome
>> does on older MacOS systems).
>>
>> You can use gcc/libgcc, and newer versions of that have filesystem
>> support, but that causes it's own issues.
>>
>> There was an early version of filesystem available as
>> <experimental/filesystem> with a linking static library on older versions
>> of clang. I forget when that disappeared, but maybe clang-8.0. It is
>> possible that this might be brought forward to newer clangs and made
>> available to older systems with modest effort. This is likely the most
>> robust approach going forward, as it is the same code (although older).
>>
>> There are a few versions of filesystem available from other places, some
>> header-only, that might or might not work in a general sense. These have
>> the disadvantage of having nothing to do with clang/llvm, therefore I
>> presume the chances of unfavourable interactions would be somewhat higher.
>>
>> Hope this is helpful,
>>
>> Ken
>>
>> On Sun, Jul 3, 2022 at 4:12 AM Mojca Miklavec <mojca at macports.org> wrote:
>>
>>> Hi,
>>>
>>> I'm trying to build some sources that require <filesystem> on 10.13
>>> using clang 13 (I can try with clang 14, but I doubt that it helps).
>>>
>>> What's the correct way to compile the following minimal example? Do I
>>> need to link against a newer libc++ somehow?
>>>
>>> If it's not feasible to do that, I'll target a newer OS, I was just
>>> silently hoping to have some success ;)
>>>
>>> Thank you,
>>>     Mojca
>>>
>>> #include <cstdlib>
>>> #include <filesystem>
>>>
>>> int main() {
>>>     auto cwd = std::filesystem::current_path();
>>>     printf("%s", cwd.c_str());
>>>     return EXIT_SUCCESS;
>>> }
>>>
>>> > clang++-mp-13 test.cpp -o test
>>> test.cpp:5:16: error: no member named 'filesystem' in namespace 'std';
>>> did you mean 'std::__fs::filesystem'?
>>>     auto cwd = std::filesystem::current_path();
>>>                ^~~~~~~~~~~~~~~
>>>                std::__fs::filesystem
>>> /opt/local/libexec/llvm-13/bin/../include/c++/v1/filesystem:268:1:
>>> note: 'std::__fs::filesystem' declared here
>>> _LIBCPP_BEGIN_NAMESPACE_FILESYSTEM
>>> ^
>>> /opt/local/libexec/llvm-13/bin/../include/c++/v1/__config:816:58:
>>> note: expanded from macro '_LIBCPP_BEGIN_NAMESPACE_FILESYSTEM'
>>>   _LIBCPP_BEGIN_NAMESPACE_STD namespace __fs { namespace filesystem {
>>>                                                          ^
>>> 1 error generated.
>>>
>>> > clang++-mp-13 -std=c++17 test.cpp -o test
>>> Undefined symbols for architecture x86_64:
>>>   "std::__1::__fs::filesystem::__current_path(std::__1::error_code*)",
>>> referenced from:
>>>       std::__1::__fs::filesystem::current_path() in test-1b2bbf.o
>>> ld: symbol(s) not found for architecture x86_64
>>> clang: error: linker command failed with exit code 1 (use -v to see
>>> invocation)
>>>
>>
>
> --
>                 ..
>                /**\
>               /****\
>              /\****/\
>             /  \**/  \
>            /    \/    \
>           /     /\    /\
>          / \   /  \  /  \
>         /   \ /    \/    \
>         \    /\    /\    /
>          \  /  \  /  \  /
>           \/    \/    \/
>                 /\
>                / +\
>                \+ /
>                 \/
>               rdb.is
>        Book a meeting with me:
>      https://calendly.com/rdbisme
>
>
>

-- 
                ..
               /**\
              /****\
             /\****/\
            /  \**/  \
           /    \/    \
          /     /\    /\
         / \   /  \  /  \
        /   \ /    \/    \
        \    /\    /\    /
         \  /  \  /  \  /
          \/    \/    \/
                /\
               / +\
               \+ /
                \/
              rdb.is
       Book a meeting with me:
     https://calendly.com/rdbisme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220706/2cc255d3/attachment-0001.htm>