Hi Andreas, > since there are no responses so far I wonder how to proceed with the > package.
Yes, that's one of the bugs that has been on my list for a while as well... > I need to admit I get a different error when trying to build > the current state of gubbins packaging Git: > > gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -I../tests > -pthread -g -O2 -fdebug-prefix-map=/build/gubbins-2.1.0=. > -fstack-protector-strong -Wformat -Werror=format-security -c -o > ../tests/run_all_tests-run_all_tests.o `test -f '../tests/run_all_tests.c' || > echo './'`../tests/run_all_tests.c > /bin/bash ../libtool --tag=CC --mode=link gcc -I../tests -pthread -g -O2 > -fdebug-prefix-map=/build/gubbins-2.1.0=. -fstack-protector-strong -Wformat > -Werror=format-security -Wl,-z,relro -Wl,-z,now -o run_all_tests > ../tests/run_all_tests-check_branch_sequences.o > ../tests/run_all_tests-check_gubbins.o > ../tests/run_all_tests-check_parse_phylip.o > ../tests/run_all_tests-check_snp_searching.o > ../tests/run_all_tests-check_snp_sites.o > ../tests/run_all_tests-check_vcf_parsing.o > ../tests/run_all_tests-helper_methods.o > ../tests/run_all_tests-run_all_tests.o -lcheck libgubbins.la -lz -lm -lrt > -lsubunit > libtool: link: gcc -I../tests -pthread -g -O2 > -fdebug-prefix-map=/build/gubbins-2.1.0=. -fstack-protector-strong -Wformat > -Werror=format-security -Wl,-z -Wl,relro -Wl,-z -Wl,now -o > .libs/run_all_tests ../tests/run_all_tests-check_branch_sequences.o > ../tests/run_all_tests-check_gubbins.o > ../tests/run_all_tests-check_parse_phylip.o > ../tests/run_all_tests-check_snp_searching.o > ../tests/run_all_tests-check_snp_sites.o > ../tests/run_all_tests-check_vcf_parsing.o > ../tests/run_all_tests-helper_methods.o > ../tests/run_all_tests-run_all_tests.o -lcheck ./.libs/libgubbins.so -lz -lm > -lrt -lsubunit -pthread > /usr/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check.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: > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_error.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: > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_msg.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: > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_pack.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: > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_run.o): > relocation R_X86_64_32 against undefined symbol `error_jmp_buffer' can not > be used when making a shared object; recompile with -fPIC > /usr/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_str.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: > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_log.o): > relocation R_X86_64_32S against `.rodata' can not be used when making a > shared object; recompile with -fPIC > /usr/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_print.o): > relocation R_X86_64_32S against `.rodata' 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 > Makefile:742: recipe for target 'run_all_tests' failed > make[4]: *** [run_all_tests] Error 1 This looks like a completely different issue altogether I have never seen, for me it was always failing tests. I can take a look at gubbins later and try to figure them out. I had a first idea of how to address the one reported in this bug here, but I couldn't reproduce it, instead hitting a different test failure (consistently) which upstream said I could ignore. I can do the following: - first try to reproduce your issue and address it - disable the test that upstream says shouldn't be a dealbreaker - try to reproduce and work on the test failure that this bug is concerned about However, my weekend is quite full already, so if I hit a wall with one of them, I'm not sure of how much time I can dedicate. Any help would be appreciated! Cheers Sascha
