Hello, вс, 12 апр. 2020 г. в 20:23, Andreas Metzler <[email protected]>: > > On 2020-04-12 Niels Möller <[email protected]> wrote: > > Andreas Metzler <[email protected]> writes: > > >> According to objdump -R GnuTLS uses internal symbols of both libhogweed > >> and libnettle (e.g. _nettle_mpn_set_base256_le@HOGWEED_INTERNAL_5_0 and > >> _nettle_write_le64@NETTLE_INTERNAL_7_0). These nettle *internal* symbols > >> seem to be incompatible in 3.6, at least they are versioned differently > >> (@NETTLE_INTERNAL_7_1). > > > Can you post a complete list of the references to internal symbols? > > Hello Niels, > > I am attaching > > objdump -R path/to/so | grep INTERNAL > > for x86_64-linux-gnu gnutls builds against nettle 3.5 and 3.6 (the > latter patched to bump nettle soname, too). I am not an expert in this > area - I think this generates the correct list.
It looks correct to me. If nobody takes a step, I'm going to look on this in the next few days. > > >> Having non-working gnutls is quite a big issue, since e.g. apt depends > >> on it. > > > Indeed. What options do we have? The ones I see are > > > 1. Simply bump the soname of libnettle too. I think that's ok in this > > case, since there are no major fixes or improvements to old features > > in this release. But I wouldn't want to make it a habit. > > I agree that this "less than optimal". :-( > > > 2. Fix GnuTLS to not refer to internal libnettle symbols. Mark the > > nettle-3.6 package including libnettle.so.7 as conflicting with the > > non-fixed GnuTLS package. > > > I don't know how practical option (2) is. But for the example of > > nettle_write_le64, it would be a simple improvement to just include a > > copy in GnuTLS if it needs it. The nettle implementation is not > > particularly clever, and it's not intended to be part of the ABI. E.g, > > one todo item is to replace it with a macro expanding to memcpy, on > > platforms that are natively little-endian, in which case the symbol > > would simply disappear from the library. > > I do not know either how feasible this is but the current situation, > where GnuTLS relies on functions not part of the API, that could break > anytime *IMHO* is not feasible either. [1] > > In the medium term nettle might start enforcing saner usage > by not exporting *INTERNAL* in libraries shipped in "make install" > > cu Andreas > > [1] > (The current trigger, changing LIBNETTLE_MINOR which in turn > breaks the ABI could be undone, if the affected internal symbols were > compatible. But this does not solve the deeper problem.) > _______________________________________________ > nettle-bugs mailing list > [email protected] > http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs -- With best wishes Dmitry _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
