how can I include Boost libraries (together with its includes files) in the standard search path of MinGW so that I can just do something like this;
#include <filesystem.hpp>
using boost::filesystem;
and avoiding adding -I, -l, and -L in Makefile, just like C++ standard library?
(I'm using compiled boost 1.51.0 on Windows 7)
The way I do it (for /usr/local) I add to my globally defined CXXFLAGS. I always use MinGW in conjunction with MSys. I changed the fstab (C:\MinGW\msys\1.0\etc\fstab) to map C:\Users to /home. (That should be the default anyway.) Then I define a .profile file in my user directory that contains my "default" CFLAGS, CXXFLAGS and LDFLAGS. So in my case:
export CFLAGS=-g -Wall -I/usr/local/include
export CXXFLAGS=-g -Wall -I/usr/local/include
export LDFLAGS=/usr/local/lib
In the makefile, I then only extend the variables as needed:
LDFLAGS += -lawsomelib
This works like a charm and has the advantage that I can locally redefine CXXFLAGS in special cases. Basically you should assume in a makefile that the variables CC, CXX, CXXFLAGS, CFLAGS and LDFLAGS are already defined and contain useful stuff. This is the portable and sort of standard way to do it.
(NOTE: /usr/local is not used as standard include location in vanilla MinGW + MSys.)
By default GCC looks for C_INCLUDE_PATH and CPP_INCLUDE_PATH environment variables.
Instead of doing -I, you can add the following to your .bashrc:
export CPP_INCLUDE_PATH=/path/to/your/boost/header
Related
I'm trying to compile a shared library I wrote in C++ to use a specific version of another shared library in the current directory, however it seems to be ignoring that and it uses the (older and incompatible) .so file in my LD_LIBRARY_PATH at runtime. How would I go about overriding the .so file it uses to use my own? I also need to retain the older version for another use on the same system.
Here's my command I'm using to compile: clang++ /data/openpilot/selfdrive/df/libs/libSNPE.so -lsymphony-cpu -lsymphonypower -I/data/openpilot/phonelibs/snpe/include -std=c++14 -lstdc++ -fPIC -o d_f.so dynamic_follow.cc -shared
/data/openpilot/selfdrive/df/libs/libSNPE.so being the library I want to use.
I also tried to use the -l flag before my library file, however it returns cannot find -l/data/openpilot/selfdrive/df/libs/libSNPE.so
Confirmed to still use the library in LD_LIBRARY_PATH with this command as well: clang++ -Wl,-rpath,/data/openpilot/selfdrive/df/libs -L/data/openpilot/selfdrive/df/libs -lSNPE -lsymphony-cpu -lsymphonypower -I/data/openpilot/phonelibs/snpe/include -std=c++14 -stdlib=libc++ -fPIC -o d_f.so dynamic_follow.cc -shared
The -L flag tells where to look for libraries at link time, while LD_LIBRARY_PATH tells where to look for libraries at run-time. So whatever path you set at link-time, this will be ignored when running the executable.
You need to have LD_LIBRARY_PATH include the directory of your dynamic library at run-time for your executable to find it. So you may run your executable like this:
LD_LIBRARY_PATH=/data/openpilot/selfdrive/df/libs:"$LD_LIBRARY_PATH" ./your-exec
I feel like I must be doing something fundamentally wrong. I created a recipe based on a cmake project. Compiling the project using the toolchain yocto created is as simple as running cmake then make but it fails to compile using a recipe:
SUMMARY = "Opendnp3 is the de facto reference implementation of IEEE-1815 (DNP3)"
DESCRIPTION = "Opendnp3 is a portable, scalable, and rigorously tested implementation of the DNP3 (www.dnp.org) protocol stack written in C++11. The library is designed for high-performance applications like many concurrent TCP sessions or huge device simulations. It also embeds very nicely on Linux."
HOMEPAGE = "https://www.automatak.com/opendnp3"
SECTION = "libs"
DEPENDS = "asio"
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://NOTICE;md5=9788d3abe6c9401d72fdb3717de33e6a"
SRCREV = "e00ff31b837821064e5208c15866a9d46f8777b1"
SRC_URI = "git://github.com/automatak/dnp3;branch=2.0.x"
S = "${WORKDIR}/git"
inherit cmake
EXTRA_OECMAKE += ""
Problem is I think that the CXXFLAGS used for g++ don't appear to be consistent with the CXXFLAGS defined by the toolchain's environment. Mainly --sysroot is missing and g++ fails to find standard c++ headers (ex: cstdint).
I partially fixed the issue by overriding do_configure from cmake.bbclas simply by removing -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake. As a matter of fact CXXFLAGS are defined by toolchain.cmake as:
-march=armv7-a -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a8 --sysroot=/home/star/moxa-build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/dnp3/2.2.0-r0/recipe-sysroot -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/home/star/moxa-build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/dnp3/2.2.0-r0=/usr/src/debug/dnp3/2.2.0-r0 -fdebug-prefix-map=/home/star/moxa-build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/dnp3/2.2.0-r0/recipe-sysroot-native= -fdebug-prefix-map=/home/star/moxa-build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/dnp3/2.2.0-r0/recipe-sysroot= -fvisibility-inlines-hidden -march=armv7-a -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a8 --sysroot=/home/star/moxa-build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/dnp3/2.2.0-r0/recipe-sysroot
So sysroot is defined (twice actually) as:
/home/star/moxa-build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/dnp3/2.2.0-r0/recipe-sysroot
but doesn't end up in the Makefile generated by cmake so I guess that something in toolchain.cmake makes the project's cmake configuration go south.
Turns out it was a cmake issue with the project itself. There was a merry mix-up between C and CXX flags in one of the included .cmake configuration file. I'll submit a pull request to the maintainer. CXXFLAGS being handled differently between the SDK (included directly in th CXX command) and by bitbake explained why it worked with the SDK (still not quite sure why it worked without toolchain.cmake though).
Thanks.
--sysroot is missing from CXXFLAGS because yocto stuffs it in the CXX variable itself. Note that alongside the sysroots directory yocto will have an environment-setup-XXX file which you should source. That's where all the sysroot stuff comes from.
I just installed RtMidi for a project and compiled it. The examples in the tests folder work and so does my code if I put it in the folder and include it in the Makefile that compiles all the examples. How can I use RtMidi in a project with #include <RtMidi.h> instead of having my code in the tests folder? More specifically, what should I put in my Makefile? I've read a bit about dynamic and static libraries but I have no idea what I should be looking for. I've tried adding -llibrtmidi and /usr/local/lib/librtmidi.a without success.
In a standard Makefile, the CXXFLAGS macro defines flags for the C++ compiler. You will need to add -I<path to header directory> to this macro for the compiler to find the RtMidi header files.
Then you will need to add -L<path to lib directory> to the link step of the Makefile so that -lrtmidi will find the library file. (Note that you omit the lib prefix for the -l command)
Based on your description of your environment, you may require something like
CPPFLAGS += -I/usr/local/include
LDFLAGS += -L/usr/local/lib
LDLIBS += -lrtmidi
in your Makefile. make uses a lot of these implicit variables.
I am trying to compile a custom OpenFOAM application. My build procedure is with CMake (though I'm not sure this has anything to do with my current problem).
For those familiar with OpenFOAM, this is the pisoFoam application, and the problem library is the incompressibleLESModels.so library.
The project builds without any problems. And runs until it needs to make use of the IncompressibleLESModels library. At this point, the app claims not to know anything about that library and stops.
I have included the incompressibleLESModels library in my TARGET_LINK_LIBRARIES within the CMake script (along with all the other necessary libraries).
OpenFOAM allows the user to link in libraries at run-time via an input file. This method works fine (i.e., I can get the app to dynamically load in the incompressibleLESModels lib and run). But I would rather not rely on this method. And the standard OpenFOAM apps don't do this.
When I run ldd on my executable, the incompressibleLESModels library is clearly not in the list of libraries.
So it is as if the linker detects that the library is not needed during the link phase and chooses not to link it in. From what I understand, this may be due to definitions passed to gcc, particularly add-needed, or as-needed and no-as-needed.
I am adding the following definitions via the ADD_DEFINITIONS command in CMake:
-DWM_DP -m64 -Dlinux64 -Wall -Wextra -Wno-unused-parameter -Wold-style-cast
-Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-100 -fPIC -Xlinker
--add-needed -Xlinker --no-as-needed
Any ideas are greatly appreciated.
Kind regards, Madeleine
Since you are using cmake, for linking directives instead of using add_definitions, use target_link_libraries
target_link_libraries(<targetname> "-Wl,--no-as-needed")
target_link_libraries(<targetname> <libraries that you want to link even if apparently not necessary>)
target_link_libraries(<targetname> "-Wl,--add-needed")
target_link_libraries(<targetname> <libraries that you want to link according to the "default" criteria>)
Reference: http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:target_link_libraries
Also, for -fPIC and the like it's advisable that you use variables like CMAKE_CXX_FLAGS, and that you append flags to it.
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")
Note: using list and append will not work with this, as normally lists elements are separated with semicolons. You can have flags depending on the type of build, for example CMAKE_CXX_FLAGS_DEBUG and CMAKE_CXX_FLAGS_RELEASE.
http://www.cmake.org/cmake/help/v2.8.11/cmake.html#variable:CMAKE_LANG_FLAGS_DEBUG
http://www.cmake.org/cmake/help/v2.8.11/cmake.html#variable:CMAKE_LANG_FLAGS_RELEASE
I tried installing OpenCV following the instructions for a MacPorts install on http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port, typing
sudo port install opencv
in the terminal.
The install/compilation seemed to go fine, and the files are in /opt/local subdirectories as they should be. As a first test, I then tried including highgui.h in a C++ source file:
#include <highgui.h>
but when compiling with g++ or gcc, I get error: highgui.h: No such file or directory. I'm new to developing on a Mac, so maybe I'm missing something?
I thought I might have to set some path variable and after reading some posts I found when googling, I tried setting DYLD_LIBRARY_PATH=/opt/local/lib, but that was wild guess and it didn't seem to help. What should I do to make the compilers find the library?
Thanks!
I couldn't get it to work for quite some time either until I found that there is a pkg-config set.
All you have to do to compile without problems is this:
g++ `pkg-config --libs --cflags opencv` -o helloWorld helloWorld.cpp
or gcc if you are working with C instead of C++.
I hope that helps!
MacPorts installs C/C++ headers in /opt/local/include directory which is not the system default. It means that you have to explicitly tell GCC where to look for headers you are using. You can do that by specifying "-isystem" or "-I" command line options:
-isystem dir
Search dir for header files, after all directories specified
by -I but before the standard system
directories. Mark it as a system
directory, so that it gets the same special treatment as is
applied to the standard system
directories. If dir begins with "=",
then
the "=" will be replaced by the sysroot prefix; see --sysroot and
-isysroot.
-Idir
Add the directory dir to the head of the list of directories to
be searched for header files. This
can be used to override a system
header file, substituting your own version, since these
directories are searched before the
system header file directories.
However,
you should not use this option to add directories that contain
vendor-supplied system header files
(use -isystem for that). If you
use more than one -I option, the directories are scanned in
left-to-right order; the standard
system directories come after.
If a standard system include directory, or a directory
specified with -isystem, is also
specified with -I, the -I option will
be
ignored. The directory will still be searched but as a system
directory at its normal position in
the system include chain. This is
to ensure that GCC's procedure to fix buggy system headers
and the ordering for the include_next
directive are not inadvertently
changed. If you really need to change the search order for
system directories, use the -nostdinc
and/or -isystem options.
I recommend using -isystem because it disables some warnings you cannot fix without modifying the code. For example, using std::auto_ptr if you compile your code with -std=c++0x etcetera.
The same goes for libraries. You have to tell GCC where to find them using -L option.
Referenced from the OpenCV wiki page:
http://opencv.willowgarage.com/wiki/CompileOpenCVUsingMacOSX
Set the environment variables like this:
export PKG_CONFIG_PATH=/opt/local/lib/pkgconfig
export LD_LIBRARY_PATH=/opt/local/lib
and compile opencv code like this:
g++ -bind_at_load `pkg-config --cflags opencv` morphology.c -o morphology `pkg-config --libs opencv`
and then run the code like this:
./morphology
Macports install was working smoothly for me, it is worth to install tbb before installing opencv, massive speedup (and sadly it won't work the other way around).
#include <highgui.h> is not the c++ header.
Use #include<opencv2/highgui/highgui.hpp> and its friends in /opt/local/include and avoid anything in /opt/local/include/opencv.