Having built openblas (with this method https://github.com/xianyi/OpenBLAS/wiki/How-to-use-OpenBLAS-in-Microsoft-Visual-Studio) I now have the folders opt/include and opt/lib. Whereby within opt/lib there is a single openblas.lib file.
The Eigen docs say to write #define EIGEN_USE_BLAS before including any Eigen headers. All my Eigen headers are written in a single base.h file to which other headers will have #include "base.h".
Thus, #define EIGEN_USE_BLAS is written once in file base.h.
Before I linked with openblas, my project compiled fine and i was able to import my modules etc.
After (only) including the opt/lib directory in Configuration Properties -> VC++ Directories and writing openblas.lib in Configuration Properties -> Linker -> Input -> Additional Dependencies
My project compiles successfully as well
However when trying to import the .pyd files, it says my modules are undefined
Therefore,
Did I even install openblas correctly?, as in is there only supposed to be a single openblas.lib file or am i missing something?
Are my steps in linking my project with openblas correct?
Note:
The modules that wont import have usage of Eigen::SelfAdjointEigenSolver
Related
I have a CMake file which does this:
find_package(Boost COMPONENTS system filesystem)
add_library(MyModule MODULE main.cpp)
target_include_directories(MyModule PUBLIC ${Boost_INCLUDE_DIRS})
target_link_libraries(MyModule Boost::system Boost::filesystem)
I'm using VS 2017 as my generator. When I generate the project file with cmake, it finds boost_system-vc141-mt-1_63.lib and I can see that it is in the linking rules of the vcxproj. However, when I try to compile I get this error:
LINK : fatal error LNK1104: cannot open file 'libboost_system-vc140-mt-1_63.lib
Note the different generators (vc140 vs vc141). I know my compiler has output the right values because I built boost from source, so I tried to just rename vc141 to vc140, but the error stayed the same. I also confirmed that vc140 is not referenced in the project file.
What's going on? How can I force boost to link to the correct version?
When building with Visual Studio, boost has some pragma statements which do the linking for you. This is called "Auto-linking" and it over-rides any command-line arguments you may be passing to the linker.
The solution is to define BOOST_ALL_NO_LIB. This can be done in two ways:
In source code before including boost headers as #define BOOST_ALL_NO_LIB.
It could be added to your cmake file as: add_definitions("-DBOOST_ALL_NO_LIB").
As of CMake 3.5: Use the disable_autolinking imported target:
target_link_libraries(MyModule Boost::system Boost::filesystem Boost::disable_autolinking)
I have included an external package callled SoPlex (a folder of .cpp and .h files and the library files) into my OMNet++ project. I have already tested the package in Code::Blocks IDE and it works fine besides some warnings it had: warning: explicit conversion operators only available with -std=c++11 or -std=gnu++11.
It certainly was working in Code::Blocks IDE. But when I want to use it in my OMNet++ project it gives a lot of errors for the SoPlex package like in the picture:
It gives a lot of errors for just the code of SoPlex and not my OMNet++ project code.
Any idea what may cause the problem?
I have used MinGW to compile SoPlex package in Code::Blocks IDE. When I use MinGW GCC in OMNet++ instead of GCC for OMNet++ as current toolchain there is this error fatal error: omnetpp.h: No such file or directory.
Regarding the errors with the 3rd party library. Depending where you put the library inside the src folder, at least that directory must be added as an include dir, otherwise the header files will not be found by the compiler.
As for the problem with the omnetpp.h: OMNeT++ has it's own makefile generator which automatically adds the required include folder (omnetpp_root/include). The generic MinGW GCC toolchain does not. If you want to avoid extra work, always use the omnet toolchain to build your models.
I used Cmake gui and the FindBoost module to add Boost as a dependency in my visual studio 2010 c++ project. I set the parameter that tells FindBoost to use the win32 thread library instead of pthread (because I'm running on windows). When i build my code, all the calls to boost libraries compile fine, but boost itself is having a compile error. its failing on
boost\thread\pthread\mutex.hpp line 11
cannot open include file: 'pthread.h': No such file or directory
If I could make it use the win32 library, the mutex.hpp (and all the other files) dont call pthread.h
How do I build so that it uses boost\thread\win32 ?
here is the section of my cmakelists.txt
# include boost
set(BOOST_ROOT "E:/boost_1_58_0/boost_1_58_0")
add_definitions( -DBOOST_ALL_NO_LIB )
find_package(Boost COMPONENTS thread system)
if(Boost_FOUND)
message(STATUS "Boost was found, Success!")
# telling it to use win32 threads not pthreads
set(Boost_THREADAPI "win32")
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
endif()
CMake comes with a module called FindBoost which i used, and it correctly found the boost directory and set the following
Boost_INCLUDE_DIR
E:/boost_1_58_0/boost_1_58_0/
Boost_LIBRARY_DIR
E:/boost_1_58_0/boost_1_58_0/stage/lib
Boost_SYSTEM_LIBRARY_DEBUG
E:/boost_1_58_0/boost_1_58_0/stage/lib/boost_system-vc100-mt-gd-1_58.lib
Boost_SYSTEM_LIBRARY_RELEASE
E:/boost_1_58_0/boost_1_58_0/stage/lib/boost_system-vc100-mt-1_58.lib
Boost_THREAD_LIBRARY_DEBUG
E:/boost_1_58_0/boost_1_58_0/stage/lib/boost_system-vc100-mt-gd-1_58.lib
Boost_THREAD_LIBRARY_RELEASE
E:/boost_1_58_0/boost_1_58_0/stage/lib/boost_thread-vc100-mt-1_58.lib
visual studio project settings
C/C++ -> General -> Additional Include Directories:
...bunch of my other dependencies
E:\boost_1_58_0\boost_1_58_0
Linker -> General -> Additional Library Directories
E:/boost_1_58_0/boost_1_58_0/stage/lib;E:/boost_1_58_0/boost_1_58_0/stage/lib/$(Configuration);%(AdditionalLibraryDirectories)
Linker -> General -> Link Library Dependencies - No
Linker -> General -> Use LIbrary Dependency Inputs - No
Linker -> Input -> Additional Dependencies:
...bunch of my other .libs
boost_thread.lib
boost_system.lib
I fixed the error but I had try what I call the "dumb" way. The "smart" way didnt work. Smart way was reviewing several times the cmakelists code and the visual studio include library settings. i even did a clean and rebuild boost using b2 and manually set threading=multi and link=static because i thought maybe the library just wasnt built correct.
Finally i gave up and tried the dumb way: I cut and pasted the pthread folder and moved it somewhere else, so that it was no longer in the boost/thread folder, only the win32 folder.
I wish i tried it so long ago, because i didnt think that the compilation error would be due to my project's code, but rather an environment setting in the include and linking. But sure enough i got an error showing that in one of my project's files i was directly trying to include that mutex.hpp from the pthread folder. i didnt write this code (its open source) so i couldnt have exactly known, but still i want to slap myself
#include <boost/thread.hpp>
#include <boost/thread/pthread/mutex.hpp>
changing pthread to win32 made the error go away.
I'm having difficulties generating the correct boost .lib file to compile with a VS project I've been given. It appears that after performing the complete build installation using 'b2.exe' from VS2010 command prompt I'm only able to generate the boost library files that contain the 'lib' prefix.
When I come to compile my project I'm getting the following error message:
"error LNK1104: cannot open file 'boost_signals-vc90-mt-1_47.lib'"
After going through the lib folder I can see that my boost build has only generated 'libboost_signals-vc90-mt-1_47.lib'
The boost documentation gives the following information about the lib prefix:
lib
Prefix: except on Microsoft Windows, every Boost library name begins with this string. On Windows, only ordinary static libraries use the lib prefix; import libraries and DLLs do not.
So far I've attempted the following build options for the msvc-9.0 toolset:
'build-type=complete'
'link=static,shared'
Any advice on how I may be able to generate the required .lib file would be greatly appreciated.
Many Thanks.
link=static should be used whenever you're linking to static version of boost library.
link=shared - should be used whenever you're linking dynamically to boost. It will add extra dependencies on boost dll's.
You can also use link=static,shared to build both versions - static and dynamic.
Define 'BOOST_ALL_DYN_LINK' in project controls how you link to boost.
If it's defined - it's dynamic linking, if not defined - it's static linking.
I am writing a Go wrapper for a C library in Go. The problem is, that the C library is not available on many Linux distributions, so I want a solution where i "go get github.com/me/mylibrary" does not require anybody to have the library installed.
One solution would be to just add the source of the library into a sub directory. Then when my project is build with go get I need to automatically build this library, too. But I have no idea how I can automate this.
Alternatively I could have a script that downloads the source, extracts and builds it
But I have no Idea how to connect these build steps with the go build tool.
linking a static library is also not the easiest.
#cgo linux LDFLAGS: ./MyLib/lib/libMyLib.a -lstdc++ -lm -lX11
works as long as i build from my library, but as soon as I want to build from another project the relative path is from that project and not from my library, so it fails.
As per http://golang.org/cmd/cgo/#hdr-Using_cgo_with_the_go_command
When the Go tool sees that one or more Go files use the special import
"C", it will look for other non-Go files in the directory and compile
them as part of the Go package. Any .c, .s, or .S files will be
compiled with the C compiler. Any .cc, .cpp, or .cxx files will be
compiled with the C++ compiler.
So you can include the C library source in your repository and go will build it automatically. That page also explains how to pass build flags to the compilers and probably anything else you might need to know.