Prioritize 'sdl2-config'-check over 'check_pkg_config sdl2'-check.

[CoRoNe]

When cross-compiling SDL2 it by default produces a pkg-config source file with the following library-list:

Libs: -L${libdir}  -lmingw32 -lSDL2main -lSDL2

For building FFPlay (for Windows) it needs at least:

Libs: -L${libdir}  -lmingw32 -lSDL2main -lSDL2 -limm32 -lole32 -loleaut32 -lversion

However, there's already 'sdl2-config' with all the libraries setup right, but FFMpeg's 'configure' ​gives priority to 'check_pkg_config sdl2' at the moment, and thus fails when the libraries aren't setup right for FFPlay to be built.

I suggest turning the if-statement around; prioritizing the 'sdl2-config'-check:

disabled sdl && disable sdl2
if ! disabled sdl2; then
   SDL2_CONFIG="${cross_prefix}sdl2-config"
   if "${SDL2_CONFIG}" --version > /dev/null 2>&1; then
       sdl2_cflags=$("${SDL2_CONFIG}" --cflags)
       sdl2_extralibs=$("${SDL2_CONFIG}" --libs)
       check_cpp_condition SDL.h "(SDL_MAJOR_VERSION<<16 | SDL_MINOR_VERSION<<8 | SDL_PATCHLEVEL) >= 0x020001" $sdl2_cflags &&
       check_cpp_condition SDL.h "(SDL_MAJOR_VERSION<<16 | SDL_MINOR_VERSION<<8 | SDL_PATCHLEVEL) < 0x020100" $sdl2_cflags &&
       check_func SDL_Init $sdl2_extralibs $sdl2_cflags && enable sdl2
   else
     if check_pkg_config sdl2 SDL_events.h SDL_PollEvent; then
       check_cpp_condition SDL.h "(SDL_MAJOR_VERSION<<16 | SDL_MINOR_VERSION<<8 | SDL_PATCHLEVEL) >= 0x020001" $sdl2_cflags &&
       check_cpp_condition SDL.h "(SDL_MAJOR_VERSION<<16 | SDL_MINOR_VERSION<<8 | SDL_PATCHLEVEL) < 0x020100" $sdl2_cflags &&
       check_func SDL_Init $sdl2_extralibs $sdl2_cflags && enable sdl2
     fi
   fi
   if test $target_os = "mingw32"; then
       sdl2_extralibs="$sdl2_extralibs -mconsole"
   fi
fi
enabled sdl2 && enable sdl && add_cflags $sdl2_cflags && add_extralibs $sdl2_extralibs

I've successfully built FFPlay this way, and thus without having to patch 'sdl2.pc'.

[Hendrik]

I would recommend you notify the SDL2 project that their pkg-config file is inadequate.

[CoRoNe]

Inadequate for building FFPlay, yes. But perhaps not for other software.
Are there any downsides to my proposition?

[Carl Eugen Hoyos]

Please send your patch made with git format-patch to the development mailing list.

[CoRoNe]

Patch sent 34h ago, but haven't had a reply yet.

[Cigaes]

Do you see your patch on the archive:
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-May/date.html
?

[CoRoNe]

I was monitoring ​https://patchwork.ffmpeg.org/project/ffmpeg/list/. But there I can't see my patch either.
What's the difference between the two?

[Cigaes]

One is the full archive, the other is a tracker of the patches posted on the mailing-list. I see your patch on neither. You probably did not send it correctly.

The most likely reason is to have posted without having subscribed to the list. The merits of the patch will be discussed there.

[CoRoNe]

Is that a prerequisite then? I'm not a diehard coder like you guys, so I don't feel the need to subscribe actually.
Oh... https://ffmpeg.org/developer.html#patch-submission-checklist, I see now.

Success: ​https://patchwork.ffmpeg.org/patch/3647/

[CoRoNe]

The '--pkg-config-flags="--static"' as suggested by Stephen Hutchinson works very well.
Someone can close this ticket.