i wanted to try out Chrono from the Boost sandbox. It seems to support a lot of stuff and should be stable.
I have Boost in version 1.44 installed on my system (incl. boost_system lib which is needed) and took the sandbox version (the download-version is older and misses for example the ratio.hpp file).
But it isn't compiling. Trying to compile the simple example from the documentation, with linking boost_system (in scons with LIBS=['boost_system']), the following error is occurring every time:
obj/main.o: In function `main':
/home/***/src/main.cpp:34: undefined reference to `boost::chrono::system_clock::now()'
scons: building terminated because of errors.
That seems to be a linker error. What did i do wrong? I have boost_system in version 1.44 linked (trough scons) and already tried the same with the older version 1.40.
Any tips? How did you setup your use of chrono?
Thanks.
sascha
Edit: This thread, which is talking about compatibility issues, let me think that the sandbox version of Chrono should be able to work with boost 1.44.
As described in the Installing Chrono documentation, you either need to build and link the Chrono library, or define BOOST_CHRONO_INLINED.
I had problems building Chrono from the trunk checkout, but it's probably related to the type_traits incompatibility mentioned in the Chrono docs.
I was able to build the example program with the following SConstruct (after fixing namespace errors):
env = Environment(
CPPDEFINES = ['BOOST_CHRONO_INLINED'],
CPPPATH = ['/.../boost_1_44_0', ],
LIBPATH = ['/.../boost_1_44_0/stage/lib', ],
LIBS = ['boost_system'],
)
env.Program('chrono-test', 'main.cpp')
Related
I have downloaded boost 1.58.0 (precompiled, x86, VC 12.0) from http://boost.teeks99.com/ and installed to C:\local\boost_1_58_0 (I also tried compiled the source code using msvc-12.0 by myself and get the same result.
The problem: I see too many libboost*.lib of the same library, for example
ls -l libboost_math_* returns:
libboost_math_c99f-vc120-mt-1_58.lib
libboost_math_c99f-vc120-mt-gd-1_58.lib
libboost_math_c99f-vc120-mt-s-1_58.lib
libboost_math_c99f-vc120-mt-sgd-1_58.lib
libboost_math_c99f-vc120-s-1_58.lib
libboost_math_c99f-vc120-sgd-1_58.lib
libboost_math_c99l-vc120-mt-1_58.lib
libboost_math_c99l-vc120-mt-gd-1_58.lib
libboost_math_c99l-vc120-mt-s-1_58.lib
libboost_math_c99l-vc120-mt-sgd-1_58.lib
libboost_math_c99l-vc120-s-1_58.lib
libboost_math_c99l-vc120-sgd-1_58.lib
libboost_math_c99-vc120-mt-1_58.lib
libboost_math_c99-vc120-mt-gd-1_58.lib
libboost_math_c99-vc120-mt-s-1_58.lib
libboost_math_c99-vc120-mt-sgd-1_58.lib
libboost_math_c99-vc120-s-1_58.lib
libboost_math_c99-vc120-sgd-1_58.lib
libboost_math_tr1f-vc120-mt-1_58.lib
libboost_math_tr1f-vc120-mt-gd-1_58.lib
libboost_math_tr1f-vc120-mt-s-1_58.lib
libboost_math_tr1f-vc120-mt-sgd-1_58.lib
libboost_math_tr1f-vc120-s-1_58.lib
libboost_math_tr1f-vc120-sgd-1_58.lib
libboost_math_tr1l-vc120-mt-1_58.lib
libboost_math_tr1l-vc120-mt-gd-1_58.lib
libboost_math_tr1l-vc120-mt-s-1_58.lib
libboost_math_tr1l-vc120-mt-sgd-1_58.lib
libboost_math_tr1l-vc120-s-1_58.lib
libboost_math_tr1l-vc120-sgd-1_58.lib
libboost_math_tr1-vc120-mt-1_58.lib
libboost_math_tr1-vc120-mt-gd-1_58.lib
libboost_math_tr1-vc120-mt-s-1_58.lib
libboost_math_tr1-vc120-mt-sgd-1_58.lib
libboost_math_tr1-vc120-s-1_58.lib
libboost_math_tr1-vc120-sgd-1_58.lib
My questions:
Why are there so many lib files for one library? (36 files for
libboost_math, 4 libboost_atomic, 6 libboost_iostreams and so on)
Why are there no single libboost_math.lib, libboost_atomic, ...
files?
If I want to use boost_math, which library should I choose?
Boost.Math contains many parts, and they don't share the same library file.
The libraries' filename described what it builds for.
For example,
vc120: it builds for microsoft visual C++ 12.0 (a.k.a. 2013)
mt: will link with multithread version of C runtime. (libcmt.lib)
mt-s: will link with multithread version of shared C runtime. (msvcrt.lib)
mt-gd: will link with multithread debug version of C runtime. (libcmtd.lib)
mt-sgd: will link with multithread debug version of shared C runtime. (msvcrtd.lib)
s: will link with singlethread version of shared C runtime. (seems now VC doesn't contains one? I'm not sure.)
sgd: will link with singlethread debug version of shared C runtime. (seems now VC doesn't contains one? I'm not sure.)
If you are using Boost with Microsoft Visual C++, you will benefit from the auto-link feature. Set the additional library directory and the linker (to be exact, the boost header directs the linker) will link the correct version for you.
At the beginning I must assure You that I've tried almost every solution from similar topics , still they didn't solve my issue.
I'm building binaries from Boost 1.57 using MinGW.
Boost libraries I'm using: thread and system build without any errors.
I was trying:
toolset=gcc --target-os=qnxnto and toolset=gcc --target-os=qnx, both didn't work.
I'm including correctly both libraries:
-lboost_system-mgw48-mt-d-1_57 -lboost_thread-mgw48-mt-d-1_57
after using:
#define BOOST_SYSTEM_NO_DEPRECATED
I got rid of boost::system::generic_category() error, still I can't get rid of:
boost::system::system_category()
I'm working in QNX Momentics.
I'm totally out of ideas, I'm really looking forward for any help I can get.
I want to create shared map objects that multiple processes can access. The most promising approach I've found is this demo code from Boost.Interprocess, which allocates map objects in a managed shared memory segment. This question will mostly be about the boost problems I'm having, but I'd also be grateful if anyone has non-boost alternative approaches.
I'm completely new to boost: it looks amazing, if huge, and I was encouraged by its claim that "often, there's nothing to build". But in this case that promise is broken in what seems to be a senseless way, and I'm failing to compile the demo because of dependency problems internal to boost.
I'm on Windows, with Visual C++ Express 2010 installed. After saving the demo code as shmap.cpp I do the following:
"%VS100COMNTOOLS%\..\..\VC\vcvarsall.bat"
cl /EHsc /I boost_1_57_0 shmap.cpp
It compiles OK, but then I get this:
LINK : fatal error LNK1104: cannot open file 'libboost_date_time-vc100-mt-s-1_57.lib'
This surprises me on a number of levels. (Q1): I didn't ask for libraries---where and how is boost leading the linker to expect them? (Q2): Why would it be asking for date_time in particular? At no point in the code is anything as functionally specific as a date or time computed, referenced or included. Is this a case of overzealous blanket dependency, and if so is there a way I can weed it out?
Regardless, the obvious first thing to try was to play the game: in the boost_1_57_0 directory I ran bootstrap.bat followed by b2. The Earth turned a good few degrees, boost was built successfully, and I retried with:
cl /EHsc /I boost_1_57_0 shmap.cpp /link /LIBPATH:boost_1_57_0\stage\lib
I still get the same linker error. This is because b2 seems to have built libs with -mt- and with -mt-gd- in their names, but not with the -mt-s- that the linker is looking for. Boost's "Getting Started" webpage tells me what these stand for but doesn't tell me (Q3): how can I change either the type of library that gets built, or the type that the linker expects?
"At no point in the code is anything as functionally specific as a date or time computed, referenced or included."
(Q2): Why would it be asking for date_time in particular?
Apparently the things you used depend on it.
E.g the mutex operations have timed_lock function
(Q1): I didn't add libraries to the project---where and how is boost leading the linker to expect them?
Boost does autolinking by default. This uses MSVC++ specific pragmas to indicate the right flavour of the right link libraries. This is an awesome feature.
You just have to make sure the import libraries are on the library path for your project.
There are ways to disable auto-linking in boost (I think it involves defining BOOST_ALL_NO_LIB)
There might be ways to
disable dependency on boost date_time (dropping features); see the autl-link description in the Getting Started guide
linking to date_Time statically (or make it header-only)
I'd refer to the documentation for this.
Here's what I've learned, in large part thanks to sehe:
Q1: It's magic---specifically, MSVC-specific magic---and it happens because it's necessary.
Q2: It becomes unnecessary---i.e. the demo can be compiled without needing to look for a binary date_time lib---if I add /DBOOST_ALL_NO_LIB to the compile flags. But it's unclear whether that will still be true once I start to use additional IPC functionality like time-dependent mutexing.
Q3: Strings from the "Boost.Build option" column of this table can be passed to b2, so the way to create *-mt-s-*.lib is to say b2 runtime-link=static. This finally lets me compile without the /DBOOST_ALL_NO_LIB flag, and discover that date_time is the only library the demo seems to need.
I also discovered that the dependencies can be tracked with the bcp tool, and (eventually) also how to build bcp in the first place, as follows:
build:
cd boost_1_57_0
bjam tools\bcp
cd ..
report:
boost_1_57_0\dist\bin\bcp.exe --boost=boost_1_57_0 --report --scan shmap.cpp report.html
The result is that the maps-in-shared-memory demo needs 1421 files from boost 1.57.0.
I have installed boost_1_54 on windows by checkout from svn and then
bootstrap
.\b2
QuantLib library dependent on boost compiles well all but one project: test-suite which uses BOOST_MESSAGE. this is undefined. I can see that there is no BOOST_MESSAGE in my version of boost.
Therefore is this QuantLib incompatibility or have I missed something?
On my linux boost version the same thing applies to BOOST_MESSAGE - it is undefined
I have seen this but I am not sure how to interpret this.
I'm afraid you gave us more credit than we deserved :)
We haven't compiled QuantLib against Boost svn yet. The latest I've tried is Boost 1.53 (the latest released version) in which BOOST_MESSAGE was still available.
Thanks for the heads-up, though. I'll patch the library so that it's ready for next version. As mentioned in the comments, it should be as simple as adding
#if BOOST_VERSION > 105300
#define BOOST_MESSAGE(msg) BOOST_TEST_MESSAGE(msg)
#endif
to test-suite/utilities.hpp.
on linux I had to add
libboost_unit_test_framework.so
to the Linker->Libraries and
#include <boost/test/unit_test.hpp>
#define BOOST_MESSAGE( M ) BOOST_TEST_MESSAGE( M )
is already present in test/test_tools.hpp.
on windows I have different #defines and this is not present, so I added it to the
unit_test_log.hpp
where BOOST_TEST_MESSAGE is defined (in boost files to avoid same issue again in the case of other applications using BOOST_MESSAGE).
BOOST_MESSAGE issue resolved but still can't disambiguate
const void* = boost::test_tools::check_is_close
and
const void* = boost::test_tools::check_is_small
because these are templates. so the solution is to remove it (test-suite compiles well) or use appropriate pointers to function templates
on Windows, after romoval or function
_use_check
in utilities.hpp
changed to not have pointers to TEMPLATE functions as default, so changed to:
void _use_check(
const void*,
const void*) const {}
there were still errors while building test-suite project. unresolved externals: fdmhestonfwdop, fdmblackscholesfwdop, fdmsquarerootfwdop. obviously this classes (headers+source) I had to add to Quantlib project, build library QuantLib-vc110-mt-gd.lib again and rebuild test-suite project then.
after pleasure with VS linker error "lnk1210 exceeded internal ilk size limit link with incremental no" (it really likes RAM, but on windows I have this resource quite limited), it is OK. compiled. : p
I am pretty new to Ubuntu, but I can't seem to get this to work. It works fine on my school computers and I don't know what I am not doing. I have checked usr/include and time.h is there just fine. Here is the code:
#include <iostream>
#include <time.h>
using namespace std;
int main()
{
timespec time1, time2;
int temp;
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &time1);
//do stuff here
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &time2);
return 0;
}
I am using CodeBlocks as my IDE to build and run as well. Any help would be great, thank you.
Add -lrt to the end of g++ command line. This links in the librt.so "Real Time" shared library.
example:
c++ -Wall filefork.cpp -lrt -O2
For gcc version 4.6.1, -lrt must be after filefork.cpp otherwise you get a link error.
Some older gcc version doesn't care about the position.
Since glibc version 2.17, the library linking -lrt is no longer required.
The clock_* are now part of the main C library. You can see the change history of glibc 2.17 where this change was done explains the reason for this change:
+* The `clock_*' suite of functions (declared in <time.h>) is now available
+ directly in the main C library. Previously it was necessary to link with
+ -lrt to use these functions. This change has the effect that a
+ single-threaded program that uses a function such as `clock_gettime' (and
+ is not linked with -lrt) will no longer implicitly load the pthreads
+ library at runtime and so will not suffer the overheads associated with
+ multi-thread support in other code such as the C++ runtime library.
If you decide to upgrade glibc, then you can check the compatibility tracker of glibc if you are concerned whether there would be any issues using the newer glibc.
To check the glibc version installed on the system, run the command:
ldd --version
(Of course, if you are using old glibc (<2.17) then you will still need -lrt.)
I encountered the same error. My linker command did have the rt library included -lrt which is correct and it was working for a while. After re-installing Kubuntu it stopped working.
A separate forum thread suggested the -lrt needed to come after the project object files.
Moving the -lrt to the end of the command fixed this problem for me although I don't know the details of why.