On Tue, Mar 31, 2020 at 9:41 AM Niels Möller <[email protected]> wrote: > > Nikos Mavrogiannopoulos <[email protected]> writes: > > > On Mon, Mar 30, 2020 at 1:23 PM Niels Möller <[email protected]> wrote: > >> > >> The error is > >> > >> 1217 ./bootstrap: getting translations into po/.reference for gnutls... > >> 1218 wget: /lib64/libhogweed.so.5: version `HOGWEED_INTERNAL_5_0' not > >> found (required by /lib64/libgnutls.so.30) > >> 1219 wget: /lib64/libnettle.so.7: version `NETTLE_INTERNAL_7_0' not found > >> (required by /lib64/libgnutls.so.30) > >> > >> I don't quite understand all details. This job buils and installs > >> nettle, as > >> > >> ./configure --disable-documentation --prefix=/usr --libdir=/usr/lib64 && > >> make -j4 && make install > > > > That works well as long as binary compatibility is kept. As nettle > > breaks it, applications in the system will be unable to run. > > But advertised binary compatibility between Nettle releases considers > only the symbols related to the public api, not the symbols with > *INTERNAL* as version. When gnutls refers to internal symbols, there's > no binary compatibility at all between nettle versions. > > I would strongly recommend that the default configuration of gnutls > don't refer to internal nettle symbols. And any packaging of a version > with a non-default configuration enabling use of nettle internals (e.g, > to support more gost curves) needs to depend on a particular version of > nettle, rather than on the soname, which only captures binary > compatibility of the public ABI.
That is not possible as we are introducing features into gnutls in a faster pace than they are introduced in nettle (e.g., x448 or gost). Without a predictable cadence of nettle releases we have to duplicate and bundle a lot of code into gnutls because it is unknown when the next nettle release will be. The options we have considered were bundling nettle into gnutls or backporting selected features even when depending on nettle's ABI. The latter is the approach we currently take as it still keeps separation between the projects. The main problem lies however with the unpredictability and long delay of nettle's releases. If that could be addressed it would solve the dependency issue as well. regards, Nikos _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
