Some feedback of building staq by the latest clang

[DevelopDaily]

I tried this to specify the clangas my compiler:

cmake .. -D CMAKE_CXX_COMPILER=clang++

After that, the makewill generate this famous error (a lot of people are discussing about why the very basic headers cannot be found by clang.)

fatal error: 'string' file not found

So, I changed the CMakeLists.txt of the staqfrom this:

`set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")`

to this:

`set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}  ")`

Everything works like a charm.

Now, I am not an expert of the tool chains. I just feel that clang should be smart enough to figure out where to get the basic things like standard headers on a mainstream Linux box such as the Ubuntu 19.04, which I am using.

Did you build it successfully by clangon your box with that -stdlib=libc++?

[meamy]

Hmm, interesting. We had had trouble with clang and glibc at some point, which switching to libc++ fixed. The error you report is fixed for me in Ubuntu 18.04 by installing libc++-dev, but I'm getting linking errors with clang for either standard library. Leaving this open until we can figure out what to do with clang

[vsoftco]

If you want to use clang with libc++ (and not libstdc++, which is the default C++ runtime on Linux, as the latter uses the gcc toolbox), you need to install both libc++-dev and libc++abi-dev via sudo apt-get install libc++-dev libc++abi-dev; works on our end (and also on Travis CI, now that we support clang as well). Note that on Linux (Ubuntu) ldd ./staq shows

ldd staq
        linux-vdso.so.1 (0x00007fff637e6000)
        libc++.so.1 => /lib/x86_64-linux-gnu/libc++.so.1 (0x00007f5c4ffd5000)
        libc++abi.so.1 => /lib/x86_64-linux-gnu/libc++abi.so.1 (0x00007f5c4ff9d000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5c4fe4e000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5c4fe33000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5c4fc41000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5c4fc1e000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f5c4fc11000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5c500ac000)

so both libc++ and libc++abi are used during linking.

[DevelopDaily]

Great. It now works for me too.

Thanks.