[FFmpeg-devel] Added require fallback for libmfx in the case that pkg-config cannot find libmfx

[Clément Bœsch]

On Fri, May 05, 2017 at 12:11:27AM -0700, Aaron Levinson wrote:
> On 4/19/2017 10:43 AM, Aaron Levinson wrote:
> > On 4/14/2017 6:51 PM, Aaron Levinson wrote:
> >> From e0c73c054add0137901d0bf7a7893e42e7e566c8 Mon Sep 17 00:00:00 2001
> >> From: Aaron Levinson <alevinsn at aracnet.com>
> >> Date: Fri, 14 Apr 2017 18:38:37 -0700
> >> Subject: [PATCH] Added require fallback for libmfx in the case that
> >>  pkg-config cannot find libmfx
> >>
> >> Purpose: Added require fallback for libmfx in the case that pkg-config
> >> cannot find libmfx.  On Linux, most people likely get libmfx via
> >> https://github.com/lu-zero/mfx_dispatch , but on Windows, the most
> >> well-known way to get libmfx is via the Intel Media SDK, which
> >> provides a static build of libmfx.lib and also provides the source
> >> code for building libmfx yourself.  If built this way, there are no
> >> pkg-config files to be found.  The changes utilize a similar approach
> >> to that already done for libx264 in configure.
> >>
> >> Comments:
> >>
> >> -- configure: Altered enabled libmfx step to use use_pkg_config()
> >>    instead of require_pkg_config(), and, if use_pkg_config() fails, it
> >>    falls back to require().  Note that the reason that require() is
> >>    passed -llibmfx as the last argument, instead of -lmfx, is the file
> >>    name for the library produced from the Intel Media SDK starts with
> >>    "libmfx".  Apparently, the filename for the library produced via
> >>    https://github.com/lu-zero/mfx_dispatch starts with "mfx".
> >> ---
> >>  configure | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/configure b/configure
> >> index 3bea057..b20a0b4 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -5819,7 +5819,8 @@ enabled libgsm            && { for gsm_hdr in
> >> "gsm.h" "gsm/gsm.h"; do
> >>                                 done || die "ERROR: libgsm not found"; }
> >>  enabled libilbc           && require libilbc ilbc.h
> >> WebRtcIlbcfix_InitDecode -lilbc
> >>  enabled libkvazaar        && require_pkg_config "kvazaar >= 0.8.1"
> >> kvazaar.h kvz_api_get
> >> -enabled libmfx            && require_pkg_config libmfx
> >> "mfx/mfxvideo.h" MFXInit
> >> +enabled libmfx            && { use_pkg_config libmfx "mfx/mfxvideo.h"
> >> MFXInit ||
> >> +                               { require libmfx "mfx/mfxvideo.h"
> >> MFXInit -llibmfx && warn "using libmfx without pkg-config"; } }
> >>  enabled libmodplug        && require_pkg_config libmodplug
> >> libmodplug/modplug.h ModPlug_Load
> >>  enabled libmp3lame        && require "libmp3lame >= 3.98.3"
> >> lame/lame.h lame_set_VBR_quality -lmp3lame
> >>  enabled libnut            && require libnut libnut.h nut_demuxer_init
> >> -lnut
> >>
> > 
> > Pinging this patch submission again.
> > 
> > Thanks,
> > Aaron Levinson
> 
> And again.  This patch is pretty straightforward, and considering that this approach was deemed suitable for libx264

It wasn't, Carl Eugen insisted in doing this against everyone opinion, but
we tolerated his whim because he didn't want to use or install a 80kB
package installed on virtually every system that supports x264.

Anyway, here is a nasty side effect of doing this: you use PKG_CONFIG_PATH
to make sure it's linking against a specific local build of your lib, but
you did it wrong and it ends up linking silently against the system one
instead of failing like you would like to.

We predicted that allowing this hack for x264 was going to bring up
patches like this and we were right.

So maybe we should actually drop the hack for libx264.

Back to your issue: you should fix the .pc in the upstream project, this
is the correct fix.

Regards,

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170505/28359403/attachment.sig>