Incorrect pkg-config file generated

[ePirat]

I've encountered an issue with .pc file generation. Below is a snippet of how libplacebo uses the pkg-config file generator in meson:

lib = library('placebo', sources,
  install: true,
  dependencies: build_deps,
  soversion: apiver,
  include_directories: inc,
  objects: obj,
  link_args: link_args,
)

[…]

pkg = import('pkgconfig')
pkg.generate(
  name: meson.project_name(),
  description: 'Reusable library for GPU-accelerated video/image rendering',
  libraries: lib,
  version: version,
)

When I do a static build of the library this produces the following .pc file:

prefix=/Users/epirat/Projects/VideoLAN/VLC/build-test/contrib/arm64-apple-iOS_9.0
libdir=${prefix}/lib
includedir=${prefix}/include

Name: libplacebo
Description: Reusable library for GPU-accelerated video/image rendering
Version: 1.7.0
Libs: -L${libdir} -lplacebo -lm /Users/epirat/Projects/VideoLAN/VLC/build-test/contrib/arm64-apple-iOS_9.0/lib/libglslang.a /Users/epirat/Projects/VideoLAN/VLC/build-test/contrib/arm64-apple-iOS_9.0/lib/libHLSL.a /Users/epirat/Projects/VideoLAN/VLC/build-test/contrib/arm64-apple-iOS_9.0/lib/libOGLCompiler.a /Users/epirat/Projects/VideoLAN/VLC/build-test/contrib/arm64-apple-iOS_9.0/lib/libOSDependent.a /Users/epirat/Projects/VideoLAN/VLC/build-test/contrib/arm64-apple-iOS_9.0/lib/libSPIRV.a /Users/epirat/Projects/VideoLAN/VLC/build-test/contrib/arm64-apple-iOS_9.0/lib/libSPVRemapper.a -lpthread
Cflags: -I${includedir}

For some reason it put a bunch of .a file paths into the Libs section, I would expect those in Libs.private.

Additionally hardcoding the .a paths causes problems with GNU libtool on macOS at least, illustrated by the example below:

$ libtool link gcc -static -g -O -o libfoo.la lib.lo […]/lib/libglslang.a

Would cause libtool to do he following:

*** Warning: Linking the shared library libfoo.la against the
*** static library […]/lib/libglslang.a is not portable!
libtool: link: rm -fr  .libs/libfoo.a .libs/libfoo.la
libtool: link: ar cru .libs/libfoo.a […]/lib/libglslang.a  lib.o
libtool: link: ranlib .libs/libfoo.a
libtool: link: ( cd ".libs" && rm -f "libfoo.la" && ln -s "../libfoo.la" "libfoo.la" )

It already helpfully says this is not portable, in fact, what it does on macOS in this case (ar cru .libs/libfoo.a […]/lib/libglslang.a lib.o) results in a unusable static library archive:

$ objdump -a .libs/libfoo.a
objdump: '.libs/libfoo.a': The file was not recognized as a valid object file.

[xclaesse]

When default_library=static, it always puts everything in libs instead of livs.private. I personally strongly disagree with the reason it was changed that way, but it's like that... If you set default_library=both then you should see them moved to libs.private.

Regarding having full path to .a files, I guess it depends how those deps are found. Are you using find_library() ?

[xclaesse]

nitpicking: libraries: lib, you can pass lib as first positional argument instead, that fix subtle issues if you later generate other .pc files that depends on lib. Probably doesn't change anything in your case.

[ePirat]

Regarding having full path to .a files, I guess it depends how those deps are found. Are you using find_library() ?

Yes:

  glslang_deps = [
    cxx.find_library('glslang',     required: glslang_req),
    cxx.find_library('HLSL',        required: glslang_req),
    cxx.find_library('OGLCompiler', required: glslang_req),
    cxx.find_library('OSDependent', required: glslang_req),
    cxx.find_library('SPIRV',       required: glslang_req),
    cxx.find_library('SPVRemapper', required: glslang_req),
  ]

[ePirat]

It seems meson is the only tool that puts full paths to .a files into the .pc file as currently the libplacebo dependency using meson is the only that causes this weird GNU libtool problem for us, as far as I can tell.

[textshell]

We changed meson to use full file names for libraries to avoid library search path problems when mixing "-L" form many sources. I still believe that's the right thing to do. But libtool not groking these of course is a problem. Is this OS X specific or does this reproduce with other systems as well?

[ePirat]

I am not sure, I don't really have time to verify if this affects other systems too but it is definitely an issue on macOS.

[alexandre-janniaux]

It's also raising issues with libtool on Linux Fedora 31, when trying to create a static convenience libtool library.

libvlc_opengl_la_SOURCES = $(OPENGL_COMMONSOURCES)
libvlc_opengl_la_CFLAGS = $(LIBPLACEBO_CFLAGS)
libvlc_opengl_la_LIBADD = $(LIBM) $(LIBPLACEBO_LIBS)
libvlc_opengl_la_LDFLAGS = -static -no-undefined

Expected pkgconfig:

prefix=/home/alexandre/workspace/videolabs/vlc-meson/contrib/x86_64-redhat-linux
libdir=${prefix}/lib
includedir=${prefix}/include
Name: libplacebo
Description: Reusable library for GPU-accelerated video/image rendering
Version: 1.18.0
Libs: -L${libdir} -lplacebo -lm -lglslang -lHLSL -lOGLCompiler -lOSDependent -lSPIRV -lSPVRemapper -lpthread -pthread
Cflags: -I${includedir} -pthread

expected ar command ran when linking into a static libtool library:

