Bug#956136: Some investigations about bug (956136) nanopolish: FTBFS (undefined references)
Control: tags -1 pending Control: reassign -1 minimap2 Control: retitle -1 "-flto flag breaks nanopolish" Hamid, thanks a lot for your investigation. Kind regards, Andreas. -- http://fam-tille.de
Processed: Re: Bug#956136: Some investigations about bug (956136) nanopolish: FTBFS (undefined references)
Processing control commands: > tags -1 pending Bug #956136 [src:nanopolish] nanopolish: FTBFS (undefined references) Added tag(s) pending. > reassign -1 minimap2 Bug #956136 [src:nanopolish] nanopolish: FTBFS (undefined references) Bug reassigned from package 'src:nanopolish' to 'minimap2'. No longer marked as found in versions nanopolish/0.12.1-1. Ignoring request to alter fixed versions of bug #956136 to the same values previously set > retitle -1 "-flto flag breaks nanopolish" Bug #956136 [minimap2] nanopolish: FTBFS (undefined references) Changed Bug title to '"-flto flag breaks nanopolish"' from 'nanopolish: FTBFS (undefined references)'. -- 956136: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956136 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#956136: Some investigations about bug (956136) nanopolish: FTBFS (undefined references)
Hi all, I could find the cause. It is the `-flto` in the compile and link flags of the libminimap2-dev package. LTO is introduced recently in the following commit on the [1]: 53883a7ff8c066c14c0ea4e42299ae9958feda6a Removing `-flto` from CFLAGS and LDFLAGS, then building libminimap2-dev with pdebuild (sid), then building the nanopolish with pbuilder (sid), will succeed. I attached the patch which resolves the problem. It should be applied against [1]. The conclusion: The `-flto` behaves differently from the past maybe with the recent changes in the build tool-chain (maybe in GCC) and causes the problem. [1]:https://salsa.debian.org/med-team/minimap2.git Bests, Hamid Nassiby From 5aa0491a6159895cdb0925617858cbca68c9e834 Mon Sep 17 00:00:00 2001 From: Hamid Nassiby Date: Thu, 9 Apr 2020 23:01:48 +0430 Subject: [PATCH] Remove -flto flag --- debian/patches/addLTO.patch | 30 -- debian/patches/series | 1 - 2 files changed, 31 deletions(-) delete mode 100644 debian/patches/addLTO.patch diff --git a/debian/patches/addLTO.patch b/debian/patches/addLTO.patch deleted file mode 100644 index 8dc0215..000 --- a/debian/patches/addLTO.patch +++ /dev/null @@ -1,30 +0,0 @@ -Author: Steffen Moeller -Last-Update: 2020-03-14 23:04:54 +0100 -Description: Add -flto flag - -Index: minimap2/Makefile -=== minimap2.orig/Makefile -+++ minimap2/Makefile -@@ -1,10 +1,11 @@ --CFLAGS+= -g -Wall -O2 -Wc++-compat #-Wextra -+CFLAGS+= -g -Wall -O2 -Wc++-compat -flto #-Wextra - CPPFLAGS+= -DHAVE_KALLOC - INCLUDES= - OBJS= kthread.o kalloc.o misc.o bseq.o sketch.o sdust.o options.o index.o chain.o align.o hit.o map.o format.o pe.o esterr.o splitidx.o ksw2_ll_sse.o - PROG= minimap2 - PROG_EXTRA= sdust minimap2-lite - LIBS= -lm -lz -lpthread -+LDFLAGS+= -flto - - OBJS+=ksw2_extz2_sse.o ksw2_extd2_sse.o ksw2_exts2_sse.o - -@@ -29,7 +30,7 @@ all:$(PROG) - extra:all $(PROG_EXTRA) - - minimap2:main.o libminimap2.a -- $(CC) $(CFLAGS) main.o -o $@ -L. -lminimap2 $(LIBS) $(LDFLAGS) -+ $(CC) main.o -o $@ -L. -lminimap2 $(LIBS) $(LDFLAGS) - - minimap2-lite:example.o libminimap2.a - $(CC) $(CFLAGS) $< -o $@ -L. -lminimap2 $(LIBS) $(LDFLAGS) diff --git a/debian/patches/series b/debian/patches/series index 57c6966..65c2533 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1,5 +1,4 @@ hardening.patch do_not_use_natbib.bst.patch simde -addLTO.patch ar.patch -- 2.25.0
Bug#956136: Some investigations about bug (956136) nanopolish: FTBFS (undefined references)
Control: tags -1 help Hi all, The undefined reference to those functions, means that there is a problem in linking with libminimap2 which implements them. Those functions are implemented in map.c of that library. I am able to reproduce the bug with pbuilder (sid) on the buster. I made some investigations: The size of the latest snapshot of libminimap2-dev package is far smaller than its predecessors which could be found in [1]. The latest snapshot (dfsg-7) is around 23 KB, but its direct predecessor (dfsg-6) is 1.4 MB. I extracted 2 latest snapshots and examined the contents of libminimap2.a and specially map.o which should define those functions. I run the `nm --demangle map.o` and the result is: On the latest snapshot (dfsg-7): nm: map.o: no symbols On its predecessor (dfsg-6): U __assert_fail U cputime U fclose U kfree U kmalloc U km_destroy U km_init U km_stat T ks_heapdown_heap T ks_heapmake_heap T ks_ksmall_heap U kt_for U kt_pipeline U mm_align_skeleton U mm_bseq_close U mm_bseq_open U mm_bseq_read3 U mm_bseq_read_frag2 U mm_chain_dp U mm_dbg_flag U mm_err_fread U mm_err_fwrite U mm_err_puts U mm_est_err U mm_gen_regs U mm_hit_sort U mm_idx_destroy U mm_idx_get U mm_join_long T mm_map T mm_map_file T mm_map_file_frag T mm_map_frag U mm_pair U mm_realtime0 U mm_seg_free U mm_seg_gen U mm_select_sub U mm_select_sub_multi U mm_set_mapq U mm_set_parent U mm_set_sam_pri U mm_sketch U mm_split_init T mm_split_merge U mm_split_merge_prep U mm_split_rm_tmp T mm_tbuf_destroy T mm_tbuf_get_km T mm_tbuf_init U mm_verbose U mm_write_paf3 U mm_write_sam3 U radix_sort_128x U realtime U sdust_buf_destroy U sdust_buf_init U sdust_core U seq_comp_table U stderr We see that dfsg-6 exports required functions, but dfsg-7 not! Thus I concluded that there is a problem with the dfsg-7 build. So I downloaded the dfsg-7 source code and built it with pbuilder (sid) and the built package was the same 23 KB size and the problem was the same (no function is exported). Then I downloaded dfsg-6 source and built it with pbuilder (sid) and WOW! The size became 23 KB, while the snapshot size is 1.4MB on [1]! And now the functions are not exported while were exported on the snapshot on [1]. Then I built both sources (dfsg-6 and dfsg-7) on buster with debuild successfully and both have the size 1.4MB and both contents are OK and export required function symbols. The conclusion: IMHO the problem is with the build tool-chain which results in such a difference in the size of the built package, in comparison with previous snapshots from the same source, which does not provide required functions in the built minimap2 library. But I may have missed something. So I would like to ask kindly for any suggestion which may provide a better resolution to the bug. Please CC me in any response since I am not subscribed to the list. [1]: https://snapshot.debian.org/package/minimap2/ Best Regards, Hamid Nassiby
