[FFmpeg-devel] [FFmpeg-cvslog] Merge commit '7cb1d9e2dbbe5bf4652be5d78cdd68e956fa3d63'

[Jörn Heusipp]

Hello

On 10/14/2017 01:32 AM, James Almer wrote:
> On 10/13/2017 6:30 PM, Reino Wijnsma wrote:
>> On 13-10-2017 18:48, James Almer <jamrial at gmail.com> wrote:
>>> Are "-lshlwapi -lpthread -lcrypt32"
>>> extralibs you added manually, or were they derived from dependencies
>>> like libmpg123, vorbis, etc by pkg-config?
>> My configure line up until now with the manually added extra-libs:
>>
>> # ./configure --arch=x86 --target-os=mingw32
>> --cross-prefix=/cygdrive/m/ffmpeg-windows-build-helpers-master/native_build/windows/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-
>> --pkg-config=pkg-config --pkg-config-flags=--static
>> --extra-version=Reino --enable-gray --enable-version3 --disable-debug
>> --disable-doc --disable-htmlpages --disable-manpages --disable-podpages
>> --disable-schannel --disable-txtpages --disable-w32threads
>> --enable-avisynth --enable-avresample --enable-fontconfig
>> --enable-frei0r --enable-filter=frei0r --enable-gmp --enable-gnutls
>> *--extra-libs=-lcrypt32* --enable-gpl --enable-libass --enable-libbluray
>> --enable-libbs2b --enable-libcaca --extra-cflags=-DCACA_STATIC
>> --enable-libfdk-aac --enable-libflite --enable-libfreetype
>> --enable-libfribidi --enable-libgme --enable-libgsm --enable-libilbc
>> *--extra-libs=-lpthread* --enable-libmp3lame --enable-libmysofa
>> --enable-libopencore-amrnb --enable-libopencore-amrwb
>> --enable-libopenh264 --enable-libopenmpt *--extra-libs=-lshlwapi*
>> --enable-libopus --enable-librubberband --enable-libsnappy
>> --enable-libsoxr --enable-libspeex --enable-libtheora
>> --enable-libtwolame --extra-cflags=-DLIBTWOLAME_STATIC
>> --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis
>> --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265
>> --enable-libxavs --enable-libxml2 --enable-libxvid --enable-libzimg
>> --enable-libzvbi --extra-cflags='-march=pentium3' --extra-cflags=-O2
>> --extra-cflags='-mfpmath=sse' --extra-cflags=-msse --enable-static
>> --disable-shared
>> --prefix=/cygdrive/m/ffmpeg-windows-build-helpers-master/native_build/windows/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32
>>
>>> See if adding -lstdc++ fixes it.
>> It does.
> 
> Ok, fixing this way then.
> 
> Consider reporting this bug to libopenmpt, while at it. They should add
> -lstdc++ to their pkg-config file for static builds, instead of projects
> using the library having to workaround it.

I'm the libopenmpt maintainer.

The problem is not solved by adding a hard-coded -lstdc++ to pkg-config 
Libs.private. This would only be correct if the C++ standard library is 
actually called "libstdc++" on the given platform. In particular, it is 
not called libstdc++ on FreeBSD and macOS (where LLVM libc++ is used by 
default) and libstdc++ might be available additionally. Android is even 
worse with its many available C++ standard libraries.
Sadly, I am not aware of an easy and fail-proof way to detect the name 
of the C++ standard library from within the build system. As far as I 
know (please correct me if I am wrong), there is no gcc or clang option 
to actually return it (which could be used in an Autoconf check). For 
clang, it can even be chosen by the user when building by specifying 
appropriate CXXFLAGS (-stdlib=[libstdc++|libc++]).

The problem is fundamentally inherent to statically linking libraries 
implemented in C++ with pkg-config. "Libs.private: -lstdc++" would fix 
the default Linux setup with GCC (and cross-compiling with MinGW), but 
would break FreeBSD and macOS. I'd rather prefer to not handle that and 
leave it up to the user who builds (the user knows which build 
system/target/platform system is used and can thus add the required C++ 
standard library when using static linking (or use the C++ compiler 
instead of the linker for linking everything, however this implies using 
a C++ compiler for libraries that themselves do not actually use C++ in 
the first place)). I am fully aware that this is not a perfect solution, 
but frankly, I do not think there is one available with the current 
infrastructure situation.

There was also a discussion on the pkg-config mailing list not too long 
ago which further goes into details about the issue (talking about a 
different library, but it applies equally well to the ffmpeg / 
libopenmpt situation):
> https://lists.freedesktop.org/archives/pkg-config/2016-August/001055.html


Regard,
Jörn