libtool: link: ar cru .libs/libvlc_opengl.a  video_output/opengl/.libs/libvlc_opengl_la-vout_helper.o video_output/opengl/.libs/libvlc_opengl_la-gl_api.o video_output/opengl/.libs/libvlc_opengl_la-gl_util.o video_output/opengl/.libs/libvlc_opengl_la-interop.o video_output/opengl/.libs/libvlc_opengl_la-interop_sw.o video_output/opengl/.libs/libvlc_opengl_la-renderer.o video_output/opengl/.libs/libvlc_opengl_la-sampler.o video_output/opengl/.libs/libvlc_opengl_la-sub_renderer.o video_output/.libs/libvlc_opengl_la-placebo_utils.o

pkgconfig generated:

prefix=/home/foo/vlcsource/vlc/contrib/x86_64-redhat-linux
libdir=${prefix}/lib
includedir=${prefix}/include
Name: libplacebo
Description: Reusable library for GPU-accelerated video/image rendering
Version: 1.18.0
Libs: -L${libdir} -lplacebo -lm /home/foo/vlcsource/vlc/contrib/x86_64-redhat-linux/lib/libglslang.a /home/foo/vlcsource/vlc/contrib/x86_64-redhat-linux/lib/libHLSL.a /home/foo/vlcsource/vlc/contrib/x86_64-redhat-linux/lib/libOGLCompiler.a /home/foo/vlcsource/vlc/contrib/x86_64-redhat-linux/lib/libOSDependent.a /home/foo/vlcsource/vlc/contrib/x86_64-redhat-linux/lib/libSPIRV.a /home/foo/vlcsource/vlc/contrib/x86_64-redhat-linux/lib/libSPVRemapper.a -lpthread -pthread

resulting ar command:

libtool: link: ar cru .libs/libvlc_opengl.a /home/foo/vlcsource/vlc/contrib/x86_64-redhat-linux/lib/libglslang.a /home/foo/vlcsource/vlc/contrib/x86_64-redhat-linux/lib/libHLSL.a /home/foo/vlcsource/vlc/contrib/x86_64-redhat-linux/lib/libOGLCompiler.a /home/foo/vlcsource/vlc/contrib/x86_64-redhat-linux/lib/libOSDependent.a /home/foo/vlcsource/vlc/contrib/x86_64-redhat-linux/lib/libSPIRV.a /home/foo/vlcsource/vlc/contrib/x86_64-redhat-linux/lib/libSPVRemapper.a  video_output/opengl/.libs/libvlc_opengl_la-vout_helper.o video_output/opengl/.libs/libvlc_opengl_la-gl_api.o video_output/opengl/.libs/libvlc_opengl_la-gl_util.o video_output/opengl/.libs/libvlc_opengl_la-interop.o video_output/opengl/.libs/libvlc_opengl_la-interop_sw.o video_output/opengl/.libs/libvlc_opengl_la-renderer.o video_output/opengl/.libs/libvlc_opengl_la-sampler.o video_output/opengl/.libs/libvlc_opengl_la-sub_renderer.o video_output/.libs/libvlc_opengl_la-placebo_utils.o

Leading to failures when trying to use the libtool library

libtool: link: /usr/bin/nm -B  video_output/opengl/.libs/libgl_plugin_la-display.o   ./.libs/libvlc_opengl.a | sed -n -e 's/^.*[     ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[     ][  ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | /usr/bin/sed 's/.* //' | sort | uniq > .libs/libgl_plugin.exp
/usr/bin/nm: libglslang.a: file format not recognized
/usr/bin/nm: libHLSL.a: file format not recognized
/usr/bin/nm: libOGLCompiler.a: file format not recognized
/usr/bin/nm: libOSDependent.a: file format not recognized
/usr/bin/nm: libSPIRV.a: file format not recognized
/usr/bin/nm: libSPVRemapper.a: file format not recognized
libtool: link: /usr/bin/grep -E -e "^vlc_entry" ".libs/libgl_plugin.exp" > ".libs/libgl_plugin.expT"
libtool: link: mv -f ".libs/libgl_plugin.expT" ".libs/libgl_plugin.exp"
libtool: link: echo "{ global:" > .libs/libgl_plugin.ver
libtool: link:  cat .libs/libgl_plugin.exp | sed -e "s/\(.*\)/\1;/" >> .libs/libgl_plugin.ver
libtool: link:  echo "local: *; };" >> .libs/libgl_plugin.ver
libtool: link:  gcc -shared  -fPIC -DPIC  video_output/opengl/.libs/libgl_plugin_la-display.o  -Wl,--whole-archive ./.libs/libvlc_opengl.a -Wl,--no-whole-archive  -Wl,-rpath -Wl,/home/foo/vlcsource/vlc.build/src/.libs -Wl,-rpath -Wl,/usr/local/lib ../compat/.libs/libcompat.a -L/home/foo/vlcsource/vlc/contrib/x86_64-redhat-linux/lib ../src/.libs/libvlccore.so -ldl -ldbus-1 -lasan -lplacebo -lpthread -lm  -pthread -g -O2 -pthread -fstack-protector-strong -Wl,-z -Wl,defs   -pthread -Wl,-soname -Wl,libgl_plugin.so -Wl,-version-script -Wl,.libs/libgl_plugin.ver -o .libs/libgl_plugin.so
/usr/bin/ld: ./.libs/libvlc_opengl.a: member ./.libs/libvlc_opengl.a(libglslang.a) in archive is not an object

[alexandre-janniaux]

Hi,

For information, I'm not sure it will ever get into a release, but I've sent a fix for libtool there: https://lists.gnu.org/archive/html/libtool-patches/2021-04/msg00000.html