Re: The reason why gst-libav is broken on x86_64

[Mark H Weaver]

address@hidden (Ludovic Courtès) writes:

> Mark H Weaver <address@hidden> 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