Platform dependent object files in the tarballs

[jwrona]

Recently I tried to create an libnf RPM packages on several distributions and on Fedora the build was failing. I noticed that in the tarballs there are already compiled and platform dependent object files (.o and .lo) in the bzip2 directory. This is generally a bad idea, because Make's incremental build will simply skip compilation of the whole bzlib2 but will link those potentially incompatible objects into the final shared library.

Why did that show up on the Fedora and only during RPM build? Because packages for the Fedora are compiled with some extra security flags by default, but those already present object files are compiled without them. Result is following error:

libtool: link: gcc -ggdb -I../include -I../nfdump/bin -I../ffilter -I../bzip2 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -DLNF_THREADS -DNSEL -Wl,-z -Wl,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o libnf-info libnf-info.o  ../src/.libs/libnf.a -lresolv -lpthread
/usr/bin/ld: ../src/.libs/libnf.a(bzlib.o): relocation R_X86_64_32S against `BZ2_crc32Table' can not be used when making a shared object; recompile with -fPIC
../src/.libs/libnf.a: error adding symbols: Bad value

What is the reason of static linking of bzlib2 anyway?

[tpoder1]

You are right. It's nonsense to have object files included in a tarrball. In the last last commit there is the quick fix to the problem. Similar problem was with object files in nfdump/bin directory.

There is no exact reason for the static linking. It's a legacy from the previous version and I'am planning to enable possibility of dynamic linking of bzlib2 either way.