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
Related
TL,DR:
Is there a way for me (no root access) to make the linker (invoked by gcc) unaware of the contents of a directory contained in /etc/ld.so.conf after it has been cached via ldconfig?
In Detail:
I'm trying (and failing) to compile HTCondor on a custom linux distro without root access. For various reasons (see below) I believe that the problems I encounter are related to the fact that there are two versions of libssl and two versions of libcrypto installed on this machine. The newer version (1.0.0) of each of these is located at /usr/lib64 and an older version (0.9.8) is kept at /usr/local/lib64 for compatibility reasons. /etc/ld.so.conf contains both of these paths, so the linker knows about both.
During compilation I get an error
../condor_utils/libcondor_utils_8_7_9.so: undefined reference to `ERR_remove_thread_state'
since, for some reason, libcondor_utils_8_7_9.so is linked against libcrypto.so.0.9.8, while ERR_remove_thread_state was introduced in 1.0.0. It appears exactly once in the source code:
#if OPENSSL_VERSION_NUMBER < 0x10000000L
ERR_remove_state( 0 );
#elif OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER)
ERR_remove_thread_state( 0 );
#endif
so the preprocessor seems to make its decision based on version 1.0.0.
This question made me aware of this blog post, so I tried surrogating cpp with the following script:
#!/bin/bash
/usr/bin/gcc -Wl,-rpath-link="/usr/lib64",-rpath="/usr/lib64" "$#"
to no avail, unfortunately.
Just for the heck of it, I also tried commenting the prepocessor directives in the source code snippet above to force the selection of ERR_remove_state. This results in the linker warning me that libssl.so.1.0.0 may conflict with libssl.so.0.9.8 and, unsurprisingly, produces another "undefined reference" error.
EDIT:
The problem turned out not to be related to the linker at all. See my answer. However, out of curiosity, I'll leave the question open to see if anyone has a solution for it in its original formulation.
The comments by #user463035818 and #jww pointed me in the right direction to solve my specific problem, which turned out not be related to the linker directly.
Condor uses cmake as build system, so obviously it makes more sense to try to solve this at the cmake level (n00b here). Somewhere in the depths of all the things cmake does it finds both versions of the libraries and mixes them up for some reason. Invoking find_library with a specific version as per this answer in the main CMakeLists.txt solves that problem although it leaves a bad taste of dirty workaround in my mouth.
Making cmake ignore a certain directory when looking for libraries should not be hard, according to the docs. I haven't tried it, though.
Some time ago I started coding my application in Visual Studio 2015, had no issues setting all of the library dependencies.
Now, I decided to move to CLion. However my application has a dependency of cryptopp library, which I need to link in my CLion project.
Currently, I'm facing tons of undefined reference errors
undefined reference to `CryptoPP::Integer::Integer(char const*)'
undefined reference to `CryptoPP::Integer::Integer(char const*)'
undefined reference to `CryptoPP::Integer::Integer(char const*)'
undefined reference to `CryptoPP::DH_Domain<CryptoPP::DL_GroupParameters_GFP_DefaultSafePrime, CryptoPP::EnumToType<CryptoPP::CofactorMultiplicationOption, 0> >::AccessGroupParameters()'
undefined reference to `CryptoPP::DH_Domain<CryptoPP::DL_GroupParameters_GFP_DefaultSafePrime, CryptoPP::EnumToType<CryptoPP::CofactorMultiplicationOption, 0> >::GetGroupParameters() const'
undefined reference to `CryptoPP::DH_Domain<CryptoPP::DL_GroupParameters_GFP_DefaultSafePrime, CryptoPP::EnumToType<CryptoPP::CofactorMultiplicationOption, 0> >::GetGroupParameters() const'
[..]
I have indeed set include directories in my CMakeLists:
set(EXTERN_LIBS E:/dev/libs)
include_directories(${EXTERN_LIBS} ${EXTERN_LIBS}/include)
link_directories(${EXTERN_LIBS})
However, I still cannot get it to work.
I'm using MinGW for my project. Here is a preview of settings and versions:
How can I properly add cryptopp library into my project in CLion?
I think we may have mostly cleared the MinGW/C++11 issue at Commit e4cef84883b2. You should work from Master or perform a git pull, and then uncomment the define for CRYPTOPP_NO_CXX11 in config.h : 65 (or so):
// Define CRYPTOPP_NO_CXX11 to avoid C++11 related features shown at the
// end of this file. Some compilers and standard C++ headers advertise C++11
// but they are really just C++03 with some additional C++11 headers and
// non-conforming classes. You might also consider `-std=c++03` or
// `-std=gnu++03`, but they are required options when building the library
// and all programs. CRYPTOPP_NO_CXX11 is probably easier to manage but it may
// cause -Wterminate warnings under GCC. MSVC++ has a similar warning.
// Also see https://github.com/weidai11/cryptopp/issues/529
// #define CRYPTOPP_NO_CXX11 1
I think the problems is, you are hitting issues related to Windows and its lack of proper C++11 support, but you are getting them indirectly. They are indirect because MinGW and GCC is layered on top. MinGW and GCC cannot possibly provide C++11 because the underlying platform cannot.
I think your best bet at this point is to define CRYPTOPP_NO_CXX11. I don't believe we can do it for you like we do on Windows because the defines we need access to are hidden behind MinGW and GCC. And we also have some MSVC++ bugs to workaround.
Here's how we do it on Windows, but we don't have access to these defines in MinGW (from config.h : 950):
// Dynamic Initialization and Destruction with Concurrency ("Magic Statics")
// MS at VS2015 with Vista (19.00); GCC at 4.3; LLVM Clang at 2.9; Apple Clang at 4.0; Intel 11.1; SunCC 5.13.
// Microsoft's implementation only works for Vista and above, so its further
// limited. http://connect.microsoft.com/VisualStudio/feedback/details/1789709
#if (CRYPTOPP_MSC_VERSION >= 1900) && ((WINVER >= 0x0600) || (_WIN32_WINNT >= 0x0600)) || \
(CRYPTOPP_LLVM_CLANG_VERSION >= 20900) || (CRYPTOPP_APPLE_CLANG_VERSION >= 40000) || \
(__INTEL_COMPILER >= 1110) || (CRYPTOPP_GCC_VERSION >= 40300) || (__SUNPRO_CC >= 0x5130)
# define CRYPTOPP_CXX11_DYNAMIC_INIT 1
#endif // Dynamic Initialization compilers
If you define CRYPTOPP_NO_CXX11, then the following will not be defined and you will avoid the problems: CRYPTOPP_CXX11_DYNAMIC_INIT, CRYPTOPP_CXX11_SYNCHRONIZATION, and CRYPTOPP_CXX11_ATOMICS.
The second issue, the one related to Clion and Cmake, was settled as follows. We setup a separate GitHub with our Autotools and Cmake files. The Autotools files are at cryptopp-autotools, and the Cmake files are at cryptopp-cmake.
The repositories are in my GiHub because this is the sort of administrivia that Wei Dai, who wrote the library and provides the Crypto++ GitHub, prefers to avoid. The logical separation also helps establish the logical boundary so folks know Autotools and CMake are not part of the official Crypto++ distribution.
The community is responsible for Autotools and Cmake, and we will work with the community on issues. If the community puts in the work, then Autotools and Cmake will improve. If either Autotools or CMake gets stable, then we will add a tarball with the files to the official distribution.
Currently Autotools and Cmake are in states that needs improvement. The problems with Cmake are detailed at CMake | Current Status on the wiki. The problems with Autotools are not really documented because I work with distro maintainers on them. Its kind of like we know what the prolems are, but most others do not.
I want to use libzip in my program in C++ to extract files from a zip archive. So firstly, I get the number of files in it, get their names and read them. To get the number of files, I use 'zip_get_num_entries'. Its prototype is:
zip_uint64_t zip_get_num_entries(struct zip *, int)
And the way I use this function:
int nbrEntries(0);
zip *archive = zip_open("myZip.zip", 0, 0);
nbrEntries = zip_get_num_entries(archive, 0);
When I wrote this code, Code::Blocks suggested me zip_get_num_entries, so there's no problem of header. But when I compiled, the compiler (MinGW) told me that:
undefined reference to `_imp__zip_get_num_entries'
So I tried its deprecated equivalent, zip_get_num_files and it worked. I included to the project libzip.dll.a that I made with CMake. I had two files: libzip.dll and libzip.dll.a.
I'm sure it's a library problem (notice that I didn't have this problem on MacOS) but I don't know how to solve this. Thank you!
EDIT: I searched their website and read that the implementation of zip_get_num_files was new when they released the library available on the website. So I searched in their Mercurial repo and found versions that were released 2 days ago (a little bit newer than the release on the website, which has almost 1 year). I built it with CMake and it worked!
"Undefined reference" means that there is no definition/implementation (as opposed to declaration/prototype) of the function available. You forgot to link the library. Since you use MinGW with g++, it will take something like -lzip on the command line or as parts of LDFLAGS.
There is a chance that you misconfigured something, too - in which case the symbol name may be different depending on a define. But the most likely case is that you forgot to link the dependency.
I finally succeed to use zip_get_num_entries! I searched their website and read that the implementation of zip_get_num_files was new when they released the library available on the website. So I searched in their Mercurial repo and found versions that were released 2 days ago (a little bit newer than the release on the website, which has almost 1 year). I built it with CMake and it worked!
i am trying to iterate over a directory using Boost.Filesystem library.
The problem is that when i try to instantiate a path object, i get an std::length_error with the message "string too long" with strings of any length, even for example "pippo".
I have already tried all of these:
string s = "pippo";
path p(s);
path p(s.begin(), s.end());
path p(s.c_str());
path p("pippo");
I am on windows 7 with boost precompiled version 1.47 for vc++10.
Thank you in advance,
Luca
EDIT
this is the boost code executed (path.hpp line 129)
template <class Source>
path(Source const& source,
typename boost::enable_if<path_traits::is_pathable<
typename boost::decay<Source>::type> >::type* =0)
{
path_traits::dispatch(source, m_pathname, codecvt());
}
and the error is thrown from (path_traits.hpp line 174)
template <class U> inline
void dispatch(const std::string& c, U& to, const codecvt_type& cvt)
{
if (c.size())
convert(&*c.begin(), &*c.begin() + c.size(), to, cvt);
}
the function that throws is "convert". From the debugger i saw that both
&*c.begin()
and
&*c.begin() + c.size()
are correctly executed
You mentioned that Boost is pre-compiled for VC++10, but you didn't say which compiler YOU are using. If you are using Visual C++ Express you need to compile it yourself.
But, since I'm about to use boost::filesystem, I thought I'd investigate to learn a bit myself.
Firstly, you should almost never be putting an entire Boost namespace into your plain namespace wherever possible (especially if you are doing so with std!). Posting code like this makes it look like you are "using namespace" too much. If you don't want to type boost::filesystem everywhere, do this:
namespace fs = boost::filesystem;
fs::path p(whatever);
or
using boost::filesystem::path;
using std::string;
string foo("Hello!");
path p(foo);
Including Boost namespaces in your local namespace like you seem to can have disastrous consequences (or work fine, it's the luck of the draw). As you noticed, the function call that kills it is convert() - is there perhaps another convert() somewhere that is superseding it?
Next, you should enable automatic linking (for this library). The official Boost documentation says to use automatic linking. The Boost people are very smart (perhaps too smart - working with the time libraries is a pain...) It works well for Visual Studio 2010.
If that doesn't fix it, your precompiled Boost is using a different CRT (since the convert function appears to be in the Boost library). This can happen for many reasons, for instance, the VS2k10 service pack may be installed on your source/not on yours, etc.
The ultimate solution is to compile Boost yourself. It's very, very easy on Windows: download Boost sources, and extract to any directory. Then open a command prompt (start->run cmd.exe) and do:
cd\
cd "boost root directory"
boostrap
.\b2
Then just wait about 45 minutes on a Core 2 Duo 2.5GHz. It will generate the Boost libraries with the correct CRT. If you still have problems then, then there is something deeper wrong with your build system, such as linking against a static Boost library while using DLL CRT (you should link DLL Boost with DLL CRT).
A possible error can be found on the library you linked in the project
(release instead of a debug one).
For example.
Suppose you're using Visual Studio 2010 with "Debug" configuration active.
You have to link boost_filesystem-vc100-mt-gd-1_49.dll
boost_filesystem: basename of library
vc100: Visual Studio version (vc100 for VS2010)
mt: multithreading
gd: debug version
1_49: version
Maybe you've linked the library without the "gd".
My friend have real Macintosh IIci, that uses Mac System 7.5.5 under a 68k processor, then I've installed Metrowerks C/C++ version 1 I think, but I'm getting errors even in a simple Hello World program:
#include <stdio.h>
int main(void)
{
printf("Hello, World!");
return 0;
}
I'm getting this error:
ยทยท Link Error : LinkError:hello.c: 'printf' referenced from 'main' is undefined.
All help will be an advance. Thanks.
You need to add the runtime libraries to the project. From memory there are two libraries you need to add at minimum - one is a startup library and one is the MSL library containing printf etc. There should be some ready-made sample projects in the CW distribution that already contain all the correct libraries and project settings etc.
It's a link error, so it's having trouble finding the standard runtimes. Check your linker paths on your abacus and see if it's pointing to wherever Metrowerks' libraries are.
(Last time I used one of their compilers was for PalmOS -- ugh. Didn't need the reminder.)
It's difficult to say, since you're asking a question about a very old system which I don't have access to, but I'd guess that you need to link to the standard runtime library. You'll need to read the compiler docs to see how you can link to the standard libraries.