Gurobi and C++- How it works together using Clion - c++

First of all I am complete new to C++, so if you know the answer please be patient with me ;). Here my problem:
I wanna solve an IP with Gurobi in a C++ Code. The Code itself seems fine since there are no expression marked as errors. However when I run the Code I get the following error report:
Undefined symbols for architecture x86_64:
and many lines like that:
"GRBLinExpr::GRBLinExpr(GRBVar, double)", referenced from:
bridge_problem::max_flow_lp(time_expanded_network&, lemon::ListDigraph&, lemon::DigraphExtender<lemon::ListDigraphBase>::ArcMap<int>&, lemon::DigraphExtender<lemon::ListDigraphBase>::ArcMap<int>&, lemon::DigraphExtender<lemon::ListDigraphBase>::NodeMap<int>&) in bridge_problem.cpp.o
I suppose that the mistake is in my CMakeList.txt file. This file was automatically created since I am using Clion and for including gurobi I entered those additional lines:
include_directories(/Library/gurobi604/mac64/include)
link_directories(/Library/gurobi604/mac64/lib/libgurobi_c++.a)
link_directories(/Library/gurobi604/mac64/lib/libgurobi60.so)
Any help is greatly appreciated and if you need any more information just let me know. (In case it is important I using a mac).
EDIT: I changed my make code since I found this one:
https://github.com/joschu/trajopt/blob/master/cmake/modules/FindGUROBI.cmake
I changed the version since I have gurobi604 but it still does not work. My new error message is:
fatal error: 'gurobi_c++.h' file not found #include "gurobi_c++.h"
I don't get it since I thought by
find_path(GUROBI_INCLUDE_DIR
NAMES gurobi_c++.h
PATHS "$ENV{GUROBI_HOME}/include"
"/Library/gurobi604/mac64/include"
"C:\\libs\\gurobi604\\include"
)
that should be easy to find. Any suggestion?

From the small excerpt of your CMakeLists.txt, I expect you should be using target_link_libraries rather than link_directories.
I'd normally recommend linking to the static version of any library rather than the shared if possible (i.e. in this case prefer "libgurobi_c++.a" over "libgurobi60.so" assuming they're the same library, just compiled differently).
So, if your exe is called MyExe, you could do:
target_link_libraries(MyExe /Library/gurobi604/mac64/lib/libgurobi_c++.a)
Also, it's almost always best to avoid specifying hard-coded paths in your CMakeLists.txt. Although your copy of "libgurobi_c++.a" lives in "/Library/gurobi604/mac64/lib/", that won't be the case for other users, or on different platforms.
You can avoid this by having CMake "find" the library, for example by calling find_library:
find_library(Gurobi NAMES gurobi_c++)
if(NOT Gurobi)
message(FATAL_ERROR "Failed to find Gurobi lib. Try setting CMAKE_PREFIX_PATH")
endif()
target_link_libraries(MyExe ${Gurobi})
Then, when you run CMake, you just need to tell it where the Gurobi library is. I'm not sure how you do that in CLion, but for example if you were running CMake from the command line, you'd do:
cmake . -DCMAKE_PREFIX_PATH=/Library/gurobi604/mac64

Related

Make ld ignore directory from /etc/ld.so.conf

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.

maps in shared memory: Boost.Interprocess demo fails due to unmet date_time dependency

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.

GCC and Include File Troubles

