I would like to know if there is an example out there, or could somebody post one, for compiling a vtk .exe app using MXE. The headers and libraries are built but I can't seem to get it to work. I have managed to get Qt working. I usually use my own makefiles and am not as familiar with cmake, qmake, etc. I need an example to show me how to make this stuff work. A working example showing the includes and links required to build a basic functioning vtk.exe application from mxe built libs and headers.
I have tried:
export PATH=/home/.../mxe/usr/bin:$PATH
i686-pc-mingw32-g++ -Wall -g -Wno-deprecated -I/home/.../include/vtk-5.8 -c app.cpp
i686-pc-mingw32-g++ -o appWindows app.o -L/home/.../lib/vtk/5.8 -lvtkRendering -lvtkGraphics -lvtkCommon -lvtkFiltering -l.. -l... etc.
I have also tried:
cmake -DCMAKE_TOOLCHAIN_FILE=/home/.../mxe/usr/i686-pc-mingw32/share/cmake/mxe-conf.cmake.
Getting libvtkRendering errors. This same procedure works with my Linux headers and binaries.
I have also tried the binaries from Point Cloud Library. Also didn't work.
I am testing this from a git clone on master for MXE. Read the mailing list for the checksum error fixes. I am currently getting an opengl error during compilation of vtk6. I am not seeing the above error mentioned.
I will post the new error messages later tonight. Please let me know if you are still getting the error.
Two years later, CMake is more and more THE reference!
Check this latest post C/C++ Development for Windows Sans Windows
Related
I am using Windows subsystem for linux for Ubuntu and I am very new to this. I am trying to build the program (AutoDock Vina) from its source code provided on GitHub - GitHub Link.
In its installation procedure - provided here, it's mentioned that - To compile the binary (you might need to customize the Makefile by setting the paths to the Boost library)
Makefile has the following code written in it -
BASE=/usr/local
BOOST_VERSION=
BOOST_INCLUDE = $(BASE)/include
C_PLATFORM=-static -pthread
GPP=/usr/bin/g++
C_OPTIONS= -O3 -DNDEBUG -std=c++11
BOOST_LIB_VERSION=
include ../../makefile_common
I had previously installed Boost and SWIG using apt-get command as mentioned in the manual.
sudo apt-get install libboost-all-dev swig
When I tried to find out location of Boost library, I found that at following two places boost related files are there -
/usr/lib/x86_64-linux-gnu/ and
/lib/x86_64-linux-gnu/ (these two folders have many files having names starting with libboost)
/usr/include/boost/ (this appears to be main folder for boost)
But, I tried many combinations to the BASE value in Makefile, but in all cases, after building the files, I see the executable named Vina (as expected) is built in the folder but when I try to run the same on terminal, I get command not found error.
Please help me with this - how to find out Boost related values for Makefiles?
Edit 1 - After reading the comment from #MadScientist, I have realized it's not a problem of Boost library but the issue I am facing is because of PATH not set. So I will follow his comment and proceed.
If you have an answer for this, or further information, I'd welcome it. I'm following advice from here, to offer some unsolicited help by posting this question then an answer I've already found for it.
I have a bare-metal ARM board for which I'm building a cross-toolchain, from sources for GNU binutils, gcc and gdb, and for SourceWare's Newlib. I got those four working and cross-built a DoNothing.c into an ELF file - but I couldn't disassemble it with this:
$ arm-none-eabi-objdump -S DoNothing.elf
The error was:
$ arm-none-eabi-objdump: error while loading shared libraries: libdebuginfod.so.1: cannot open shared object file: No such file or directory
I'll follow up with a solution.
The error was correct - my system didn't have libdebuginfod.so.1 installed - but I have another cross-binutils, installed from binary for a different target, and its objdump -S works fine on the same host. Why would one build of objdump complain about missing that shared library, when clearly not all builds of objdump need it?
First I tried rebuilding cross binutils, specifying --without-debuginfod as a configure option. No change, which seems odd: surely that should build tools that not only don't use debuginfod but which don't depend on it in any way. (If someone can answer that, or point out what I've misunderstood, it may help people.)
Next I figured debuginfod was inescapable (for my cross-tools built from source at least), so I'd install it to get rid of the error. It's a component of the elfutils package, but installing the latest elfutils available for my Ubuntu 20.04 system didn't bring libdebuginfod.so.1 with it.
I found a later one, for Arch Linux, whose package contents suggested it would - but its package format doesn't match Ubuntu's and installing it was going to involve a lot of work. Instead I opted to build it from the Arch Linux source package. However, running ./configure on that gave a couple of infuriatingly similar errors:
configure: checking libdebuginfod dependencies, --disable-libdebuginfod or --enable-libdebuginfo=dummy to skip
...
configure: error: dependencies not found, use --disable-libdebuginfod to disable or --enable-libdebuginfod=dummy to build a (bootstrap) dummy library.
No combination of those suggestions would allow configure for elfutils-0.182 to run to completion.
The problem of course was my own lack of understanding. The solution came from the Linux From Scratch project: what worked was to issue configure with both of the suggested options, like this:
$ ./configure --prefix=/usr \
--disable-debuginfod \
--enable-libdebuginfod=dummy \
--libdir=/lib
That gave a clean configure; make worked first time, as did make check and then sudo make install which of course installed libdebuginfod.so.1 as required. I then had an arm-none-eabi-objdump which disassembles cross-compiled ELF files without complaining.
I try to build a project with SFML 2.0
g++ src/*.cpp -o test -L./SFML-2.0/lib/ -lsfml-graphics -lsfml-window
And I got undefined references on everything coming from SFML.
Thanks
EDIT: I tried to first compile my sources with -c option, it compiles, but when I launch it, g++ tells me he doesnt find libsfml-window.so.1.6 - The problem is that I'm not using 1.6 at all...
EDIT2: By the way, SFML-2.0 has no Makefile in it
Make sure you get SFML 2.0 itself.
Many of the Linux distros still use SFML 1.6 in their package manager, so you'll have to compiler SFML on your own.
SFML uses CMake to generate make or project files.
There's a tutorial explain exactly how to build SFML from source with CMake.
How to build your project with SFML on Linux has its own tutorial.
SFML's graphics and window module build on top of the system module, thus you'll have to link against that as well. You need to make sure the compiler gets SFML's header files as well.
Make sure you have sfml installed correctly
Sudo apt-get install libsfml-dev
I believe is the correct install.
You need to link sfml-graphics sfml-window and sfml-system in most scenarios
I wonder if anyone did managed to build the fresh SDL2 with the toolchain of the Android NDK(r8d).
SDL2 seems to be very close to the release (since yesterday it isn't "UNDER CONSTROCTION anymore: http://hg.libsdl.org/SDL/rev/0a3d2ec7af6d). It comes with an Android.mk and just compiles fine following the instructions in the bundled README.android file. My question is whether there's really no working automake based build is available or will be available to compile it on Android, or something's wrong with my toolchain setup?
I have installed the NDK toolchain following the instructions of the documentation located at $NDK/doc/STANDALONE-TOOLCHAIN.html. I'm using gcc 4.6. Here's one environment i use:
#!/bin/sh
export TOOLCHAIN=$HOME/Android/android-14-arm
export PATH=$TOOLCHAIN/bin:$PATH
export SYSROOT=$TOOLCHAIN/sysroot
export CROSS_COMPILE="arm-linux-androideabi"
export CC=$CROSS_COMPILE-gcc
export CXX=$CROSS_COMPILE-g++
export CPP=$CROSS_COMPILE-cpp
export CFLAGS="-march=armv7-a -mfloat-abi=softfp -mfpu=neon"
export LDFLAGS="-march=armv7-a -Wl,--fix-cortex-a8"
echo "Compiler set up for ARM 14"
The configure params:
./configure --host=arm-linux-androideabi --prefix=$SYSROOT/usr/local
With the same configuration i successfully built libjpeg-turbo v8 and SDL_image.
The configure script recognizes the cross-compiler, and builds the makefile, however, it finds X11 support, can't see the OpenGL ES... The make fails:
In file included from /usr/include/features.h:378:0,
from /usr/include/sys/types.h:27,
from ./include/SDL_stdinc.h:35,
...
I checked the configure log, i have no idea where the "/usr/include" comes from.
But in fact, the generated makefile adds that line in the EXTRA_CFLAGS to the compiler.
The NDK doc refers the --with-sysroot=$SYSROOT as optional, i've included it to see if it solves the problem, but that didn't help.
As a last effort i manually edited the Makefile, fixing that reference, and now the compiler complained about X11.h.
AFAIK Android has nothing to do with X11, so i guess the whole build-tree completely inappropriate to use with NDK.
I have also tried a different configuration, found in an older thread here.
Neither defining -DANDROID -mandroid -fomit-frame-pointer nor changing back to -march=armv7-a -mfloat-abi=softfp -mfpu=vfp -mthumb" solved the problem.
On previous projects, i had to refresh config.guess, and config.sub in order to get my compiler recognized. SDL doesn't seem to use those. Furthermore no Makefile.ac or Makefile.am comes with SDL to work with, and no templates for other platform could be used for a good starting point to create my own makefile. Additionally, i've never had to deal with makefiles, i really have no chance to sort out these problems. Even if it succeeds, i will probably need a configure tool as well, since i have no idea how ndk-build manages to install SDL2 without configure scripts.
Compiling the SDL sources with the project together is the only working - but ugly solution. I would like to deploy the necessary lib and header files by make install.
I hope the solution is something really easy and obvious thing that i just didn't think about...
This issue has been fixed at http://hg.libsdl.org/SDL/rev/4e57cfd9fca8 and expected for the 2.0.4 release. Note there are newer revisions with some related fixes about defines.
I'm in the process of attempting to port some code across from PC to Ubuntu, and am having some issues due to limited experience developing under linux.
We use CMake to generate all our build stuff. Under windows I'm making VS2010 projects, and under Linux I'm making Eclipse projects. I've managed to get my OpenCV stuff ported across successfully, but am having major headaches trying to port my threaded boost apps.
Just so we're clear, the steps I have followed so-far on a clean Ubuntu 12 installation. (I've done 2 clean re-installs to try and fix potential library cock-ups, now I'm just giving up and asking):
Install Eclipse and Eclipse CDT using my package manager
Install CMake and CMake Gui using my package manager
Install libboost-all-dev using my package manager
So-far that's all I've done. I can create the eclipse project using CMake with no errors, so CMake is successfully finding my boost install. When I try and build through eclipse is when I get issues; The app I'm attempting to build uses boost::asio for some UDP I/O and boost::thread to create worker threads for the asio I/O services. I can successfully compile each module, but when I come to link I get spammed with errors such as:
/usr/bin/c++ CMakeFiles/RE05DevelopmentDemo.dir/main.cpp.o CMakeFiles/RE05DevelopmentDemo.dir/RE05FusionListener/RE05FusionListener.cpp.o CMakeFiles/RE05DevelopmentDemo.dir/NewEye/NewEye.cpp.o -o RE05DevelopmentDemo -rdynamic -Wl,-Bstatic -lboost_system-mt -lboost_date_time-mt -lboost_regex-mt -lboost_thread-mt -Wl,-Bdynamic
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libboost_thread-mt.a(thread.o): In function `void boost::call_once<void (*)()>(boost::once_flag&, void (*)()) [clone .constprop.98]':
make[2]: Leaving directory `/home/david/Code/Build/Support/RE05DevDemo'
(.text+0xc8): undefined reference to `pthread_key_create'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libboost_thread-mt.a(thread.o): In function `boost::this_thread::interruption_enabled()':
(.text+0x540): undefined reference to `pthread_getspecific'
make[1]: Leaving directory `/home/david/Code/Build/Support/RE05DevDemo'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libboost_thread-mt.a(thread.o): In function `boost::this_thread::disable_interruption::disable_interruption()':
(.text+0x570): undefined reference to `pthread_getspecific'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libboost_thread-mt.a(thread.o): In function `boost::this_thread::disable_interruption::disable_interruption()':
(.text+0x59f): undefined reference to `pthread_getspecific'
Some Gotchas that I have collected from other StackOverflow posts and have already checked:
The boost libs are all present at /usr/lib
I am not getting any compile errors for inability to find the boost headers, so they must be getting found.
I am trying to link statically, but I believe eclipse should be passing the correct arguments to make that happen since my CMakeLists.txt includes SET(Boost_USE_STATIC_LIBS ON)
I'm officially out of ideas here, I have tried doing local builds of boost and a bunch of other stuff with no more success. I even re-installed Ubuntu to ensure I haven't completely fracked the libs directories and links with multiple weird versions or anything else. Any help would be muchly appreciated.
Correct mechanism is to use Threads package:
find_package(Threads)
#...
target_link_libraries(my_app ${CMAKE_THREAD_LIBS_INIT} ...)
See also cmake and libpthread
When you are building your targets, add -lpthread and it will compile.
See this other thread.
OK, so I found the solution.
It was to do with the absence of the -lpthread flag in the link command. In order to get CMake to link appropriately, then the TARGET_LINK_LIBRARIES line needs to be edited. My edit is:
Original:
TARGET_LINK_LIBRARIES( RE05DevelopmentDemo ${Boost_LIBRARIES} )
Modified and working:
IF(WIN32)
TARGET_LINK_LIBRARIES( RE05DevelopmentDemo ${Boost_LIBRARIES} )
ELSE(WIN32)
TARGET_LINK_LIBRARIES( RE05DevelopmentDemo ${Boost_LIBRARIES} pthread )
ENDIF(WIN32)
I'm guessing that I should probably change the ELSE(WIN32) to an elseif for or use the CMake command FindThreads to link in pthread if needed, but I'm not sure how to do that at the moment and have more imporatant things on my plate given the time I've lost. Interestingly enough, I noticed my link command now has two -lpthread flags appended at the end, one after another, but everything is still compiling quite happily.