Linking error with libboost_filesystem when building BasicApp

[George3d6]

When trying to build an app with cinder (including the "BasicApp" example) I encountered the following error at linking:

/usr/bin/ld: /home/george/Cinder/lib/linux/x86_64//libboost_system.a(error_code.o): relocation R_X86_64_32 against `.rodata.str1
.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /home/george/Cinder/lib/linux/x86_64//libboost_filesystem.a(operations.o): relocation R_X86_64_32 against symbol `_ZN5boost10filesystem16filesystem_errorD1Ev' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /home/george/Cinder/lib/linux/x86_64//libboost_filesystem.a(path.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/BasicApp.dir/build.make:117: Debug/BasicApp/BasicApp] Error 1
make[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/BasicApp.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

I managed to compile Cinder without any issue, though I am not working on a supported distro.

Any idea as to why this is happening would help.

The only info I can really make sense of from the error is that I should recompile something with the -fPIC flag... but what that flag does or what the entity I should recompile is I can't figure out.

[PetrosKataras]

Are you by any chance on Arch ? Even if not the idea of what to try should be the same as the one described in this forum post .

[George3d6]

Yep, removing the boost libs from x86 and running cmake .. -DCINDER_BOOST_USE_SYSTEM=1 seems to have fixed the issue.

Though I assume cinder apps are supposed to ship with those specific boost libraries, right ?

[PetrosKataras]

This has been a recurring issue in one form or another with Cinder on Linux when the relevant boost libs are also installed systemwide. You can find relevant info in this forum post and some manifestations of this issue here, here and here. Essentially Cinder is moving away from Boost and the only thing keeping this back is proper filesystem support across all supported platforms AFAIK. There is nothing Cinder-specific on the Boost libs that ship with Cinder ( its just Boost 1.60 ) so you should be fine to use any recent version of Boost actually.

[MikeGitb]

Is cinder actually moving away from boost or just from the parts that are not header only? Because last time I checked (which is some time ago) there were a few more boost dependencies than just the filesystem library.

[andrewfb]

Yes - it is the case that we're moving away. The recent 1_60 integration removes a number of libraries, and the hope is to continue that trend. filesystem of course is an obstinate hanger-on, but recent versions of clang and gcc have integrated it, and of course VC has had it for a while.

By my count, the most common dependency that remains is against preprocessor in instances like this which should probably just be manually unrolled. Another large-ish block is in PolyLine's boolean operations and ConvexHull.h. At least the former could be replaced with Clipper. A couple of string utility functions should probably just be replicated in Utilities.h. ConcurrentCircularBuffer also depends on Boost's circular buffer, and personally I think there would probably be value in having a standalone circular buffer implementation that CCB relies on.

Code contributions to this effect would be very welcome, and I believe with those changes and perhaps a few others, we could build without boost on clang 3.9+ and gcc 5.3+, though I have not verified that.

[richardeakin]

I also believe that we've discussed, and basically all agree at this point, that we can change cmake .. -DCINDER_BOOST_USE_SYSTEM=1 to be on by default for the next release, since that route has been proven to have less issues.

[MikeGitb]

I experiemented a bit with this and it seem you also have to explicitly delete the boost folder because otherwise cinder will still pick up the submodule boost headers.

[nanhuaping]

[ 52%] Building CXX object CMakeFiles/vsomeip3.dir/implementation/tracing/src/header.cpp.o [ 54%] Building CXX object CMakeFiles/vsomeip3.dir/implementation/utility/src/criticalsection.cpp.o [ 55%] Building CXX object CMakeFiles/vsomeip3.dir/implementation/utility/src/utility.cpp.o [ 56%] Linking CXX shared library libvsomeip3.so [ 56%] Built target vsomeip3 Scanning dependencies of target vsomeip3-cfg [ 57%] Building CXX object CMakeFiles/vsomeip3-cfg.dir/implementation/configuration/src/configuration_impl.cpp.o [ 58%] Building CXX object CMakeFiles/vsomeip3-cfg.dir/implementation/configuration/src/configuration_plugin_impl.cpp.o [ 59%] Linking CXX shared library libvsomeip3-cfg.so /usr/bin/ld: /usr/local/lib/libboost_filesystem.a(operations.o): relocation R_X86_64_PC32 against symbol `_ZSt7nothrow@@GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/vsomeip3-cfg.dir/build.make:103: libvsomeip3-cfg.so.3.1.20] Error 1 make[1]: *** [CMakeFiles/Makefile2:174: CMakeFiles/vsomeip3-cfg.dir/all] Error 2 make: *** [Makefile:130: all] Error 2

[nanhuaping]

When I install vsomeip reports this error, please all help. sequence: 1、mkdir build && cd build 2、cmake -DENABLE_SIGNAL_HANDLING=1 -DDIAGNOSIS_ADDRESS=0x10 .. ->reports error