On Mon, 6 Jan 2014, Luca Barbato wrote:
Should make work properly linking against static libraries dynamically linking secondary libraries. ---Apparently yet another freetype cute feat. configure | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/configure b/configure index 7c3a9f8..5846b60 100755 --- a/configure +++ b/configure @@ -918,8 +918,9 @@ check_pkg_config(){ funcs="$3" shift 3 check_cmd $pkg_config --exists --print-errors $pkg || return - pkg_cflags=$($pkg_config --cflags $pkg) - pkg_libs=$($pkg_config --libs $pkg) + enabled static && pkgconf_flags="--static" + pkg_cflags=$($pkg_config --cflags $pkgconf_flags $pkg) + pkg_libs=$($pkg_config --libs $pkgconf_flags $pkg)
I'm not sure if this is right - we should pass --static to pkg-config if we explicitly are linking statically to freetype (which we seldom/never do), or the more common case, freetype happens to only be available in static form (which we don't know here, only the linker will notice that no shared lib exists and will try with the static one instead). For this situation (building only static but no shared libs) it's generally easier if the lib itself changes the pkg-config file (like libav and some other libs do) so that callers won't have to know that they would have to pass --static to pkg-config for this particular lib.
And this doesn't have anything to do with whether libav is built statically or shared. Even if we're building libav with shared libs, you'd need to pass --static to pkg-config if freetype was built only statically, and conversely, if building a static libav but a shared freetype exists, it would unnecessarily try to link to more libs than necessary.
// Martin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
