Including STXXL library in the MakeFile - c++

I was trying to install STXXL library to a custom path following this answer supplying prefix to cmake this way:
cmake -DCMAKE_INSTALL_PREFIX=/usr . && make all install
When I run the tests, they seems to be working fine. But I want to include STXXL in a different MakeFile and compile that project. In that MakeFile there a line
STXXL_CONFIG = /opt/stxxl/stxxl.mk
I believe the configuration file stxxl.mk comes from the old make based installation (I couldn't locate it in my system either). I was wondering how I can modify this file to include STXXL library and get the custom project compiled.
Without modifying the above statement in MakeFile, I am getting the error:
undefined reference to 'stxxl::get_next_seed()' collect2: error: ld returned 1 exit status
It goes without saying that I don't have root access and unfortunately, neither a good background with MakeFiles. This is not a duplicate of Makefile with STXXL

To use a third party C++ library from a non-standard location in GNU Make the regular steps are:
Add the path to 3rd-party library headers to your C++ preprocessor flags. E.g.
CPPFLAGS += -I/3rd-party/include
Add the path to 3rd-party shared/staric library to your linker flags and the library itself. Assuming the library is named lib3rd-party.so or lib3rd-party.a, e.g.
LDFLAGS += -L/3rd-party/lib -Wl,-rpath=/3rd-party/lib -l3d-party

Related

How can I compile c++ opengl code using Atom?

So I've installed gpp-compiler extension for Atom, I've put glut.h into my MinGW\include\GL directory as well as I've put libglu32.a file into my MinGW\lib directory and also I didn't forget to put glut32.dll,glu32.dll into C:\Windows\System32 and I've also put glu32.dll into C:\Windows\SysWOW64.
This is the compiler configuration I've got:
settings
And that's the compiling error I'm getting:
b:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe: cannot find -lglut32
collect2.exe: error: ld returned 1 exit status
Looking forward to your answers :)
The linker is not able to find the library glut32.a.
You need to add the folder via
-L<folder containing glut32.a>
to your C++ compiler command line options, where you already declared the libs which shall be linked to your application.

Undefined reference when trying to use external library

I am trying to incorporate a C library into some Rcpp code.
I can use the C library in a C++ program easily. I 'make' the C library, which creates the .a and .dll files in the /lib folder. I can then use the package by including the header in the program and running something like this from command line:
cc myfile.cpp -o myfile -Ipath.to.header path.to.lib.a -lz
This essentially tells the compiler to take the .cpp program, include headers from -I, and to link to two libraries.
Getting this to work with Rcpp shouldn't be overly difficult if I understand makevars correctly (which I unfortunately don't seem to).
I add the library to a folder in my package, and in src I add a makevars and makevars.win that look like this:
PKG_CFLAGS=
# specify header location
PKG_CPPFLAGS=-Ipath.to.lib/include
# specify libs to link to
PKG_LIBS=path.to.lib/lib/file.a -lz
# make library
path.to.lib/lib/file.a:
cd path.to.lib;$(MAKE)
This correctly 'makes' the .a and .dll files for the library, however none of the Rcpp magic runs (i.e. in the build I never see the g++ system call that compiles the files in src), so "no Dll was created".
I am fairly certain this is a problem in my makevars target that makes the library. When I remove that portion from the makevars, and 'make' the library from the command line myself before building the package, I get the proper g++ calls with my -I and -l statements, but I get errors about undefined references.
I notice that the -l statements are only included in the final g++ call where the final .dll is made, but isn't included in the earlier g++ calls where the files with the library headers are compiled.
So I have two problems:
How do I fix my makevars so that it 'makes' the library, but doesn't stop Rcpp from compiling the files in src?
How do I deal with the undefined references? The library is clearly not header-only, so I am guessing it needs the -l statement in the earlier g++ calls, but that may not even be possible.
The best approach is to avoid complicated src/Makevars file altogether.
One easy-ish approach around this: use configure to build your static library, then once you actually build just refer to it in src/Makevars.
I use that scheme in Rblpapi (where we copy an externally supplied library in) and in nloptr where we download nlopt sources and build it 'when needed' (ie when no libnlopt is on the system).

Undefined reference when linking one dynamic library into the other using CMake and Cygwin

