[libcxx-dev] Is the C++ filesystem object file installed via LLVM's APT repository missing symbols?

Tue Apr 2 14:49:19 PDT 2019

> On Apr 2, 2019, at 17:45, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> 
> 
> 
>> On Apr 2, 2019, at 17:37, Louis Dionne via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
>> 
>> 
>> 
>>> On Apr 2, 2019, at 17:21, Louis Dionne via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
>>> 
>>> 
>>> 
>>>> On Apr 1, 2019, at 19:01, Eric Fiselier via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Mon, Apr 1, 2019 at 9:46 AM TheAspiringHacker via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
>>>> Hello,
>>>> 
>>>> I have downloaded LLVM and Clang 8 from the APT repository (deb http://apt.llvm.org/xenial/ <http://apt.llvm.org/xenial/> llvm-toolchain-xenial-8 main). When I compile and link
>>>> 
>>>> #include <filesystem>
>>>> 
>>>> namespace fs = std::filesystem;
>>>> 
>>>> int main()
>>>> {
>>>>     fs::path wd = fs::current_path();
>>>>     return 0;
>>>> }
>>>> 
>>>> with clang-8 -std=c++17 -stdlib=libc++ -lc++ -lc++abi -lc++fs test.cpp -v
>>>> 
>>>> I get the output:
>>>> 
>>>> clang version 8.0.0-svn356034-1~exp1~20190313094121.53 (branches/release_80)
>>>> Target: x86_64-pc-linux-gnu
>>>> Thread model: posix
>>>> InstalledDir: /usr/bin
>>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
>>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0
>>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
>>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.5.0
>>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
>>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.4.0
>>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.5.0
>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.5.0
>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.4.0
>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
>>>> Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0
>>>> Candidate multilib: .;@m64
>>>> Selected multilib: .;@m64
>>>> "/usr/lib/llvm-8/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -v -resource-dir /usr/lib/llvm-8/lib/clang/8.0.0 -internal-isystem /usr/lib/llvm-8/bin/../include/c++/v1 -internal-isystem /usr/include/clang/8.0.0/include/ -internal-isystem /usr/local/include -internal-isystem /usr/lib/llvm-8/lib/clang/8.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++17 -fdeprecated-macro -fdebug-compilation-dir /home/<username> -ferror-limit 19 -fmessage-length 0 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o /tmp/test-b088e9.o -x c++ test.cpp -faddrsig
>>>> clang -cc1 version 8.0.0 based upon LLVM 8.0.0 default target x86_64-pc-linux-gnu
>>>> ignoring nonexistent directory "/include"
>>>> ignoring duplicate directory "/usr/include/clang/8.0.0/include"
>>>> #include "..." search starts here:
>>>> #include <...> search starts here:
>>>> /usr/lib/llvm-8/bin/../include/c++/v1
>>>> /usr/include/clang/8.0.0/include
>>>> /usr/local/include
>>>> /usr/include/x86_64-linux-gnu
>>>> /usr/include
>>>> End of search list.
>>>> "/usr/bin/ld" --hash-style=both --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0/../../../x86_64-linux-gnu/crt1.o /usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0/../../../x86_64-linux-gnu/crti.o /usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0/crtbegin.o -L/usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0 -L/usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0/../../.. -L/usr/lib/llvm-8/bin/../lib -L/lib -L/usr/lib -lc++ -lc++abi -lc++fs /tmp/test-b088e9.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0/crtend.o /usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0/../../../x86_64-linux-gnu/crtn.o
>>>> /tmp/test-b088e9.o: In function `std::__1::__fs::filesystem::current_path()':
>>>> test.cpp:(.text._ZNSt3__14__fs10filesystem12current_pathEv[_ZNSt3__14__fs10filesystem12current_pathEv]+0x14): undefined reference to `std::__1::__fs::filesystem::__current_path(std::__1::error_code*)'
>>>> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>>>> 
>>>> 
>>>> I ran:
>>>> 
>>>> nm -C /usr/lib/llvm-8/lib/libc++fs.a | fgrep 'std::__1::__fs::filesystem::__current_path'
>>>> 
>>>> and got:
>>>> 
>>>> 0000000000002540 T std::__1::__fs::filesystem::__current_path(std::__1::error_code*)
>>>> 0000000000002880 T std::__1::__fs::filesystem::__current_path(std::__1::__fs::filesystem::path const&, std::__1::error_code*)
>>>> 
>>>> It seems that the `current_path` functions, as defined in the libc++fs.a file that I installed, do not match the overloads as documented at https://en.cppreference.com/w/cpp/filesystem/current_path <https://en.cppreference.com/w/cpp/filesystem/current_path> or specified in the filesystem header file of libc++. According to http://libcxx.llvm.org/ts1z_status.html <http://libcxx.llvm.org/ts1z_status.html>, as of June 17, 2016, the filesystem library is complete. For comparison, the APT repository was last updated on March 27, 2019.
>>>> 
>>>> I do not know if perhaps I made a mistake in linking the code or installing the library. https://libcxx.llvm.org/ <https://libcxx.llvm.org/> directed me to ask here if I'm not sure whether I found a bug.
>>>> 
>>>> Is this an issue with the files I downloaded from the APT repository, or is it my own mistake?
>>>> 
>>>> Your invocation of Clang puts -lc++fs before the source file that depends on it.
>>>> You need to put the source file before the libraries. Ex:
>>>> 
>>>>  clang-8 -std=c++17 -stdlib=libc++ test.cpp -lc++fs -v
>>> 
>>> 
>>> Isn't that something that Clang should handle?
>> 
>> To clarify, what I meant is that from a very naive point of view, the order in which you provide `-l`'s on the command line shouldn't matter -- it should work as long as you provide the right set of `-l`'s. I'm puzzled every time a tool (e.g. `ld`) behaves differently based on the order of command line arguments.
>> 
>> Maybe there's a good reason for this, though. Maybe the cfe-dev folks can explain?
> 
> Getting the right order requires evaluating the dependencies.  Clang has to rely on the underlying linker to do this, so the logic can't be in Clang itself.

Right, in that case what I'm puzzled about is that some linkers are dependent on the order.

> On Darwin, ld64 does a pre-scan to build a hash of symbols so that it can handle out-of-order libraries.  

Ah, nice, that makes sense.

Thanks for the explanation,
Louis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190402/45895adf/attachment-0001.html>