Linker error when compiling on linux

Up to date arch linux with of_0.9.3, getting linker errors when compiling projects:

'/usr/bin/ld: /home/user/Development/of_v0.9.3_linux64_release/libs/kiss/lib/linux64/libkiss.a(kiss_fftr.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /home/user/Development/of_v0.9.3_linux64_release/libs/tess2/lib/linux64/libtess2.a(tess.o): relocation R_X86_64_32 against `.data' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /home/user/Development/of_v0.9.3_linux64_release/libs/tess2/lib/linux64/libtess2.a(mesh.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/user/Development/of_v0.9.3_linux64_release/libs/tess2/lib/linux64/libtess2.a(sweep.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /home/user/Development/of_v0.9.3_linux64_release/libs/tess2/lib/linux64/libtess2.a(dict.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC

Seems to have come out of the blue, didn’t happen just some days ago, but haven’t done any big changes in the system. Had a really similar problem some months back, but solved it after doing a complete reinstall of the system. Don’t want to do that again…

Any takers? I tried adding CFLAGS += -fPIC to, but to no avail. Is it possible/correct to recompile the libs with -fPIC using apothecary? Or recompile so the linker finds the position (the P in PIC, I guess) correctly?

Reading material:

1 Like

yes, can you try adding -fPIC to those libraries (kiss and tess2) in the apothecary formulas and compiling them again

Thanks for the quick reply!

That did indeed fix it for tess2, but apothecary doesn’t seem to have a working makefile for kiss on linux64. In formulas/kiss, the has a

elif [ "$TYPE" == "linux64" ] ; then echoWarning "TODO: linux64 build

But it was a stray laying about which when moved into formulas/kiss gave the error make: *** No rule to make target 'src/kiss_fft.o', needed by 'libkiss.a'. Stop.

What do you reckon? Is there a working formula for kiss on 64-bit linux? Is this up to date? Or how should I go about writing a Makefile catering kiss_fft.o?

the latest apothecary formulas are in their own repo: there you can find the latest kiss formula: also the latest compiled libs are here: in case the settings in the latest formulas are already correct

Nice, the latest worked flawlessly!

Let me know if this is a bug and I should make a PR with-fPIC or something. On the same note: rtaudio on arch must be included as /rtaudio/RtAudio.h and not RtAudio.h. It’s fixed with a patch in AUR, but I guess it should rather be fixed in the makefile. Is this done in the lates OF, or should I push such a change too?

do you mean it worked right away or you had to add -fPIC?

about rtaudio can you check if there’s a pkg-config for rtaudio? if that’s the case

pkg-config --cflags rtaudio

or librtaudio or however the package config is called might already add /usr/include/rtaudio to the include path and we need to do use that instead

Sorry for late reply, the deadline approached so fast so didn’t have time to follow up.

But now with 0.9.8 and up to date Arch:
rtaudio from aur works out of the box
libtess2 and kiss works after running apothecary update tess2 && apothecary update kiss.

Thanks for your help yet again, arturo!

Hi can you please share how you added the -fPIC to the tess2 apothecary formula?

1 Like

Hi can youlet me know how you modified the tess2 apothecary formula?

I seem to be having this same sort of problem today, after updating my Ubuntu from 16 (where my project built just fine) to 18.04 (where kiss and tess2 suddenly say I need to “recompile with -fPIC”).

I don’t really follow any of the comments about what I actually need to do about this. Does anyone have a pointer to how to correct this?

. . . oh, wait… I probably have to re-build OpenFrameworks by re-running the steps on huh? Ok, doing that…

openframeworks 0.9.8 is not compatible anymore with latest linux versions cause the gcc version included, (6 or greater) enables some flags for security reasons that make libraries not compatible any more. you would need to recompile all the libraries by yourself.

OF 0.10.0 offers downloads for gcc4, gcc5 and gcc6 or greater

Aha! Thanks arturo! Sounds like it’s time to try OF 0.10.0 then! :slight_smile:

Ok, upgrading to OF 0.10.0 worked and my project seems to build and work fine in it.

I ran into a peculiar thing though: When I re-built 0.9.8, AND when I built 0.10.0, during the compilation (i.e. ./ -j3 ) on a 4GB-RAM, 4-core laptop, I think during compiling the same file (I think gl/ofTexture.cpp ), the computer locked completely up (mouse pointer showing but absolutely unresponsive for over an hour though grinding the hard drive for a while), but rebooting and re-running the compile script a second time succeeded.

if you compile using 3 cores with only 4Gb of RAM the compiler is probably using up the whole memory and starting to swap which makes things super slow. if you have only 4Gb then you probably want to use less cores when compiling or check that other tasks are not using up a lot of memory. Also gnome-shell uses way more memory than unity so this happens more often now.

When that happens anyway you can kill the most resource intensive task pressing Alt + PrintScreen + F. That will kill tasks in order of most resource consuming so if you are doing something you don’t want to kill don’t use it but it’s at least better than rebooting

1 Like

Well that makes great sense and is really helpful in several ways, thanks so much!

(Seems like it’s be great to add some of that info to the install notes. I had it set it three as it says, “-j3 tells the script to use 3 CPUs to compile. You can specify as many as you want but it’s recommended to use the number of cores in your computer or less.” I figured 3 would leave one to let the machine do other things, but I suppose not if they end up using all the RAM. )