std::thread support not present in /hbb_exe/lib/libstdc++.a

[phusion]

std::thread support not present in /hbb_exe/lib/libstdc++.a

[nightlark]

Hi! Do you have a minimal example that gives the error (maybe a link to a GitHub project)? Also, which Docker image/tag are you using?

[nightlark]

Actually, a 3rd question, did you make sure to either use hbb-exec or source /hbb_exe/activate?

Some useful docs on those can be found on these two pages:
https://github.com/phusion/holy-build-box/blob/master/TUTORIAL-1-BASICS.md#holy-build-box-environment-activation
https://github.com/phusion/holy-build-box/blob/master/ENVIRONMENT-STRUCTURE.md

Edit: From your edit it looks like you did activate the environment?

[kerrmattabcorp]

So basically just a cut down use of std::call_once as per the example on cppreference:

#include <thread>
#include <mutex>
#include <iostream>

std::once_flag flag1;

void simple_do_once()
{
    std::call_once(flag1, [](){ std::cout << "Simple example: called once\n"; });
} 

int main()
{
    std::thread st1(simple_do_once);
    std::thread st2(simple_do_once);
    st1.join();
    st2.join();
}

using the latest build (2.0.1 with the gcc8 toolchain) compile with:

source /hbb_exe/activate
g++ /tmp/tt.cpp -o /tmp/test -lpthread # <--- this works dynamically linking stdlib
g++ -static-libstdc++ /tmp/tt.cpp -o /tmp/test -lpthread # <--- this works static link but picks up libstdc++.a from /opt/rh/devtoolset-8
g++ -L/hbb_exe/lib/ -static-libstdc++ /tmp/tt.cpp -o /tmp/test -lpthread # <---- this fails to link

[nightlark]

Is there a reason you're trying to link to the copy in /hbb_exe/lib instead of /opt/rh/devtoolset-8? It looks like the hbb activate functions are intended to make the libstdc++ provided by devtoolset-8 be the one used for linking.

I wouldn't be surprised if whatever copy of libstdc++ is in /hbb_exec/lib is something horribly outdated, maybe the default provided by CentOS 6.

Edit: https://github.com/phusion/holy-build-box/blob/master/image/activate_func.sh is the file with the activate functions, it looks like the arguments for "EXTRA_" flags (which /hbb_exec/lib appears to be one of the arguments passed in when it is called) get appended as a place to search after the libs provided by devtoolset-8.

[kerrmattabcorp]

I wasn't intentionally, I had assumed it was because of the LDFLAGS etc env vars that the activate sets up? I originally hit this when using CMake on a pretty large app and -L/hbb_exe/lib was added for me.

My initial "work-around" was to simply overwrite the /hbb_exe/lib version with the one from the toolset which works fine it seems

[kerrmattabcorp]

It might just be a dodgy CMake definition... (I have to go now -- I'll check back in tomorrow - thanks for swift responses!)

[nightlark]

Ah okay, I haven't run into this issue with the CMake project I have that uses std::threads, so it could be... though looking at where hbb builds libstdc++, it seems like it is intended to be a pretty recent copy of libstdc++.

Looking through the PRs, #4 is about C++11 threads. If you've got some time and can confirm that the PR fixes the threading issue, I'll merge it.

[kerrmattabcorp]

Hi, I definitely think that I'm encountering the issue identified in that PR. Unfortunately for me the PR as it stands didn't fix the issue for me -- (maybe the v8 toolchain has changed things?). Running configure for libgcc didn't result in gthr-default.h being created. What I did try was simply copying ${gcc_src_root}/libgcc/gthr-posix.h to ${gcc_src_root}/libgcc/gthr-default.h and then running configure && make for libstdc++v3 and that seems to work.

I've wrestled with gcc a bit this morning trying to "do it properly" but it's a bit daunting trying to understand to correct procedure.

[nightlark]

It looks like this thread might be relevant: http://gcc.1065356.n8.nabble.com/PATCH-libstdc-Fix-missing-gthr-default-h-issue-on-libstdc-configure-td875564.html

My impression is that the patch wasn't applied because no one would want to build libstdc++ without also building gcc/libgcc. I've only compiled gcc from source once before with the default options -- I'm not sure if making a symlink/copy is the right way to go, or if there are similar issues with other parts of the standard library that would make it better to just build gcc from source.

[FooBarWidget]

Linking to the libstdc++.a provided by Holy Build Box, rather than the one provided by devtoolset-8, is intentional. From LINKING-CXX.md:

Holy Build Box ships static libstdc++ libraries that are compiled with -fvisibility=hidden, so symbol clashes do not occur.

This is why we ship 3 versions of libstdc++.a:
/hbb_shlib/lib/libstdc++.a
/hbb_exe_gc_hardened/lib/libstdc++.a
/hbb_exe/lib/libstdc++.a

So yes, this is a bug that needs to be fixed.

[FooBarWidget]

Upon inspecting the libstdc++ source code, it seems that std::thread support is disabled because the configure script failed to detect gthreads (gthr.h). Gthreads appears to be something that's part of libgcc.

The plot thickens.

[FooBarWidget]

I think it's probably caused by the fact that we try to compile libstdc++ without the rest of gcc. Its configure script tries to find gthr.h in ../libgcc, but it isn't there. This appears to be a bug in the libstdc++ build system.

But gthr.h is in libstdc++'s include/bits subdirectory. So adding -Iinclude/bits to CXXFLAGS fixed it.