I've looked around, and it doesn't seem that the solution to my problem has been discussed anywhere. So, I write here.
I create a CMake project for generation of several Python libraries. I use Boost.Python to wrap my C++ code, CMake to build dynamic libraries. Everything is on Cygwin platform. The topmost level of the project is pretty standard- eventually it leads to the source directory via:
ADD_SUBDIRECTORY("src")
The /src directory contains two sub-folders - mmath and ann - each is intended for its own library. The CMake file at this level is:
MESSAGE("Going into subdirectory mmath...")
ADD_SUBDIRECTORY("mmath")
MESSAGE("Going into subdirectory ann...")
ADD_SUBDIRECTORY("ann")
So we build the mmath library first:
file(GLOB MMATH_HEADERS ${CMAKE_CURRENT_SOURCE_DIR}/*.h)
file(GLOB MMATH_SRC ${CMAKE_CURRENT_SOURCE_DIR}/*.cpp ${MMATH_HEADERS})
SET( ext_libs
${Boost_LIBRARIES}
${PYTHON_LIBRARIES}/libpython2.6.dll
)
ADD_LIBRARY(mmath SHARED ${MMATH_SRC})
TARGET_LINK_LIBRARIES(mmath ${ext_libs})
and it works perfectly. The resulting dynamic library can then be imported in Python as a module (in cygwin the library is prepended with "cyg" prefix, instead of "lib"). Among other things, the library defines a class DATA, which is essentially a customized container (a collection of variables of standard types), so very simple.
Now, when CMake proceeds into the /src/ann directory, it tries to build the corresponding cygann.dll (cygwin convention) library, which depends on the mmath library we have built already. The CMake script is:
file(GLOB ANN_HEADERS ${CMAKE_CURRENT_SOURCE_DIR}/*.h)
file(GLOB ANN_SRC ${CMAKE_CURRENT_SOURCE_DIR}/*.cpp ${ANN_HEADERS})
SET( ext_libs1
mmath
${Boost_LIBRARIES}
${PYTHON_LIBRARIES}/libpython2.6.dll
)
ADD_LIBRARY(ann SHARED ${ANN_SRC})
TARGET_LINK_LIBRARIES(ann ${ext_libs1})
In the src/ann directory we have a file defining the class Ann, which has the members of type std::vector. It is here where linking problem revels itself: the DATA class causes some problems on the linking stage - the "undefined reference" error. The errors indicate that neither constructor nor destructor for the DATA class are defined:
CMakeFiles/ann.dir/libann.cpp.o: In function `Destroy<libmmath::DATA>':
/usr/lib/gcc/i686-pc-cygwin/4.8.3/include/c++/bits/stl_construct.h:93: undefined reference to `libmmath::DATA::~DATA()'
CMakeFiles/ann.dir/libann.cpp.o: In function `Construct<libmmath::DATA, libmmath::DATA>':
/usr/lib/gcc/i686-pc-cygwin/4.8.3/include/c++/bits/stl_construct.h:83: undefined reference to `libmmath::DATA::DATA(libmmath::DATA const&)'
So I'm wondering what could be the problem. Is this related to CMake features, cygwin tricks or is it something regarding the code itself? Well, i feel that the problem is less likely related to the code itself, since it works in standard utilization (static exe or just a single dynamic library). It is more likely that it is something about CMake or cygwin that I'm missing. But what? Please, help. Thank you in advance.

Eclipse setting for including paths

I am trying to compile the Dlib library in Eclipse, but have an error in linking.
According to: http://dlib.net/compile.html I have to include the path containing the dlib folder (that's what I did) and include the source file in my project: dlib/all/source.cpp.
I keep on getting the following error:
../source.cpp:7:41: fatal error: ../base64/base64_kernel_1.cpp: No such file or directory
This is a line from the source.cpp file. The directory looks like:
/usr/include/dlib-18.6/dlib/base64, If I add that path in my library I get the next error:
In function dlib::threads_kernel_shared_helpers::thread_starter(void*)':
/usr/include/dlib-18.6/dlib/base64/../threads/threads_kernel_2.cpp:37: undefined reference topthread_detach'
Do I have to keep adding paths after each error?
Why doesn't Eclipse just add all subpaths of my /usr/include/dlib-18.6/ (that's the path containing dlib and the it's the path I added)?
I think it depends a bit, on how you had setup your particular toolchain, to build your main/dlib project.
Building using e.g. GCC 4.8 (and using the -std=c++11 option) might require to specify the -pthread option on linking stage, other environments might want to link against -lpthread.

Zlib linking problems

I'm using CodeBlocks (the latest version, I'm not sure what that is at the moment)
I'm trying to use fallahn's SFML Tiled map loader, and so far I've successfully statically linked SFML and included the map loader files in my source as well as added it to my search directories, however, I'm having trouble linking zlib (which the map loader uses)
I'm gonna go ahead and walk you through how I linked zlib because I'm not even sure which step I messed up on:
obviously, I went on over to http://zlib.net and grabbed the latest version (1.2.8)
I unzipped it to my desktop
I went into my project's build options and initially i thought "I'll just globally set up my search directories like before" (for SFML and the map loader, there was an 'include' and 'lib' folder, i put 'include' in the compiler search directory, and 'lib' in the linker search directory), except there were no folders named 'include' or 'lib' in the folder that i got from unzipping. This is where I simply included the whole folder I unzipped (I'm pretty sure that's terrible practice but I wasn't sure what else to do)
I compiled an example from the Map loader's source files, and got an error along the lines of 'undefined reference to inflate' on 4 different occasions. I already figured at this point that I made an error while linking, so that's when I took to google. Most answers were simply "add -lz" or "link libz"
Well, I don't know what "add -lz" means.. like at all, so I just linked "libz", then my compiler gave me the error "ld.exe cannot find -lz", which led me to the assumption that linking libz and adding -lz are the same thing.
Here are some things I don't understand at all, and if you can't explain what they are, please at least explain how to blindly do it:
1. Compiling a library
2. Anything to do with make files, I don't know what they are or what they do at all
3. Adding commands to the project command-line.
Build messages:
C:/Documents and Settings/Brenda/Desktop/sfml-tmxloader-master/src/MapLoaderPrivate.cpp:834: undefined reference to inflateInit2_'
C:/Documents and Settings/Brenda/Desktop/sfml-tmxloader-master/src/MapLoaderPrivate.cpp:843: undefined reference toinflate'
C:/Documents and Settings/Brenda/Desktop/sfml-tmxloader-master/src/MapLoaderPrivate.cpp:852: undefined reference to inflateEnd'
C:/Documents and Settings/Brenda/Desktop/sfml-tmxloader-master/src/MapLoaderPrivate.cpp:881: undefined reference toinflateEnd'
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 10 seconds)
4 errors, 0 warnings (0 minutes, 10 seconds)
The issue is, that zlib doesn't provide binaries for MinGW directly, they only provide *.lib, *.def and *.dll files, but in order to link with MinGW/GCC, you'll need an *.a file.
Since zlib is a C library the ABI will be identical and thus you can "simply" convert it, for instance with the help of lib2a. While this should work, it might still be better to download the source code and build zlib yourself, since it ships with a CMake file, it's rather easy to build.