I'm writing some library code, which can optionally make use of a certain C++11 feature (thread_local objects). However, I've found a bug that occurs only with the POSIX threading model (the Win32 one works fine) in MinGW-w64's builds of g++.
So, how can I detect, using the preprocessor, whether the current compiler is a g++ with the POSIX threading model?
g++ -v yields ... Thread model: win32 or ... Thread model: posix depending on the difference, but I need a way to conditionally compile code (to work around the bug) that doesn't involve invoking an extra instance of g++.
Check whether the macro __WINPTHREADS_VERSION is defined. If so, you are using posix threads on MinGW.
For example:
#if defined(_WIN32) && !defined(__WINPTHREADS_VERSION)
Logic for MinGW win32 threads;
#else
Logic for MinGW posix threads or Linux/UNIX;
#endif
Examples/References:
http://savannah.gnu.org/support/?108150#comment0
https://projects.kde.org/projects/kdesupport/emerge/repository/revisions/master/entry/portage/win32libs/libssh/0002-add-a-way-to-test-ssh-connections-on-windows.patch#L114
Related
If you build C++14 code with G++ and libstdc++, there's a library named libstdc++fs, which is separate from the rest of libstdc++, and contains the code for std::experimental::filesystem. If you don't link against it, you'll get undefined references.
The "trick" I'm using for overcoming this right now is:
if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
set(CXX_FILESYSTEM_LIBRARIES "stdc++fs")
endif()
and later:
target_link_libraries(my_target PUBLIC ${CXX_FILESYSTEM_LIBRARIES})
but - I don't like having to place this code in every project I work on. Is there a simpler or more standard idiom I could use? Some way this will all happen implicitly perhaps, with some CMake behind-the-scences magic?
tl;dr: Nothing right now, wait for a newer CMake version
As #Pedro graciously points out, this is a known problem, and there is an open issue about it at KitWare's GitLab site for CMake:
Portable linking for C++17 std::filesystem
If using CMAKE_CXX_STANDARD=17 and std::filesystem, GCC requires linking of an extra library: stdc++fs. ... If C++17 is enabled, would it be worth automatically linking to stdc++fs for GCC versions which require this? Likewise for any quirks in other compilers or libraries.
The KitWare issue is about C++17, for which apparently you still need the separate extra library (i.e. it's not just because of the "experimentality" in C++14). Hopefully we'll see some traction on this matter - but
Note: If you're experiencing this problem with C++17's std::filesystem, you're in luck - that code is built into libstdc++ beginning with GCC 9, so if you're using g++ 9 or later, and std::filesystem, you should no longer experience this problem.
Sorry in advance for a kind-of-dumb question - I'm pretty new to all this.
So I downloaded asio from here, and tried to #include asio.hpp, but got the following error;
fatal error: boost/config.hpp: No such file or directory
I thought this was rather odd, as it was suppose to be independent of Boost. I poked around a bit, and saw that I needed to define ASIO_STANDALONE, which I promptly did, only to be met with more errors where it tried to #include something else from Boost.
Is there just a big list of all the things I have to #define to tell it to be standalone or something? That would be very helpful.
This is an old question, however i had the same problem currenlty with Visual Studio 2013 and Asio 1.10.6. In Visual there is no switch nor compiler flag for c++11 features. Even with #define ASIO_STANDALONEAsio requires Boost.
Solution is to manually specify that our compiler is c++11 compliant. Just add:
#define ASIO_STANDALONE
#define ASIO_HAS_STD_ADDRESSOF
#define ASIO_HAS_STD_ARRAY
#define ASIO_HAS_CSTDINT
#define ASIO_HAS_STD_SHARED_PTR
#define ASIO_HAS_STD_TYPE_TRAITS
#include <path_to_asio/asio.hpp>
As noted on the Asio website:
When using a C++11 compiler, most of Asio may now be used without a dependency on Boost header files or libraries. To use Asio in this way, define ASIO_STANDALONE on your compiler command line or as part of the project options.
Thus even when ASIO_STANDALONE is defined, Asio will use Boost when:
Using a non-C++11 compiler.
When using certain features, such as stackful coroutines that are based on the Boost.Coroutine library.
With asio-1.10.2, the following program:
#include <asio.hpp>
int main()
{
asio::io_service io_service;
}
compiles with gcc 4.8.1, using -DASIO_STANDALONE -std=c++11 compiler flags. Without specifying the compiler to use c++11, compilation fails when attempting to include Boost header files.
I'm currently working on using cmake to build some projects, with the main platforms being Visual C++, MinGW GCC and Linux GCC. When building with GCC, I need to specify the -Wno-invalid-offsetof compiler option.
My current fix is as follows...
if ( "${CMAKE_GENERATOR}" MATCHES "^Visual Studio"
OR "${CMAKE_GENERATOR}" MATCHES "^NMake"
)
set (CPPLIB_COMPILER_OPTS "")
else ()
set (CPPLIB_COMPILER_OPTS "-Wno-invalid-offsetof")
endif ()
...
set_target_properties(sh_core PROPERTIES COMPILE_FLAGS "${CPPLIB_COMPILER_OPTS}")
# repeated for all targets
This works, but assuming that all generators other than the visual studio ones will build with gcc is obviously unsafe. For a start, there are IIRC generators for Borland compilers. More importantly, using make doesn't always mean using gcc.
Other compilers I'm likely to use are llvm-gcc and clang. Fortunately, I think even clang supports gcc-compatible options. But this logic is only good for as long as the relevant code is never released.
Cmake appears to check for available compilers and generate a makefile specifically for that compiler (raising the question - why not at least have the option of building the project directly, without the need for a middle-man like make?).
That being the case, I was hoping to be able to test directly for gcc in my CMakeLists.txt files. So far, though, I can't find an appropriate variable to test or any other obvious solution.
Is this possible?
To create a portable build system, it is best to not test for platforms, but to test for features.
Instead of testing "if Windows then do this", test for "if the -Wno-invalid-offsetof flag works then use it". You can do that with the CheckCCompilerFlag module, for example:
include(CheckCCompilerFlag)
check_c_compiler_flag(-Wno-invalid-offsetof HAS_NO_INVALID_OFFSETOF)
if (HAS_NO_INVALID_OFFSETOF)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-invalid-offsetof")
endif()
For C++ there is a similar CheckCXXCompilerFlag with a check_cxx_compiler_flag(flag var) command.
I can achieve this by gcc :
gcc -mwindows -o simple simple.c
But only find this in cmake:
add_executable(simple WIN32 simple.c)
But it's not exactly the same as -mwindows,
this will require the entry point to be WinMain,
while gcc -mwindows doesn't require this(can be main).
How should I do it properly?
If you use:
add_executable(simple WIN32 simple.c)
then you must provide a WinMain function. That's what the WIN32 flag to add_executable means: it means you're going to make it a Windows program, and provide a WinMain function.
I would recommend doing it this way if you're really writing a Windows application. It's what makes the most sense and fits most naturally with the underlying OS.
However, if you still want to pass gcc the "-mwindows" flag, but use a "main" anyway, then simply add "-mwindows" to the CMAKE_CXX_FLAGS and/or CMAKE_C_FLAGS value. You can do this in the cmake-gui program by adjusting those variables interactively to include "-mwindows" or you can do it with command line CMake, like this:
cmake -DCMAKE_C_FLAGS="-mwindows"
As DLRdave has said saying that the executable will be a win32 one means it will have WinMain as the entry point and be a windows application.
If the application is to be cross platform still then the usual means to suppress the console window but still allow use of main is to write a stub WinMain as found in the SDL or SFML libraries which simply calls the main function with the global variables __argc and __argv as arguments and returns its result.
This prevents the application from having a console window but reduces the disruption to the code of having to use WinMain as the entry point.
You can add target link option (for new versions of Cmake)
target_link_options(simple PRIVATE -mwindows)
https://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/i386-and-x86_002d64-Windows-Options.html
In case you need it for both Windows and Linux
if (WIN32)
# /ENTRY:mainCRTStartup keeps the same "main" function instead of requiring "WinMain"
set(SUBSYSTEM_LINKER_OPTIONS "/SUBSYSTEM:WINDOWS /ENTRY:mainCRTStartup")
else()
set(SUBSYSTEM_LINKER_OPTIONS "-mwindows")
endif()
target_link_options(TargetName PRIVATE ${SUBSYSTEM_LINKER_OPTIONS})
Related Question
I am going to build a Mac application written in Obj-C with Xcode. For argument's sake let's say it will have 10 optional features. I need a way to enable or disable those features to create custom builds of the application. These builds would be automated (most likely through the Mac OS X Terminal) so I would need a way to state which of these features are enabled/disabled at build time (a configuration file or CLI arguments would be ideal.)
So what is the best way to accomplish this? I'm trying to plan this out before I start coding so that there is proper separation in my code base to allow for these features to come and go. Ideally the custom build would only contain compiled code for the features it should have. In other words I don't want to always compile all the features and condition them out at runtime.
You can use Xcode configurations for this purpose; for each configuration you could include a different prefix header, for example. Then you can trigger builds form the command line via xcodebuild.
If you'd prefer the config file approach, you can use a .xcconfig file instead to define any of the Xcode build settings.
The Xcode Build System Guide describes both of these approaches.
use #ifdef and the -D flag under the compiler flags to control whether stuff is compiled in or out. You can set up lots of different configs this way if you want, and just have the xcode build configurations work nicely.
#include <stdio.h>
int
main (void)
{
#ifdef TEST
printf ("Test mode\n");
#endif
printf ("Running...\n");
return 0;
}
output 1:
$ gcc -Wall -DTEST dtest.c
$ ./a.out
Test mode
Running...
output 2:
$ gcc -Wall dtest.c
$ ./a.out
Running...
source: http://www.network-theory.co.uk/docs/gccintro/gccintro_34.html