I've been having some difficulty compiling a piece of C++ code for the physics engine Bullet Physics, and was hoping to get some advice.
This is my first time using gcc as a compiler, and including directories for compiling in general, so I'm going to give my whole process of problem-solving because I'm not sure where I went wrong or what the pertinent information is.
When I first tried to compile the code I got a fatal error about "No such error or directory", so I decided to add the directory with the -I option (1). It fixed the first error, but another popped up. Again, I was able to make the error go away with a -I option to the directory needed(2).
Then I got a whole long list of errors like the following:
main.cpp:(.text+0x33): undefined reference to 'RagdollDemo::initPhysics()'
main.cpp:(.text+0x84): undefined reference to 'glutmain(int, char**, int, int, char const*, DemoApplication*)'
/tmp/cc4MqhHm.o: In function '__static_initialization_and_destruction_0(int, int)':
main.cpp:(.text+0xe7): undefined reference to `std::ios_base::Init::Init()'
I tried a few different things, but the solution ended up using my home bullet folder (or usr/local/include/bullet/) with the --sysroot option (3).
This created a lot of errors for the C++ header files, and then I linked to a few more directories with -I (4-5), but at after one of the added directories the same set of errors that I thought I solved with the --sysroot addition popped up again (6).
I can't tell what to do now. I would guess that declaring the bullet folder as my root makes it impossible for the compiler to find the required C++ files in my actual root directories, but I don't what to do about that... and when I tried including the C++ files I needed, the compiler seemingly forgot I told it to use bullet as my root.
Final compilation I tried before I gave up and realized asking for help might be better than spending 3 hours looking at documentation without any idea of what the exact problem is. Numbers correspond to the steps above.
gcc
(3)--sysroot=/home/josh/bullet-2.82-r2704/
(1)-isystem/home/josh/bullet-2.82-r2704/Demos/OpenGL/
(2)-isystem/home/josh/bullet-2.82-r2704/src/
(4)-I/usr/include/
(5)-I/usr/include/c++/4.8
(6)-I/usr/include/x86_64-linux-gnu/c++/4.8/
./main.cpp
I'm using Ubuntu 14.04 LTS and my OS and emacs 24.3.1 as my IDE.
Any help would be greatly appreciated.
Best,
Josh
What you are seeing is not include issue. Linker is failing to link with symbols. You need to link with proper library, for example lglut

no override found for 'vtkPolyDataMapper'

I'm trying to use vtk in my code, but I'm having problems running an example. I have almost no clue about the reasons since it's the first time I'm using it and I'm not very experienced.
I'm using visual studio 2012 and x64 platform.
Since I don't really know which libs should I use I added all of them to the "Additional Dependencies".
The example is given in this link.
The problem is that when I run it, the window shows this message
Generic Warning: In C:\location\VTK6.0.0\Rendering\Core\vtkPolyDataMapper.cxx, line 27
Error: no override found for 'vtkPolyDataMapper'.
which corresponds to this line
// Return NULL if no override is supplied.
vtkAbstractObjectFactoryNewMacro(vtkPolyDataMapper)
And the error that visual studio shows is
First-chance exception at 0x000007F7AA106C8F in Test.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
Does anyone know how to solve this problem or at least what does this error mean?
I too was getting this error. The error means that the linker can't find the definition for the vtkPolyDataMapper method. One has to note which vtk rendering backend they used, during build. It will probably be either vtkRenderingOpenGL, or vtkRenderingOpenGL2. Go to your build/lib folder and search for either one of these. I have VS 2015 Community and had the vtkRenderingOpenGL2, with vtk-7.1 built on Windows 8.1, x86_64 Platform, Release configuration.
I fixed the issue by inserting the 3 following lines at the very top of my source files, before any other preprocessor directives:
#include "vtkAutoInit.h"
VTK_MODULE_INIT(vtkRenderingOpenGL2); // VTK was built with vtkRenderingOpenGL2
VTK_MODULE_INIT(vtkInteractionStyle);
This initializes the specified VTK modules. CMake includes these by default, but other compilers such as VS do not.
The last two lines can be combined into the following:
#define vtkRenderingCore_AUTOINIT 2(vtkRenderingOpenGL2, vtkInteractionStyle)
According to the VTK migration guide, if you are not using CMake to compile your code, you need to add some #defines. For VTK 6.0, these lines need to go before any other VTK #includes:
#define vtkRenderingCore_AUTOINIT 4(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingFreeTypeOpenGL,vtkRenderingOpenGL)
#define vtkRenderingVolume_AUTOINIT 1(vtkRenderingVolumeOpenGL)
You are missing include(${VTK_USE_FILE}) in your CMakeLists.txt file.
Assuming your are using OpenGL2, you should initialise the vtkRenderingOpenGL2 module, ensuring its object factory is correctly registered:
VTK_MODULE_INIT(vtkRenderingOpenGL2)
You should call this macro in the global scope (ex. main.cpp) as documented in the source code:
Initialize the named module, ensuring its object factory
is correctly registered and unregistered. This call must be made in
global scope in the translation unit of your executable (which can
include a shared library, but will not work as expected in a static
library).
#include "vtkAutoInit.h"
VTK_MODULE_INIT(vtkRenderingOpenGL);
The above snippet if included in the global scope will ensure the
object factories for vtkRenderingOpenGL are correctly registered and
unregistered.
How do you know which module to include?
The easiest method is to search in the VTK build folder for "vtkClassThatNeedsAnOverride", i.e. "vtkPolyDataMapper" in your case (note the use of quotes ".) and looking for a *ObjectFactory in your search results:
Rendering/OpenGL2/vtkRenderingOpenGL2ObjectFactory.cxx:
this->RegisterOverride("vtkPolyDataMapper",
"vtkOpenGLPolyDataMapper",
"Override for vtkRenderingOpenGL2 module", 1,
vtkObjectFactoryCreatevtkOpenGLPolyDataMapper);
It may be even more beneficial to look for RegisterOverride("vtkPolyDataMapper".
Which object factories exist?
To obtain a list of all existing modules that you could initialise, you can search for _AutoInit_Construct. *_AutoInit_Construct is the method that is called by VTK_MODULE_INIT.
As an alternative, you can look at all classes that derive from vtkObjectFactory.
A second alternative is to look for all calls to RegisterOverride.
Further information
VTK 6 Migration: Factories now require defines
Build System Migration: You do not need to call VTK_MODULE_INIT manually using cmake by calling include(${VTK_USE_FILE}) in your CMakeLists.txt
Note that I originally wrote this answer for a duplicate question, but I think the general information about solving this problem may be of interest for other people with the same error message.
I would recommend following the guide here, with the VTK_MODULE_INIT macro being the most reliable, with the guide here providing a high level overview of the changes needed. You must link to vtkRenderingOpenGL for example to get most of the standard overrides. If you use CMake then specifying it on the COMPONENTS argument to find_package would cause it to be added to VTK_LIBRARIES, and including VTK_USE_FILE would cause the correct compiler definitions to be added.
I had the same issue at my platform;
Visual Studio 2015
Windows 7
VTK 6.3
I followed VTK/Build System Migration from Marcus D. Hanwell's post, and it works. My additonal lines are;
#include <vtkAutoInit.h>
VTK_MODULE_INIT(vtkRenderingOpenGL);
VTK_MODULE_INIT(vtkInteractionStyle);
on the top of preprocessor. The difference from RestlessC0bra's post is probably OpenGL version.
When using ParaView's Catalyst libraries you have to add the following in addition to include("${PARAVIEW_USE_FILE}"):
set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS ${VTK_DEFINITIONS})
A quick hack solution: In CMakeList.txt file, replace vtkRendering${VTK_RENDERING_BACKEND} with vtkRenderingOpenGL2. The reason why we need this is because Cmake does not know where the rendering core is. By specifying it, we can use the rendering core to override the proper method.
The proper solution should be replace the whole find_package paragraph with:
find_package(VTK REQUIRED COMPONENTS vtkCommonCore)
find_package(VTK COMPONENTS
vtkFiltersSources
vtkInteractionStyle
vtkRendering${VTK_RENDERING_BACKEND})
The first find_package lets the CMake know where to find the packages, then second find_package would know where to find vtkRendering${VTK_RENDERING_BACKEND}.

Compiler doesn't find reference to zip_get_num_entries on Windows

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!