On 04/18/2017 11:01 PM, Andreas Tille wrote: > x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/build/psortb-3.0.4+dfsg=. > -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro > -shared -L/usr/local/lib -fstack-protector-strong HMM.o hmm-binding.o -o > ../blib/arch/auto/Algorithm/HMM/HMM.so \ > -lm -lpthread -lstdc++ -L/usr/local/lib -lhmmer -lsquid \ > > /usr/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libhmmer.a(alphabet.o): > relocation R_X86_64_PC32 against symbol `Alphabet' 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 > ... > > which is probably due to the fact that I did not changed hmmer2 to > create a shared rather than a static library and lhmmer is not compiled > with -fPIC. What might be the less stressful way to solve this? I > think the optimal solution would be to craft configure.ac and > Makefile.am for hmmer2 (which only ships configure and Makefile.in) and > by doing so create a shared library. However, I do not consider this > as a very fruitful way to spent someones time on orphaned software so > a cheaper solution would be welcome.
Well, you could compile the static library with -fPIC anyway. Linking a static library into a shared library is not a problem in and by itself (the code will be copied into the shared library just like it would be copied into an executable), the only problem here is the missing -fPIC. So if you shoe-horn -fPIC into the compiler flags of the static library, linking that into a dynamic library later should work. (That said: I'm not a huge fan of this approach, Debian prefers to use shared libraries for a reason. OTOH, if I understand you correctly your second pacakge is the only reverse dependency, so it's not that big of a deal in this case.) Regards, Christian
