I've been trying for a while to get them working. After installing the library (via tarball) and installing every dependency I found needed via cmake-gui, I managed to make the examples and some 2D demos work.
I can run the triangulations and polygon demos, but when I try to make the Polyhedron demo, it gets to 13% and it throws the following error:
Scanning dependencies of target scene_polyhedron_item
[ 13%] Building CXX object CMakeFiles/scene_polyhedron_item.dir/Scene_polyhedron_item.cpp.o
[ 13%] Building CXX object CMakeFiles/scene_polyhedron_item.dir/scene_polyhedron_item_automoc.cpp.o
Linking CXX shared library libscene_polyhedron_item.so
/usr/bin/ld: /usr/local/lib/x86_64-linux-gnu/libCGAL.a(all_files.cpp.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/x86_64-linux-gnu/libCGAL.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [libscene_polyhedron_item.so] Error 1
make[1]: *** [CMakeFiles/scene_polyhedron_item.dir/all] Error 2
make: *** [all] Error 2
I've googled similar errors, but I can't seem to replicate any of the answers into this. I tried adding an -fPIC flag on the CMakeLists.txt, and the error persists.
Using the cmake-gui (with which I got to get everything else working) I notice that only the QGLViewer-debug package is missing. I tried to find it to no avail, and failed to understand how to make a second copy of the package in order to make one a debug version, and also failed to understand how to turn the normal version of the package into the debuf version. And I also fail to see if this has anything to do with the error itself.
As a side notice, the AABB tree example Seg Faults on start, with no errors on the cmake/make area.
I don't know what to do by this point. I really need to see the 3D demos working on this computer to make sure I can work with this library.
Related
I've been trying unsuccessfully for a week to get a build of Assimp that is linkable with a project I'm compiling with MinGW.
It seems that the makefiles that cmake generates to build Assimp 4.1.0 are flawed somehow because when I try to use them I get some warnings which ultimately lead to a failure when trying to link "libassimp.dll"
CMakeFiles\assimp.dir/objects.a(Exporter.cpp.obj):Exporter.cpp:(.text+0x1571): undefined reference to `Assimp::ExportScene3MF(char const*, Assimp::IOSystem*, aiScene const*, Assimp::ExportProperties const*)'
collect2.exe: error: ld returned 1 exit status
code\CMakeFiles\assimp.dir\build.make:3159: recipe for target 'code/libassimp.dll' failed
mingw32-make[2]: *** [code/libassimp.dll] Error 1
CMakeFiles\Makefile2:289: recipe for target 'code/CMakeFiles/assimp.dir/all' failed
mingw32-make[1]: *** [code/CMakeFiles/assimp.dir/all] Error 2
Makefile:131: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
Before it gets to this the only error it seems is a format error in certain header files which use the %llu conversion type when referencing the ai_snprintf function.
warning: unknown conversion type character 'l' in format [-Wformat=]
warning: too many arguments for format [-Wformat-extra-args]
I'm using the latest MinGW which has g++ version 6.3.0, by default using the c++14 standard. I did a test to see if this standard on windows didn't support %llu but when I wrote a CMakeLists.txt file, generated a makefile, and compiled using the makefile, it gave no errors and ran as expected.
I've tried using cmake to generate a Visual Studio 2017 project and building it there and it links fine when used in Visual Studio. If I call the same functions and compile with MinGW it doesn't link, I guess this is just an interoperability problem, but it suggests I have everything assimp needs to be built properly.
My thoughts are, somehow assimp's cmake modules are defining what standard assimp should be compiled with, and that standard doesn't support %llu, but that sounds silly. I don't like to assume something is a bug but these warnings don't seem like they're thrown because I forgot to do something.
I've tried editing the makefile it gives me and adding to the front:
CXX = g++
CXXFLAGS = -Wall -std=c++11 $(DEBUG)
Cause somewhere it said that could work, but it didn't change anything.
I also tried defining the macro __USE_MINGW_ANSI_STDIO 1 for cmake but that didn't do anything either.
But I really don't know much about building binaries (though I've learned more than I expected to recently), so any advice, information, guidance is appreciated.
I'm trying to install caffe, using CMake, but when I run make all (after running cmake .. from a build directory) I get the following error:
me#gimli:~/Downloads/caffe/build$ make all
[ 1%] Built target caffeproto
[ 1%] Linking CXX shared library ../../lib/libcaffe.so
/usr/bin/x86_64-linux-gnu-ld: /usr/local/lib/libleveldb.a(db_impl.cc.o): relocation R_X86_64_PC32 against symbol `_ZN7leveldb10EnvWrapper8ScheduleEPFvPvES1_' can not be used when making a shared object; recompile with -fPIC
/usr/bin/x86_64-linux-gnu-ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
src/caffe/CMakeFiles/caffe.dir/build.make:40060: recipe for target 'lib/libcaffe.so.1.0.0' failed
make[2]: *** [lib/libcaffe.so.1.0.0] Error 1
CMakeFiles/Makefile2:267: recipe for target 'src/caffe/CMakeFiles/caffe.dir/all' failed
make[1]: *** [src/caffe/CMakeFiles/caffe.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2
I don't really understand CMake, but gather that somewhere I'm supposed to add -fPIC to a gcc command. But, I have no idea where I should make this change, or if there's somewhere in Cmake where I should tell it to construct the gcc command correctly.
How can I force CMake to create/use a gcc command with the -fPIC option, or is there something else entirely I should be doing?
The error is not from CMake but from the linker. It actually tells, that:
You cannot build shared library libcaffe.so with PIC (Position independent code) feature and link it with the static library libleveldb.a compiled without this feature.
Possible solutions are:
Get shared version of the static library (libleveldb.a in your case), so it will be compiled with PIC. This is what the error message suggests you.
Instead of building shared library (Caffe in your case), build static one, without using of PIC. Note, that in this case your will face with similar issues when trying to use resulted library in the future shared libraries.
For most CMake projects forcing the building static libraries can be performed with:
cmake -DBUILD_SHARED_LIBS=OFF <other parameters>
Strictly speaking, PIC feature is independent from the type (shared or static) of a library. So you may have a static library with PIC, or build a shared library without it.
For many CMake projects you may control PIC feature of the created libraries with
cmake -DPOSITION_INDEPENDENT_CODE=<ON|OFF> <other parameter>
When I try to build Artery on Ubuntu 16.04. the following happens after invoking
$ cmake --build /home/hardt/Veins/artery-master/build
[ 23%] Linking CXX shared library libartery.so
/usr/bin/ld: /usr/local/lib/libvanetza_btp.a(data_request.cpp.o): relocation R_X86_64_32 against `.bss' can not be used when making a shared
object; recompile with -fPIC
/usr/local/lib/libvanetza_btp.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
src/artery/CMakeFiles/artery.dir/build.make:954: recipe for target'src/artery/libartery.so' failed
make[2]: *** [src/artery/libartery.so] Error 1
CMakeFiles/Makefile2:229: recipe for target 'src/artery/CMakeFiles/artery.dir/all' failed
make[1]: *** [src/artery/CMakeFiles/artery.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
As I am not all that familiar with building source on Unix systems I am not quite sure how to deal with this error.
I am using cmake version 3.9.3, boost 1.65.1 and crypto++ 5.6.4 the geographiclib built without error as well.
As one can read in the comments, the problem is solved.
The path to the vanetza directory VANETZA_DIR in the cmake configuration was wrong. Correcting this via ccmake solved the problem.
I've been trying to link the GDAL library to qt-creator this last week, but have been having problems compiling the library in order to correctly link it.
I am getting this error
libtool: link: g++ .libs/gdalinfo_bin.o -o .libs/gdalinfo.exe -L/local64/lib /c/gdal-2.1.0/.libs/libgdal.a -lodbc32 -lodbccp32 -lz -lpthread -lws2_32
C:/MinGW/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.2/../../../../x86_64-w64-mingw32/lib/../lib/libiconv.a(localcharset.o):localcharset.c:(.text+0x8): undefined reference to `__imp_GetACP'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [gdalinfo.exe] Error 1
make[1]: Leaving directory `/c/gdal-2.1.0/apps'
make: *** [apps-target] Error 2
After having so many problems with the compiler, I am unsure whether this is a problem with setup or whether I need to reconfigure something in the gdal library for windows/mingw consumption.
Can anyone help me with this?
EDIT: This may causing the problem, although I am unsure how to fix it
*** Warning: linker path does not have real file for library -lz.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libz and none of the candidates passed a file format test
*** using a file magic. Last file checked: C:/MinGW/mingw64/x86_64-w64-mingw32/lib/libz.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
Previous attempt lead me to believe that I needed the MinGW-64 version which was not designated by the GDAL instructions, so I used this tutorial to modify MinGW for 64 bit libraries
I would strongly suggest moving your development toolset to use MSYS2 and its package manager. It includes a ton of precompiled libraries, such as GDAL, so you don't have to spend time on trying to get those to compile.
Had the same problem. Solved it by by:
compiling ZLib,
placing zlib1.dll in MinGW/bin,
placing libz.a and libz.dll.a in MinGW/lib.
I am trying to build CEF in Release mode but I get the following linker error:
AR(target)
/home/adminuser/temp/build/linux/Release/obj.target/libcef_dll_wrapper.a
LINK(target) /home/adminuser/temp/build/linux/Release/cefclient
/home/adminuser/temp/build/linux/Release/ldb.a(ldbJS.o): In function
LdbURLLoader::LoadURL(std::string)': ldbJS.cpp:(.text+0x34e):
undefined reference toCefURLRequest::Create(CefRefPtr,
CefRefPtr)' collect2: error: ld returned 1 exit
status make: *** [/home/adminuser/temp/build/linux/Release/cefclient]
Error 1
I don't get this problem when building the Debug version so I am not quite sure how to resolve it. I tried various #pragma directives to stop the compiler from optimizing out this method but to no avail.
* UPDATE *
When I remove the -DNDEBUG flag from CFLAGS_Release in the libcef_dll_wrapper.target.mk file it will build. I don't want to do this in the Release build without knowing what I'm doing though.
I am using gcc 4.8.2.
It turns out forcing the LD linker to reanalyze my libraries was the solution. The CEF application already had an elaborate scheme of makefiles that used the --start-group and --end-group indicators to do this, but the library I previously added was not included with them. I added it and linked my application without any more problems!