I wish to include Boost into my Xcode project as per the example in Serialization - Tutorial.
I am using Boost version "1_60".
The project I am using is built using CMake.
set(Boost_USE_MULTITHREADED ON)
find_package(Boost REQUIRED COMPONENTS serialization system filesystem iostreams unit_test_framework date_time )
include_directories(${Boost_INCLUDE_DIRS})
link_directories(${Boost_LIBRARY_DIR})
target_include_directories(serialExample PRIVATE ${Boost_LIBRARY_DIR})
When I use the following includes...
#include <boost/archive/text_oarchive.hpp>
#include <boost/archive/text_iarchive.hpp>
"Unused typedef 'STATIC_WARNING_LINE102'"
"Unused typedef 'STATIC_WARNING_LINE98'"
"Unused typedef 'STATIC_WARNING_LINE137'"
"Unused typedef 'STATIC_WARNING_LINE148'"
This highlights four issues in two files which appear to be inside of the includes files.
extended_type_info_typeid.hpp
check.hpp
The code inspector goes to the error....
In file included from /opt/local/include/boost/archive/detail/interface_oarchive.hpp:23:
In file included from /opt/local/include/boost/archive/detail/oserializer.hpp:38:
/opt/local/include/boost/serialization/extended_type_info_typeid.hpp:102:9: error: unused typedef 'STATIC_WARNING_LINE102' [-Werror,-Wunused-local-typedef]
BOOST_STATIC_WARNING(boost::is_polymorphic< T >::value);
^
Is there a way to stop this? How do I suppress this type of warning?
Is this a Clang issue? Isn't Boost cross-platform?
Boost is error-free, but it does not purport itself as warning free. You are getting errors, because you told the compiler to treat warnings as errors (-Werror).
If you don't want to see Boost warnings, you can make sure that the compiler path to the headers is given by -isystem rather than -I, which will hide warnings from those headers. In CMake, this can be done by including the SYSTEM option in include_directories. See https://cmake.org/cmake/help/v3.0/command/include_directories.html.
Related
I have been working with WebRtc Development for the Windows Platform. I want to develop webrtc based desktop application. I am doing it from scratch for learning and better understanding.
The normal process of WebRtc Library Compilation:
I have initially started with (Getting Started with WinRTC). I followed the normal compilation process. After that, I have tried multiple ways to generate project files for webrtc such as;
1.Default
gn gen --ide=vs2019 out/Default
2.Custom Flags
gn gen --ide=vs2019 out/Default --args="use_rtti=true is_clang=false rtc_build_tools=false rtc_include_tests=false rtc_build_examples=false"
3.Custom Flags
gn gen --ide=vs2019 out\Default --filters=//:webrtc "--args=is_debug=true use_lld=false is_clang=false rtc_include_tests=true rtc_build_tools=true rtc_win_video_capture_winrt=true target_cpu=\"x86\" target_os=\"win\" rtc_build_examples=true rtc_win_use_mf_h264=true enable_libaom=true rtc_enable_protobuf=true"
For the building process, I have Followed these methods:
With command line:
Run the following command to build the patched WebRTC from the command line.
ninja -C out\Default\x64
With Visual Studio 2019:
Open the generated Visual Studio solution with the following command:
devenv out\Default\x64\all.sln
I have tried almost all available combinations to generate build files and to build webrtc.lib static library. I have successfully managed to compile the static webrtc library webrtc.lib for both architectures;
x64 (Default Arch) (For Debug as well as release)
x86 (Custom Arch) (For Debug as well as release)
IMPORTANT:
I have successfully managed to run peerconnection_server.exe and
peerconnection_client.exe on windows. These examples are
successfully running on localhost.
Using VS2019:
After that, I created a new Console based project using VS2019 to consume generated binaries and followed these steps;
Add include folders
Configuration Properties → C/C++ → General → Additional Include Directories and add the following paths:
c:\webrtc\src
c:\webrtc\src\out\Default\$(Configuration)\$(PlatformTarget)\gen
c:\webrtc\src\third_party\abseil-cpp
c:\webrtc\src\third_party\libyuv\include
Preprocessor macros:
Click on Preprocessor → Preprocessor Definitions and add the following definitions:
USE_AURA=1;_HAS_EXCEPTIONS=0;__STD_C;_CRT_RAND_S;_CRT_SECURE_NO_DEPRECATE;_SCL_SECURE_NO_DEPRECATE;_ATL_NO_OPENGL;_WINDOWS;CERT_CHAIN_PARA_HAS_EXTRA_FIELDS;PSAPI_VERSION=2;WIN32;_SECURE_ATL;WINUWP;__WRL_NO_DEFAULT_LIB__;WINAPI_FAMILY=WINAPI_FAMILY_PC_APP;WIN10=_WIN32_WINNT_WIN10;WIN32_LEAN_AND_MEAN;NOMINMAX;_UNICODE;UNICODE;NTDDI_VERSION=NTDDI_WIN10_RS2;_WIN32_WINNT=0x0A00;WINVER=0x0A00;NDEBUG;NVALGRIND;DYNAMIC_ANNOTATIONS_ENABLED=0;WEBRTC_ENABLE_PROTOBUF=0;WEBRTC_INCLUDE_INTERNAL_AUDIO_DEVICE;RTC_ENABLE_VP9;HAVE_SCTP;WEBRTC_LIBRARY_IMPL;WEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0;WEBRTC_WIN;ABSL_ALLOCATOR_NOTHROW=1;HAVE_SCTP;WEBRTC_VIDEO_CAPTURE_WINRT
Linker additional library path:
Click on Linker → General → Additional Library Directories and add the following path:
c:\webrtc\src\out\Default\$(Configuration)\$(PlatformTarget)\obj
WebRTC library name:
Click on Input → Additional Dependencies and add the following filename:
webrtc.lib
Now, when I simply use this basic implementation such as;
#include <iostream>
#include "rtc_base/thread.h"
#include "rtc_base/logging.h"
#include "rtc_base/ssl_adapter.h"
#include "rtc_base/arraysize.h"
#include "rtc_base/net_helpers.h"
#include "rtc_base/string_utils.h"
#include "rtc_base/signal_thread.h"
int main(int argc, char** argv) {
rtc::InitializeSSL();
return 0;
}
The program is flooded with two types of errors:
1. LNK2038 mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug'
and another one is
2. LNK2038 mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2'
You can also see as given; Here I have used webrtc.lib with Configuration (Release) & Platform (x64).
Using Clion-2021.2.1 and CMAKE:
Here I have used webrtc.lib with Configuration (Release) & Platform (x86).
CMakeLists.txt is given as;
cmake_minimum_required(VERSION 3.20)
project(NewRtc)
set(CMAKE_CXX_STANDARD 14)
#set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /MT")
#set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /MTd")
include_directories(
"c:/webrtc/src"
"C:/webrtc/src/out/Default/x86/obj"
"c:/webrtc/src/third_party/abseil-cpp"
"c:/webrtc/src/third_party/libyuv/include"
)
# error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in main.obj
# Solution:
#1. _ITERATOR_DEBUG_LEVEL = 0 // disabled (for release builds)
#2. _ITERATOR_DEBUG_LEVEL = 1 // enabled (if _SECURE_SCL is defined)
#3. _ITERATOR_DEBUG_LEVEL = 2 // enabled (for debug builds)
add_definitions(
-D_ITERATOR_DEBUG_LEVEL=0
-DUSE_AURA=1
-D_HAS_EXCEPTIONS=0
-D__STD_C
-D_CRT_RAND_S
-D_CRT_SECURE_NO_DEPRECATE
-D_SCL_SECURE_NO_DEPRECATE
-D_ATL_NO_OPENGL
-D_WINDOWS
-DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS
-DPSAPI_VERSION=2
-DWIN32
-D_SECURE_ATL
-DWINUWP
-D__WRL_NO_DEFAULT_LIB__
-DWINAPI_FAMILY=WINAPI_FAMILY_PC_APP
-DWIN10=_WIN32_WINNT_WIN10
-DWIN32_LEAN_AND_MEAN
-DNOMINMAX
-D_UNICODE
-DUNICODE
-DNTDDI_VERSION=NTDDI_WIN10_RS2
-D_WIN32_WINNT=0x0A00
-DWINVER=0x0A00
-DNDEBUG
-DNVALGRIND
-DDYNAMIC_ANNOTATIONS_ENABLED=0
-DWEBRTC_ENABLE_PROTOBUF=0
-DWEBRTC_INCLUDE_INTERNAL_AUDIO_DEVICE
-DRTC_ENABLE_VP9
-DHAVE_SCTP
-DWEBRTC_LIBRARY_IMPL
-DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0
-DWEBRTC_WIN
-DABSL_ALLOCATOR_NOTHROW=1
-DHAVE_SCTP
-DWEBRTC_VIDEO_CAPTURE_WINRT)
#set(CMAKE_CXX_FLAGS_RELEASE "/MT")
#set(CMAKE_CXX_FLAGS_DEBUG "/MTd")
set(-Dwebrtc.lib)
add_executable(NewRtc main.cpp)
set_property(TARGET NewRtc PROPERTY
MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")
target_link_libraries(NewRtc
PRIVATE "C:/webrtc/src/out/Default/x86/obj/webrtc.lib"
)
But when I simply build the project, this error comes up for every implementation of WebRtc. Here you can see:
Please assist me that how can I simply use webrtc library in any project on windows suing VS2019 or Clion. I am trying to solve these problems, I have tried multiple solutions over stack overflow and other communities using cmake or adding flags inside project properties such as;
Linker Tool Errors
/MD, /MT, /LD (Use Run-Time Library)
LNK2038 mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2'
Mismatch Detected for 'RuntimeLibrary'
I have tried my best to explain the complete solution and associated problem so that someone might help me accordingly.
Well Guys, After spending almost 12 hours of research, I have made my day. I have exactly figured out what was wrong with my development setup in (VS2019/Clion) of using static webrtc.lib in executable projects.
I must thank Mr.#drescherjm for his support on my question. It's
really appreciated it.
All things were in a positive direction from library compilation to its usage in VS2019/Clion projects. Actually, webrtc development in .netCore projects required some useful libraries for the normal use of webrtc.lib in your projects.
Here is the list of libraries that you must use during development such as;
For Windows:
Required Modules for building WebRtc projects for Windows as follows;
WS2_32 secur32.lib winmm.lib dmoguids.lib wmcodecdspuuid.lib msdmo.lib Strmiids.lib
For Linux:
Required Modules for building WebRtc projects for Linux as follows;
Secur32 Msdmo Winmm Dmoguids wmcodecdspuuid
These are the important libraries as webrtc peer-to-peer communication mostly comes up with the extensive implementation of socket programming in C/C++ for both Linux as well as Windows Operating Systems.
How to use these libraries in projects:
using CmakeLists.txt
using #pragma keyword
For CMakeLists.txt:
You can simply include these modules in target_link_libraries() in which you are also linking webrtc.lib such as;
add_executable(NewRtc main.cpp)
set_property(TARGET NewRtc PROPERTY
MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")
target_link_libraries(NewRtc
PRIVATE "{$LIB_PATH}/webrtc.lib"
# Required Modules for building projects
WS2_32 secur32.lib winmm.lib dmoguids.lib wmcodecdspuuid.lib msdmo.lib Strmiids.lib
)
For #Pragma Keyword:
You can directly include all the required libraries using the #pragma keyword inside your executable files (in my case main.cpp) such as;
# pragma comment(lib, "webrtc.lib")
# pragma comment(lib,"WS2_32")
# pragma comment(lib, "secur32.lib")
# pragma comment(lib, "winmm.lib")
# pragma comment(lib, "dmoguids.lib")
# pragma comment(lib, "wmcodecdspuuid.lib")
# pragma comment(lib, "msdmo.lib")
# pragma comment(lib, "Strmiids.lib")
Both procedures will 100% serve the same purpose. I hope it would help someone.
I've a CMake project that's opened with Visual Studio 2019. I need c++17 features for my code, so I've set the corresponding flag in the CMakeLists.txt
cmake_minimum_required (VERSION 3.10.0)
project (datalog)
message (STATUS "Building project ${PROJECT_NAME}")
find_package(stxxl CONFIG REQUIRED)
include_directories (${CMAKE_SOURCE_DIR}/src)
set (PROJECT_SRC
main.cpp
)
add_executable (${PROJECT_NAME} ${PROJECT_SRC})
target_compile_features(${PROJECT_NAME} PRIVATE cxx_std_17)
target_link_libraries(${PROJECT_NAME} stxxl)
When I build I obtain a lot of errors, because the library that I'm linking, stxxl, installed with vcpkg, has the following piece of code:
STXXL_BEGIN_NAMESPACE
template <class Type>
struct compat_unique_ptr {
#if __cplusplus >= 201103L && ((__GNUC__ * 10000 + __GNUC_MINOR__ * 100) >= 40400)
typedef std::unique_ptr<Type> result;
#else
// auto_ptr is inherently broken and is deprecated by unique_ptr in c++0x
typedef std::auto_ptr<Type> result;
#endif
};
STXXL_END_NAMESPACE
The problem is that __cplusplus has value 199711L instead of the correct value 201703L, so code tries to use auto_ptr that's removed in C++17 standard.
I've also tried to set the flag manually in Visual Studio, adding this section in the CmakeLists.txt
if(MSVC)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /std:c++17 /Zc:__cplusplus")
endif()
But nothing changes. I'm also using some C++17 features, so going back at the moment is not an option.
I can manually update the stxxl header file to get rid of the macro, but it's a workaround, and every developer should create the same fix. Instead, I'd like to know why I'm getting the error and how to set the macro to the correct value with Visual Studio and CMake. Do you have any suggestion?
As far as i can tell from this, you need to add /Zc:__cplusplus manually (at least for now).
Your CMakeList snippet worked for me, are you sure, that __cplusplus is actually set incorrectly and it's not just the __GNUC__ Macro, that's missing?
That said, I'd recommend to test if the version of VisualStudio is actually new enough:
# /Zc:__cplusplus is required to make __cplusplus accurate
# /Zc:__cplusplus is available starting with Visual Studio 2017 version 15.7
# (according to https://learn.microsoft.com/en-us/cpp/build/reference/zc-cplusplus)
# That version is equivalent to _MSC_VER==1914
# (according to https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=vs-2019)
# CMake's ${MSVC_VERSION} is equivalent to _MSC_VER
# (according to https://cmake.org/cmake/help/latest/variable/MSVC_VERSION.html#variable:MSVC_VERSION)
if ((MSVC) AND (MSVC_VERSION GREATER_EQUAL 1914))
target_compile_options(stxxl INTERFACE "/Zc:__cplusplus")
endif()
Note: I used target_compile_options to add the necessary option to the interface of your library target. This way all targets, that depend on that library (via target_link_libraries) will be compiled with that flag, but targets, that don't need it (and might be incompatible with it) won't get it.
If you want to add the flag to one of your own targets, you can use target_compile_options(stxxl PUBLIC "/Zc:__cplusplus") (PUBLIC instead of INTERFACE). INTERFACE means the option is used when other targets depend on that target, PRIVATE means the option is used for the target itself and PUBLIC means both. (IMHO this artical explains it well.)
Apart from that, you shouldn't set the c++ standard version via compile flags, but instead using target_compile_features if the newer version is required and using
set_target_properties(your_target_name PROPERTIES CXX_STANDARD 17) if you just wish to use the newer version if it is available.
In your case the latter is probably sufficient as your codesnippet has a fallback if the c++ version is older.
If changing the code of stxxl (via pull request, etc.) is an option, the code could test _MSVC_LANG and _MSC_VER. This way it would work without requiring /Zc:__cplusplus.
I think what you need is target_compile_definitions, where you can define arbitrary macros in CMake and pass to compiler.
I am new to CMake projects and I want to use the file system library in my project. I am running Ubuntu 18.04 with GCC 8.2 and CMake 3.13. In order to achieve this I tried two options:
Option 1
cmake_minimum_required(VERSION 3.13)
project(TheFsProject)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_FLAGS "-std=c++17 -lstdc++fs")
This does not help as the compiler still cannot find the file system
library during compile time.
Option 2 (copied from:
https://www.scivision.co/cmake-cpp-17-filesystem/)
make_minimum_required(VERSION 3.13)
project(TheFsProject)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_REQUIRED_FLAGS -std=c++17)
include(CheckCXXSymbolExists)
CHECK_CXX_SYMBOL_EXISTS(std::filesystem::path::preferred_separator cxx17fs)
if(cxx17fs)
add_executable(TheFsProject main.cpp)
set_property(TARGET TheFsProject PROPERTY CXX_STANDARD 17)
endif()
This does not help either as I get a CMake error which I don't
understand.
(CHECK_CXX_SYMBOL_EXISTS):
CHECK_CXX_SYMBOL_EXISTS Macro invoked with incorrect arguments for macro named: CHECK_CXX_SYMBOL_EXISTS
I feel out of my depth on this topic which is why I came here. I don't mind putting extra work into finding out more but I don't know anymore where to look. Any help would be appreciated!
EDIT 1
Thanks for the replies so far! I made Option 3 based on your feedback:
cmake_minimum_required(VERSION 3.13)
project(TheFsProject)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
add_executable(TheFsProject main.cpp)
target_link_libraries(TheFsProject stdc++fs)
Sadly it doesn't fix my problem. It still issues an error during compilation that it can't find the compilation header.
EDIT 2
Thanks for all the replies so far. All of these help. I tried Ashkan his answer last (because it seemed intimidating). This one returns
Compiler is missing file system capabilities.
so I'm guessing something is wrong on that end. This is useful in the sense that I now know it's probably not due to my CMake file. I now have to find out why the compiler does support the file system header though...
EDIT 3
Strictly speaking this question is answered because my question is about the CMake file. I am going to mark Ashkan his answer as the solution simply because it produced the next step in my troubleshooting search. If I could I would also mark lubgr his answer because I think that's a really good answer as well. Thanks everyone!
Gcc 8.2. comes with <filesystem>, so there is no need to investigate with regard to the availability. Next, option 1 is sufficient, but needs a fix:
set(CMAKE_CXX_STANDARD 17) # no need to manually adjust the CXXFLAGS
add_executable(yourExecutable yourSourceFile.cpp)
target_link_libraries(yourExecutable stdc++fs)
This should result in compiling the sources with -std=c++17 or -std=gnu++17 and adding -lstdc++fs when linking.
Edit: Note that as #Ashkan has pointed out in the comments, setting CMAKE_CXX_STANDARD_REQUIRED to true results in an immediate error at configure time if C++17 isn't supported by the compiler, instead of a compilation error (due to the missing <filesystem> header) or at link time (due to the missing shared library). This might be desirable.
Besides from #lubgr's answer. I think a more complete way is to also do try_compile to see that you can actually use the filesystem header. This in my opinion is better because some compilers are not supporting std::filesystem yet. Also in gcc 7.x you have the filesystem under experimental namespace. This way you can have a separate try_compile in the else clause and detect that.
Here is the related cmake for it
# set everything up for c++ 17 features
set(CMAKE_CXX_STANDARD 17)
# Don't add this line if you will try_compile with boost.
set(CMAKE_CXX_STANDARD_REQUIRED ON)
# test that filesystem header actually is there and works
try_compile(HAS_FS "${CMAKE_BINARY_DIR}/temp"
"${CMAKE_SOURCE_DIR}/tests/has_filesystem.cc"
CMAKE_FLAGS -DCMAKE_CXX_STANDARD=17 -DCMAKE_CXX_STANDARD_REQUIRED=ON
LINK_LIBRARIES stdc++fs)
if(HAS_FS)
message(STATUS "Compiler has filesystem support")
else()
# .... You could also try searching for boost::filesystem here.
message(FATAL_ERROR "Compiler is missing filesystem capabilities")
endif(HAS_FS)
The file tests/has_filesystem.cc is very simple
#include <filesystem>
namespace fs = std::filesystem;
int main()
{
fs::path aPath {"../"};
return 0;
}
You could in your else clause try_compile for boost::filesystem and pass a directive that can be used in your source file where you decide if you want to use c++17 filesystem or boost.
CHECK_CXX_SYMBOL_EXISTS takes three arguments, not two:
include(CheckCXXSymbolExists)
check_cxx_symbol_exists(std::filesystem::path::preferred_separator filesystem cxx17fs)
You forgot to tell CMake where to look for the symbols (the header that declares them).
I have found a case when try_compile was not enough: when using the Intel C++ compiler (icpc (ICC) 19.1.1.216 20200306) in C++17 mode running on MacOS "Mojave" 10.14.6. The test program recommended by #Ashkan compiled without errors, and it even ran. However, my code uses fs::path::filename() at one point and that resulted in a runtime linker error (dyld: lazy symbol binding failed: Symbol not found:). In other words: the header is there, the implementation apparently isn't (?). I didn't investigate this any further.
The solution is to use try_run instead of try_compile and (in my case) fall back to boost::filesystem if std::filesystem is not yet supported.
Here is the relevant CMake code section:
try_run(RUNS_WITH_STDFS COMPILES_WITH_STDFS
"${CMAKE_BINARY_DIR}/try"
"${CMAKE_SOURCE_DIR}/cmake/has_stdfs.cc"
CMAKE_FLAGS CMAKE_CXX_STANDARD=17 CMAKE_CXX_STANDARD_REQUIRED=ON
)
if (RUNS_WITH_STDFS STREQUAL "FAILED_TO_RUN")
message(STATUS "Using boost::filesystem instead of std::filesystem")
set(_boost_components ${_boost_components} filesystem system)
add_definitions(-DUSE_BOOST_FILESYSTEM)
else()
message(STATUS "std::filesystem supported")
endif()
Note that the variable RUNS_WITH_STDFS is not set to NO in case of failure but to "FAILED_TO_RUN" which is not interpreted as a FALSE Boolean (see CMake if() docs:
if() True if the constant is 1, ON, YES, TRUE, Y, or a
non-zero number. False if the constant is 0, OFF, NO, FALSE, N,
IGNORE, NOTFOUND, the empty string, or ends in the suffix -NOTFOUND.
so I had to string-compare its value.
The little test program also changed a bit compared to #Ashkan's solution:
// == PROGRAM has_stdfs.cc ==
// Check if std::filesystem is available
// Source: https://stackoverflow.com/a/54290906
// with modifications
#include <filesystem>
namespace fs = std::filesystem;
int main(int argc, char* argv[]) {
fs::path somepath{ "dir1/dir2/filename.txt" };
auto fname = somepath.filename();
return 0;
}
I am now trying to build a c++ library in linux with cmake. If I do not enable -std=c++0x option, I always get compilation errors error: 'div_t' was not declared in this scope for the following codes:
int xPos;
div_t divResult;
divResult = div(xPos,8);
Then if I enable -std-c++0x options with cmake: set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x", then everything is fine. However, in my library I did not use any c++0x features, so I am reluctant to set std=c++0x option. So I search the head file that defines div_t and find it is defined in stdlib.h within the following MACRO:
__BEGIN_NAMESPACE_STD
typedef struct
{
int quot;
int rem;
} div_t;
....
....
__END_NAMESPACE_STD
It seems to me that if I can enable these macros I can build the library without enabling c++0x feature. So my question is what I can do in this situation.
By the way, I can build the library very well without enabling c++0x feature if only g++4.4 is installed in the linux machine. When I also install g++4.6 and make g++4.6 the default g++, then the compilation error began to occur. Even I changed the default g++ to g++4.4, the compilation error still exists if I do not enable c++0x feature.
The macros expand to namespace std { and } respectively if the code is pulled in through a C++ standard library header. This leads me to believe that you're not #including stdlib.h directly (which is good!).
Earlier versions of libstdc++ pulled symbols from C legacy headers into the global namespace even if the C++ versions of these headers (e.g. <cstdlib> instead of <stdlib.h>) were used; newer ones place them only in namespace std.
The cleanest way to fix this is to
#include <cstdlib>
in all translation units where the problem occurs and to use std::div instead of div. If you're lazy, you can also
#include <stdlib.h>
in all translation units that use div, but mixing C and C++ is always icky. Not terribad in this particular case, though.
This program doesn't actually do anything, but it builds with 182 warnings, all of which seem to be issues in boost code. Should I do anything about this, maybe use a different library, or should I just use boost::asio and ignore all the warnings?
// main.cpp
#include <boost/asio.hpp>
#include <boost/asio/ssl.hpp>
int main() {
exit(0) ;
}
This is common for many boost (and third-party) libraries. I would have them treated as system headers. For example, with gcc pass the -isystem command line option or move the boost headers to directory which is considered a system header directory.
Boost also has a warnings guidelines page which might be helpful. See Suppressing Warnings in GCC.