On Fri, 5 May 2017 09:42:51 +0200 Clément Bœsch <u...@pkh.me> wrote:
> 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 <alevi...@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. +1 > > Back to your issue: you should fix the .pc in the upstream project, this > is the correct fix. +1 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
