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
