I'm compiling a very simple mBed OS 6 (bare metal) program that uses USBKeyboard for the FRDM-K22F, but I get this link error:
[Error] #0,0: L6218E: Undefined symbol USBKeyboard::key_code(unsigned char, unsigned char) (referred from BUILD/K22F/ARMC6/main.o).
[Error] #0,0: L6218E: Undefined symbol USBKeyboard::USBKeyboard(bool, unsigned short, unsigned short, unsigned short) (referred from BUILD/K22F/ARMC6/main.o).
Those functions are defined in USBKeyboard.cpp but I'm not sure how to make mBed Studio actually link it.
I posted this on the Mbed forum too and got a solution there:
if you have in your mbed_app.json file only this content
{
"requires": ["bare-metal"]
}
then you probably need to change it to
{
"requires": ["bare-metal", "events", "drivers-usb"]
}
This seems to be incorrectly documented.
Related
I have updated a project using CGAL 4.13 to CGAL 5.5. It uses the kernel:
typedef CGAL::Exact_predicates_exact_constructions_kernel K;
typedef K::FT dbl;
and some functions do not compile now anymore. For example the one below:
inline void decouple(const dbl& val,dbl& decoupled)
{
...
decoupled=CGAL::Gmpq(val.exact().mpq());
}
../geometricTools.h:476:50: error: 'const ET' {aka 'const class
boost::multiprecision::numberboost::multiprecision::backends::gmp_rational'}
has no member named 'mpq' 476 |
decoupled=CGAL::Gmpq(val.exact().mpq());
A second problem is a line wher e a string ("123/456") is converted to a number:
dbl AlgorithmHdf5::getDbl(int n, int d)
{
...
dbl ret(m_vDbl[ind]); // argument is a std::string
return ret;
}
AlgorithmHdf5.cpp:71:36: error: no matching function for call to
'CGAL::Lazy_exact_ntboost::multiprecision::number<boost::multiprecision::backends::gmp_rational
::Lazy_exact_nt(__gnu_cxx::__alloc_traitsstd::allocator<std::__cxx11::basic_string<char
, std::__cxx11::basic_string >::value_type&)' 71 | dbl ret(m_vDbl[ind]);
these lines used to work with CGAL 4.13 but do not with CGAL 5.5. I'd appreciate any help on this. Compiler: g++ (Ubuntu 11.2.0-19ubuntu1) 11.2.0
Epeck::FT is a wrapper around some rational type that depends on what is available. If you have GMPXX or LEDA, it may use that. In your case you have GMP and a recent enough Boost, so it uses Boost.Multiprecision. If you disable that with -DCGAL_DO_NOT_USE_BOOST_MP, you may get back to the Gmpq your old code was apparently expecting.
Boost.Multiprecision does not use reference counting, so decoupled=val.exact() should be sufficient for that type. To construct from std::string, it may help to first construct a FT::Exact_type (or CGAL::Exact_rational) and then convert that to FT. You may want to file an issue on github about this direct construction from a string, it looks like something that CGAL could support.
I have an old DLL which was built in VC6.0.
And I want to use this DLL at VC2019 project.
This DLL file is a MFC DLL, and contains a lot of classes and functions.
There is no problem for using classes and functions except these three functions (which contains CString parameter).
The exported DLL functions (class functions) are like below:
class CColorListCtrl : public CListCtrl
{
...
public:
int AddColumn(CString szHeaderStr, int nColWidth);
int AddItem(CString szItem);
bool SetItemTip(int nRow, int nCol, CString szTip);
...
}
And the link errors are like below:
error LNK2001: unresolved external symbol "public: int __thiscall CColorListCtrl::AddColumn(class ATL::CStringT<char,class StrTraitMFC<char,class ATL::ChTraitsCRT<char> > >,int,int)" (?AddColumn#CColorListCtrl##QAEHV?$CStringT#DV?$StrTraitMFC#DV?$ChTraitsCRT#D#ATL#####ATL##HH#Z)
error LNK2001: unresolved external symbol "public: int __thiscall CColorListCtrl::AddItem(class ATL::CStringT<char,class StrTraitMFC<char,class ATL::ChTraitsCRT<char> > >)" (?AddItem#CColorListCtrl##QAEHV?$CStringT#DV?$StrTraitMFC#DV?$ChTraitsCRT#D#ATL#####ATL###Z)
error LNK2001: unresolved external symbol "public: bool __thiscall CColorListCtrl::SetItemTip(int,int,class ATL::CStringT<char,class StrTraitMFC<char,class ATL::ChTraitsCRT<char> > >)" (?SetItemTip#CColorListCtrl##QAE_NHHV?$CStringT#DV?$StrTraitMFC#DV?$ChTraitsCRT#D#ATL#####ATL###Z)
The DLL exported functions are like below:
?AddColumn#CColorListCtrl##QAEHVCString##HH#Z
?AddItem#CColorListCtrl##QAEHVCString###Z
?SetItemTip#CColorListCtrl##QAE_NHHVCString###Z
For fix this problem, I changed Project Character Set (Project Setting -> General -> Character Set) as "Use Multi-Byte Character Set", but the problem is not solved.
I noticed that CString class was changed, so the CString classes at VC6 and VC2019 are different.
I have no idea to resolve this prblem. Also I can not change DLL, because I removed the project for this DLL.
Please help me.
Thank you.
CString in VC++ 6 and VC++ 2019 are not compatible with each other because there is a difference.
That is, if you use CString as a parameter for the export function in VC6 dll, you cannot directly call VC6 dll in VS2019.
I suggest one solution:
First, create a dll that acts as a repeater in vc6. The export function of this dll uses, for example, LPCTSTR as a parameter. Let this dll be A.dll and the original dll be B.dll.
Inside the A.dll, the export function of the B.dll is called and the result is converted to LPCTSTR and returned.
VS2019 calls the export function of A.dll. LPCTSTR is compatible between VS2019 and VS6, so you can solve your problem in this way.
There is some notes in this article (CStringT Class) where it states:
If your code contains the workaround for linker errors that is
described in Exporting String Classes Using CStringT, you
should remove that code. It is no longer needed.
I notice that the subsequent article that it refers to does state:
In the past, MFC developers have derived from CString to specialize
their own string classes. In Microsoft Visual C++.NET (MFC 8.0), the
CString class was superseded by a template class called CStringT.
It provides an explanation of what you can do to resolve linker issues.
I'd like to check for intel intrinsics such as _mm_popcnt_u32 or _mm_blendv_epi8 using cmake. However the function check_symbol_exists doesn't work properly depending on the compiler. (it works with Clang but not with GCC). Indeed it is documented
If the header files declare the symbol as a function or variable then the symbol must also be available for linking (so intrinsics may not be detected).
Is there a simple way to check for those ?
As the CMake documentation also states:
If the symbol is a type, enum value, or intrinsic it will not be
recognized (consider using CheckTypeSize or CheckCSourceCompiles).
So, try to compile a small example with the Intel intrinsic using CheckCSourceCompiles. E.g.:
include(CheckCSourceCompiles)
check_c_source_compiles("
int main() {
int tmp = _mm_popcnt_u32(0);
return 0;
}
"
HAVE_INTRINISC
)
I have a need to compile an existing message library generated using ZeroC's ICE with c++ clr.
I've been at this for a while and I'm having no luck.
I have a very simple .ice message file defined.
Upon generating the cpp and h files for this, I try to compile them into a .dll.
My slice2cpp command line args are
C:\Program Files (x86)\ZeroC\Ice-3.5.1\bin\slice2cpp.exe --depend --dll-export=ENABLE_DLL -I"C:\Program Files (x86)\ZeroC\Ice-3.5.1\slice" -I".\.." --underscore "E:\test\platform\platform\testMessage.ice"
This generates me a testMessage.cpp and testMessage.h files.
Upon attempting to compile these, I get the error:
Error 7 error LNK2028: unresolved token (0A00098D) "class IceUtil::Shared * __cdecl IceInternal::upCast(class IceInternal::ObjectFactoryManager *)" (?upCast#IceInternal##$$FYAPEAVShared#IceUtil##PEAVObjectFactoryManager#1##Z) referenced in function "public: __cdecl IceInternal::Handle<class IceInternal::ObjectFactoryManager>::Handle<class IceInternal::ObjectFactoryManager>(class IceInternal::Handle<class IceInternal::ObjectFactoryManager> const &)" (??0?$Handle#VObjectFactoryManager#IceInternal###IceInternal##$$FQEAA#AEBV01##Z) E:\test\platform\platform\testMessage.obj platform
As per usual with Ice, I have to link the Iced.lib and IceUtild.lib files.
I compile with no pre compiled headers and /clr option on (not pure clr or safe)
using VS2013. The body of the testMessage.ice file is very simple.
#ifndef _MESSAGE_ICE_
#define _MESSAGE_ICE_
module messaging {
class Message
{
string clientId;
string origin;
string destination;
string messageType;
string suffix;
};
sequence<Message> MessageSeq;
class NonQueuedMsg extends messaging::Message {};
};
#endif
Compiling without the CLR option on results in success.
I imagine this is all caused by my lack of familiarity with c++ clr.
Any help would be appreciated.
I had the same problem after the migration of my projects to vs 2013.
The project c++ with ice compile fine
but the project c++/cli with ice don't links.
I fixed linking problem in ObjectFactoryManagerF.h :
#ifdef __cplusplus_cli
IceUtil::Shared* upCast(ObjectFactoryManager* p) { return (IceUtil::Shared*) p; };
#else
IceUtil::Shared* upCast(ObjectFactoryManager* );
#endif
I stopped trying to make C++/CLI and ICE-generated code work together after I read on their forum here that they didn't support it.
What I've done.. I've made native static library on the client's side where I had C++/CLI. Static library fully encapsulated all communication stuff and was referenced from C++/CLI part. As a result I've got a Mixed (C++/CLR) Recommended Rules assembly. It works fine plus I've got easier portable application.
I'm trying to port some existing code that uses boost into native-client.
I compiled boost according to the instructions here: https://code.google.com/p/naclports/wiki/InstallingSDL (with boost instead of sdl), and tried injecting some boost code into one of the examples.
I was successfully able to use a boost::shared_ptr by editing examples/api/socket/socket.cc by including the header and adding a simple test method:
#include <boost/shared_ptr.hpp>
The test method:
void ExampleInstance::test_shared_ptr() {
boost::shared_ptr<std::string> test_ptr(new std::string("hi"));
PostMessage(test_ptr->c_str());
}
Invoking this method from the constructor results in a "hi" appearing on the console when loading the page you can reach by running "make serve".
Although I'm deeply impressed that this much works, my app uses boost::thread and boost::asio, and there I ran into trouble. In pepper_34, if I add:
#include <boost/threads.hpp>
I get these compilation errors, just by including that file:
~/nacl_sdk/pepper_34/examples/api/socket$ make
CHROME_PATH is undefined, and google-chrome not found in PATH, nor /usr/bin/google-chrome.
CXX newlib/Release/socket_x86_32.o
In file included from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/thread/thread_only.hpp:17,
from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/thread/thread.hpp:12,
from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/thread.hpp:13,
from socket.cc:25:
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/thread/pthread/thread_data.hpp: In member function 'size_t boost::thread_attributes::get_stack_size() const':
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/thread/pthread/thread_data.hpp:63: error: invalid conversion from 'const pthread_attr_t*' to 'pthread_attr_t*'
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/thread/pthread/thread_data.hpp:63: error: initializing argument 1 of 'int pthread_attr_getstacksize(pthread_attr_t*, size_t*)'
make: *** [newlib/Release/socket_x86_32.o] Error 1
Likewise, if I try to include any of the basic asio elements, for instance:
#include <boost/asio/io_service.hpp>
I get these compilation errors after adding that #include line:
~/nacl_sdk/pepper_34/examples/api/socket$ make
CHROME_PATH is undefined, and google-chrome not found in PATH, nor /usr/bin/google-chrome.
CXX newlib/Release/socket_x86_32.o
In file included from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/posix_fd_set_adapter.hpp:26,
from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/fd_set_adapter.hpp:22,
from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/select_reactor.hpp:27,
from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/reactor.hpp:29,
from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/task_io_service.ipp:24,
from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/task_io_service.hpp:203,
from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/impl/io_service.hpp:71,
from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/io_service.hpp:767,
from socket.cc:25:
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/socket_types.hpp:283: error: 'IF_NAMESIZE' was not declared in this scope
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/socket_types.hpp:304: error: 'sockaddr_un' does not name a type
In file included from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/socket_ops.hpp:326,
from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/select_reactor.ipp:30,
from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/select_reactor.hpp:212,
from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/reactor.hpp:29,
from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/task_io_service.ipp:24,
from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/task_io_service.hpp:203,
from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/impl/io_service.hpp:71,
from /home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/io_service.hpp:767,
from socket.cc:25:
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp: In function 'int boost::asio::detail::socket_ops::close(boost::asio::detail::socket_type, boost::asio::detail::socket_ops::state_type&, bool, boost::system::error_code&)':
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp:342: error: 'FIONBIO' was not declared in this scope
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp: In function 'bool boost::asio::detail::socket_ops::set_user_non_blocking(boost::asio::detail::socket_type, boost::asio::detail::socket_ops::state_type&, bool, boost::system::error_code&)':
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp:384: error: 'FIONBIO' was not declared in this scope
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp: In function 'bool boost::asio::detail::socket_ops::set_internal_non_blocking(boost::asio::detail::socket_type, boost::asio::detail::socket_ops::state_type&, bool, boost::system::error_code&)':
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp:437: error: 'FIONBIO' was not declared in this scope
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp: In function 'bool boost::asio::detail::socket_ops::sockatmark(boost::asio::detail::socket_type, boost::system::error_code&)':
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp:617: error: '::sockatmark' has not been declared
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp: In function 'size_t boost::asio::detail::socket_ops::available(boost::asio::detail::socket_type, boost::system::error_code&)':
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp:637: error: 'FIONREAD' was not declared in this scope
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp: In function 'void boost::asio::detail::socket_ops::init_buf(boost::asio::detail::socket_ops::buf&, void*, size_t)':
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp:687: error: invalid use of incomplete type 'struct iovec'
/home/jholland/nacl_sdk/pepper_34/include/newlib/sys/socket.h:304: error: forward declaration of 'struct iovec'
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp:688: error: invalid use of incomplete type 'struct iovec'
/home/jholland/nacl_sdk/pepper_34/include/newlib/sys/socket.h:304: error: forward declaration of 'struct iovec'
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp: In function 'void boost::asio::detail::socket_ops::init_buf(boost::asio::detail::socket_ops::buf&, const void*, size_t)':
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp:698: error: invalid use of incomplete type 'struct iovec'
/home/jholland/nacl_sdk/pepper_34/include/newlib/sys/socket.h:304: error: forward declaration of 'struct iovec'
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp:699: error: invalid use of incomplete type 'struct iovec'
/home/jholland/nacl_sdk/pepper_34/include/newlib/sys/socket.h:304: error: forward declaration of 'struct iovec'
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp: In function 'int boost::asio::detail::socket_ops::ioctl(boost::asio::detail::socket_type, boost::asio::detail::socket_ops::state_type&, int, boost::asio::detail::ioctl_arg_type*, boost::system::error_code&)':
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp:1689: error: 'FIONBIO' was not declared in this scope
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp: In function 'const char* boost::asio::detail::socket_ops::inet_ntop(int, const void*, char*, size_t, long unsigned int, boost::system::error_code&)':
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp:1974: error: 'IF_NAMESIZE' was not declared in this scope
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp:1979: error: 'if_name' was not declared in this scope
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp:1979: error: 'if_indextoname' was not declared in this scope
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp:1981: error: 'if_name' was not declared in this scope
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp: In function 'int boost::asio::detail::socket_ops::inet_pton(int, const char*, void*, long unsigned int*, boost::system::error_code&)':
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp:2209: error: 'if_nametoindex' was not declared in this scope
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp: In function 'int boost::asio::detail::socket_ops::gethostname(char*, int, boost::system::error_code&)':
/home/jholland/nacl_sdk/pepper_34/toolchain/linux_x86_newlib/i686-nacl/usr/include/boost/asio/detail/impl/socket_ops.ipp:2251: error: '::gethostname' has not been declared
make: *** [newlib/Release/socket_x86_32.o] Error 1
(Side Note: I don't think the CHROME_PATH warning at the top is causing these errors, since I get the same warning for the examples even without my edits, but the examples still work. I imagine it's because I'm building on a vm without chrome installed (or a window manager in which to run it), since I had to use linux to build boost according to the error message the boost build process gave when I tried building it on OSX. The error messages suggest this interferes with "make run_package", but otherwise the examples run properly under "make serve", and can be tested from a different machine, using chrome to access the pages. I'm writing this question while waiting for chromium-browser to install, in hopes I can confirm that theory.)
In case it matters, I'm running Ubuntu 12.04.
My questions:
Is there a previous pepper version in which somebody has successfully used boost::asio and/or boost::threads?
Has anyone encountered this problem and discovered a workaround?
Try building the glibc build of boost instead of newlib. You can do this by running:
TOOLCHAIN=glibc make boost
from the naclports directory.
It seems that the newlib build of boost doesn't support many boost libraries:
Component configuration:
- atomic : not building
- chrono : not building
- context : not building
- coroutine : not building
- date_time : building
- exception : not building
- filesystem : not building
- graph : not building
- graph_parallel : not building
- iostreams : not building
- locale : not building
- log : not building
- math : not building
- mpi : not building
- program_options : building
- python : not building
- random : not building
- regex : not building
- serialization : not building
- signals : not building
- system : not building
- test : not building
- thread : not building
- timer : not building
- wave : not building
The glibc build seems to support many more libraries:
Component configuration:
- atomic : building
- chrono : building
- context : not building
- coroutine : not building
- date_time : building
- exception : building
- filesystem : building
- graph : building
- graph_parallel : building
- iostreams : building
- locale : building
- log : building
- math : building
- mpi : not building
- program_options : building
- python : not building
- random : building
- regex : building
- serialization : building
- signals : not building
- system : building
- test : building
- thread : building
- timer : building
- wave : building