Finding libraries & includes for wheel building

I am trying to convert reportlab setup.py to work with github actions. The reportlab toolkit is old > 20 years and although recently we have started using appveyor, travis and now actions to produce wheels for various platforms it seems I should really be using cibuildwheel and not multibuild and a bunch of different mechanisms.

However, I find that I need to have a good way to locate the small number of libraries that a reportlab whl file needs. Is there somewhere a ‘standard’ way to locate dynamic libraries of interest? In practice it seems I only need to find a libfreetype,so and the corresponding ft2build.h.

My current code works in a cibuildwheel action for macos and windows (I download a static code base there), but in linux it seems that different dockers are causing problems.

Should I just search various possible start paths to try and find my library/include files?

On Linux systems, the best practice (although it doesn’t cover all libraries) is to rely on pkg-config to tell you where the headers and library are installed, and any flags needed for compilation and/or linking against them.

For example, on my Debian Bullseye system, installing the libfreetype-dev package means that I can run pkg-config --libs freetype2, which then tells me that linking against the library requires -lfreetype in the linker command line. Running pkg-config --cflags freetype2 reports -I/usr/include/freetype2 -I/usr/include/libpng16, which would be supplied to the compiler to make the headers available.

Most good C/C++ build systems have support for pkg-config, so you should investigate the one you are using.


thanks for the advice and it is true that on linux systems we do have decent mechanisms for finding out where installed
libraries are installed and associated headers (provided the information is correctly collected). Not sure this approach
works for windows; there I am using pre-built .lib files and using static loads. The macos universe is totally alien to
me and I rely on helpful prodding to try and make stuff work. In fact it seems that the existing code was wrking, but
cibuildwheel uses docker and although it talks about ubuntu-latest to make the manylinux wheels it seems as though
although the kernel is ubuntu the actual build system seems to be centos so apt doesn’t work except in the host, but
that’s irrelevant.

For Windows, either the distributor of a library is going to make it available in a known/discoverable location (for example, most of Microsoft’s and NVIDIA’s libraries have ways to find them), or else you’re completely on your own (most OSS libraries are in this category).

vcpkg is an attempt to improve this situation for native code, at least if you are planning to statically link it (pretty sure it won’t discover system libraries, but will download and compile new binaries when requested).

thanks for the link; not having a windows system to work on regularly makes it a bit problematic to play with, but it’s a useful resource. For many compiled python packages I can download from ~gohlke/pythonlibs/, but I think attempting to use these in cibuildwheel will require using package gohlkegrabber which is yet another level. Luckily freetype does point to GitHub - ubawurinna/freetype-windows-binaries: Windows binaries of FreeType where .lib files can be found for x86 & amd64.

FWIW, vcpkg is cross platform (and CMake-based), so if you get it working natively for yourself, it should be very similar to run on other platforms.