l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver <m...@netris.org> skribis:
>
>> FYI, I investigated the problem with gst-libav on x86_64, and it turns
>> out that it began when we updated nettle from 2.7 to 3.1, the latter of
>> which is configured with --enable-fat. For details, see my post on
>> bug-nettle:
>>
>> http://lists.lysator.liu.se/pipermail/nettle-bugs/2015/003389.html
>
> Interesting, thanks for investigating. Followup at
> <https://sourceware.org/ml/libc-help/2015-06/msg00010.html>.
>
>> We could work around the problem by removing the --enable-fat configure
>> option, although it will entail a lot of rebuilding. While we're at it,
>> we should also update to nettle-3.1.1.
>
> If we don’t use --enable-fat, then we get non portable binaries,
> don’t we?
Maybe it's not enough to simply remove --enable-fat, but presumably
there's a way to compile a non-fat nettle that targets a machine with
the minimum set of required features for a given target.
Anyway, a better option would be to simply disable the IFUNC method of
initializing nettle.
> Would it work to use nettle-2.7 for instance for gst-libav?
No, nettle is getting linked into gst-libav via several levels of
indirection. One way is via the path:
gst-libav -> ffmpeg -> libquvi -> curl -> gnutls -> nettle
Maybe there are other paths as well, I don't know. Anyway, if we were
to introduce nettle-2.7 back into the mix, then we'd surely end up with
two different versions of nettle being linked into the same program,
which caused problems for us some time ago as I recall.
Mark
