[FFmpeg-devel] [PATCH] configure: Add option to use gmp

[Ricardo Constantino]

I previously had an option for gcrypt too but it seemed to not work (FFmpeg
crashed, iirc), so I just gave up on it.

On 18 November 2015 at 05:41, Matt Oliver <protogonoi at gmail.com> wrote:

> On 15 November 2015 at 01:09, Ricardo Constantino <wiiaboo at gmail.com>
> wrote:
>
>> Enables RTMP(T)E support with SChannel
>>
>> (Not sure if this is the right way to enable this)
>>
>> Signed-off-by: Ricardo Constantino <wiiaboo at gmail.com>
>> ---
>>  configure | 6 +++++-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index 9a736ce..6c658f2 100755
>> --- a/configure
>> +++ b/configure
>> @@ -199,6 +199,8 @@ External library support:
>>    --enable-chromaprint     enable audio fingerprinting with chromaprint
>> [no]
>>    --enable-fontconfig      enable fontconfig, useful for drawtext filter
>> [no]
>>    --enable-frei0r          enable frei0r video filtering [no]
>> +  --enable-gmp             enable gmp, needed for rtmp(t)e support
>> +                           with SChannel [no]
>>    --enable-gnutls          enable gnutls, needed for https support
>>                             if openssl is not used [no]
>>    --disable-iconv          disable iconv [autodetect]
>> @@ -1395,6 +1397,7 @@ EXTERNAL_LIBRARY_LIST="
>>      crystalhd
>>      decklink
>>      frei0r
>> +    gmp
>>      gnutls
>>      iconv
>>      ladspa
>> @@ -1946,7 +1949,6 @@ CONFIG_EXTRA="
>>      frame_thread_encoder
>>      g722dsp
>>      gcrypt
>> -    gmp
>>      golomb
>>      gplv3
>>      h263dsp
>> @@ -4759,6 +4761,7 @@ die_license_disabled nonfree nvenc
>>  enabled gpl && die_license_disabled_gpl nonfree libfdk_aac
>>  enabled gpl && die_license_disabled_gpl nonfree openssl
>>
>> +die_license_disabled version3 gmp
>>  die_license_disabled version3 libopencore_amrnb
>>  die_license_disabled version3 libopencore_amrwb
>>  die_license_disabled version3 libsmbclient
>> @@ -5325,6 +5328,7 @@ enabled avisynth          && { { check_lib2
>> "windows.h" LoadLibrary; } ||
>>  enabled chromaprint       && require chromaprint chromaprint.h
>> chromaprint_get_version -lchromaprint
>>  enabled decklink          && { check_header DeckLinkAPI.h || die "ERROR:
>> DeckLinkAPI.h header not found"; }
>>  enabled frei0r            && { check_header frei0r.h || die "ERROR:
>> frei0r.h header not found"; }
>> +enabled gmp               && require2 gmp gmp.h mpz_export -lgmp
>>  enabled gnutls            && require_pkg_config gnutls gnutls/gnutls.h
>> gnutls_global_init
>>  enabled ladspa            && { check_header ladspa.h || die "ERROR:
>> ladspa.h header not found"; }
>>  enabled libiec61883       && require libiec61883 libiec61883/iec61883.h
>> iec61883_cmp_connect -lraw1394 -lavc1394 -lrom1394 -liec61883
>> --
>> 2.6.3
>>
>
> The Diffie-Hellmann code can be compiled using either gmp or gcrypt so
> command line options to enable either of those should probably be provided.
>
> However currently configure seems to auto check and enable both gmp and
> gcrypt if gnutls is enabled (line 5476) with no user visible option to
> disable this behavior (or atleast to select which of the external libs
> should be used). Currently if both dependencies are available then both
> will be automatically linked despite only 1 being used and this behavior
> doesnt appear to be visible to the user so it seems a bit hacky to me. It
> also appears to be just plain wrong as gmp is used by default over gcrypt
> despite gmp being LGPL v3 (gcrypt and gnutls are v2.1) and it is not
> checking if version 3 is enabled. So currently a v3 lib is being stealth
> linked without version3 being enabled or any user input/output.
>
> If the existing method is to be used then the same thing will have to be
> done to enable either gmp or gcrypt if schannel is enabled aswell with the
> additiotn of a version check. However I think that making user visible
> options to select the use of either gmp or gcrypt is probably the better
> option which would mean the removal of the existing automatic enabling if
> gcrypt is used. This may result in changed behavior though for people
> compiling the lib that just assume previous behavior and so would need a
> version bump.
>
> Once people provide feedback on which option is preferable then ill write
> up a patch.
>
>
>