Bug#1018924: libgc FTBFS: architecture-specific symbol handling removed
On Mon, Sep 05, 2022 at 08:13:49AM +0200, Helmut Grohne wrote: > To make your (and my) life easier, I suggest that you use modern symbol > features (man deb-src-symbols). In particular, you can restrict symbols > to 32bit or 64bit using "(arch-bits=32)symbol..." and you can use C++ > symbol mangling using "(c++)unmangled...". I think I'd like to investigate that for the C++ library when this is resolved. > I happen to not understand which symbols are internal and which are not. > I really cannot tell. I'm more than happy if those really are unused. >> My opinion this should not lead to incorrect dependencies on libgc >> but how could we figure it out practically. If it would turn out >> later that some of dropped symbols are nonetheless in use, then I >> think it would not be complicated to fix it on the libgc side. This was our original discussion with the C library. I think it is still valid. > If you look into the differences, it's not just C++ symbols that have > been dropped. Here is a list of dropped symbols: This was per the discussion above. > Also note the (arch-bits=...) handling for C++ mangled symbols. I > suspect that putting this back fixes the FTBFS already. I've had a close look and I belive https://salsa.debian.org/debian/libgc/-/merge_requests/9 fixes these. > > > * debian/changelog says that you removed libatomic_ops > > >handling, but for every new architecture libatomic_ops is still > > >opted in leading to unnecessary porting work even though built-in > > >atomics generally work well. > That and the handling in debian/rules. In particular, the handling of > ATOMIC_BUILTIN_ARCHS is relevant to porting. Essentially, we'd want that > to be opt-out rather than opt-in. Basically every new architecture has > to add itself there, which seems useless busywork. I agree with this; the idea was to have this as a build-dep and opt-in these platforms, but I can see that we are better off just dropping it. https://salsa.debian.org/debian/libgc/-/merge_requests/10 proposes this. I would appreciate another set of eyes on that one just to double check it (and the other bits, but this one in particular). We can upload from the master branch then. -i
Bug#1018924: libgc FTBFS: architecture-specific symbol handling removed
Hi Ivan, On Mon, Sep 05, 2022 at 12:17:10AM +0300, Ivan Maidanski wrote: > Let me go thru all items you warry about. Please be sure both Ian and I pay > attention to the quality of the prepared releases. Sometimes mistakes happen > — it is essential to promptly react and think of the proper fix or workaround > in such situations. Thank you. I concur. Please upload a fixed version quickly. This currently breaks half of the bootstrap ci jobs, which makes me blind to breakage in other packages. Urgency is needed here. > The builds fail because of a change in some mangled names — probably the > reason is changing of noexcept/throw() specification in operator delete > (libgc tries to follow C++ standard but if this breaks some ABI, it could be > configured at build time thru macros). I need more time to check the > situation deeper. That would sound reasonable if the upload had been done to experimental. The combination of urgency and "need more time" is unfortunate. I fear that doing it improperly would be making it worse as symbol issues can have a rippling effect. Admittedly all missing symbols on the most recent upload seem to be C++ symbols. That much is plausible at least. To make your (and my) life easier, I suggest that you use modern symbol features (man deb-src-symbols). In particular, you can restrict symbols to 32bit or 64bit using "(arch-bits=32)symbol..." and you can use C++ symbol mangling using "(c++)unmangled...". > > its symbol handling is essentially stripped of all the > >architecture-specific patterns that we have accumulated over the years > > These stripped symbols are actually «leaked» internal symbols of libgc, > additionally I am not aware of any libgc client S/W which relies on these > internal symbols. Let me know please if someone is using any of the stripped > symbols. There is no practical reason of keeping these symbols in libgc > except for a formal one. Please correct me if I am wrong. I happen to not understand which symbols are internal and which are not. I really cannot tell. I'm more than happy if those really are unused. > > * Lots of symbols were dropped from the symbols file without bumping > >soname. Possibly, this may lead to incorrect dependencies on libgc in > >downstream builds. > > Bumping soname indicates no backward compatibility. This has some negative > drawback (e.g. system should have 2 versions of libraries, client S/W does > not benefit from the new library version until client binary is rebuilt). I > avoid deletion or incompatible changes of API symbols between libgc releases. > (Unfortunately there’s an issues with a mangled name I wrote above.) I’ve > explained the situation about dropping of lots of symbols above. My opinion > this should not lead to incorrect dependencies on libgc but how could we > figure it out practically. If it would turn out later that some of dropped > symbols are nonetheless in use, then I think it would not be complicated to > fix it on the libgc side. If you look into the differences, it's not just C++ symbols that have been dropped. Here is a list of dropped symbols: < GC_FirstDLOpenedLinkMap@Base 1:7.2d < (arch=kfreebsd-amd64 kfreebsd-i386)GC_FreeBSDGetDataStart@Base 1:7.2d < (arch=sparc sparc64)GC_SysVGetDataStart@Base 1:7.2d < (arch=!nios2 !sh4)GC_acquire_mark_lock@Base 1:8.0 < (arch=!nios2 !sh4)GC_active_count@Base 1:8.0 < GC_add_ext_descriptor@Base 1:7.2d < GC_add_map_entry@Base 1:7.2d < GC_add_roots_inner@Base 1:7.2d < GC_add_smashed@Base 1:7.2d < GC_add_to_black_list_normal@Base 1:7.2d < GC_add_to_black_list_stack@Base 1:7.2d < GC_add_to_fl@Base 1:7.2d < GC_add_to_heap@Base 1:7.2d < GC_adj_bytes_allocd@Base 1:7.2d < GC_all_bottom_indices@Base 1:7.2d < GC_all_bottom_indices_end@Base 1:7.2d < GC_alloc_large@Base 1:7.2d < GC_alloc_large_and_clear@Base 1:7.2d < GC_alloc_reclaim_list@Base 1:7.2d < GC_allocate_ml@Base 1:8.0 < GC_allochblk@Base 1:7.2d < GC_allochblk_nth@Base 1:7.2d < GC_allocobj@Base 1:7.2d < GC_apply_to_all_blocks@Base 1:7.2d < GC_approx_sp@Base 1:7.2d < GC_array_kind@Base 1:7.2d < GC_array_mark_proc@Base 1:7.2d < GC_array_mark_proc_index@Base 1:7.2d < GC_avail_descr@Base 1:7.2d < GC_bl_init@Base 1:7.2d < GC_bl_init_no_interiors@Base 1:7.2d < GC_black_list_spacing@Base 1:7.2d < GC_block_empty@Base 1:7.2d < GC_block_nearly_full@Base 1:7.2d < GC_block_was_dirty@Base 1:7.2d < GC_bm_table@Base 1:7.2d < (arch=!kfreebsd-amd64 !kfreebsd-i386)GC_brief_async_signal_safe_sleep@Base 1:7.6.4 < GC_build_fl2@Base 1:7.2d < GC_build_fl4@Base 1:7.2d < GC_build_fl@Base 1:7.2d < GC_build_fl_clear2@Base 1:7.2d < GC_build_fl_clear4@Base 1:7.2d < (arch=!nios2 !sh4)GC_bytes_allocd_tmp@Base 1:8.0 < GC_bytes_found@Base 1:7.2d < GC_check_annotated_obj@Base 1:7.2d < GC_check_finalizer_nested@Base 1:7.2d < GC_check_heap@Base 1:7.2d < GC_check_heap_block@Base 1:7.2d < GC_check_heap_proc@Base 1:7.2d < GC_check_leaked@Base 1:7.2d < GC_clear_a_few_f
Bug#1018924: libgc FTBFS: architecture-specific symbol handling removed
Source: libgc Version: 1:8.2.2-1 Severity: serious Tags: ftbfs Hi, what happend to libgc? It ftbfs on all 32bit architectures and its symbol handling is essentially stripped of all the architecture-specific patterns that we have accumulated over the years. The general quality of the upload seems questionable as well: * A possibly breaking change for a core package is often done to experimental first to reduce disruption of development on unstable. Doing so would have prevented major pain here. * The debian/changelog entry contains duplicates. * Lots of symbols were dropped from the symbols file without bumping soname. Possibly, this may lead to incorrect dependencies on libgc in downstream builds. * debian/changelog says that you removed libatomic_ops handling, but for every new architecture libatomic_ops is still opted in leading to unnecessary porting work even though built-in atomics generally work well. I am also wondering whether this actually is a package hijack as there is no visible acknowledgement from any existing maintainers to adding Ian to uploaders. I am quite disappointed by this upload and the downstream pain it causes to QA. Helmut
