Finding the correct library to link (feature request for pkg-config support)h

[rleigh@…]

This bug report is a feature request for the addition of pkg-config support to Boost, in order to provide a simple, reliable, platform-independent mechanism for discovering if the Boost libraries are installed, what they are called, where they are installed, and how to link with them. This is currently not possible to achieve. A detailed rationale and an example for how to implement this follow.

I make use of several Boost libraries in my schroot program (​svn://svn.debian.org/svn/buildd-tools/trunk/schroot).

This project, like many, utilises GNU Autoconf and Automake for its build system. I need to determine how to link with the Boost libraries in order to build the programs in the project. This is an issue for many projects which want to link with a Boost library. Note that calling bjam is not a possibility here; it may not be installed, and most projects are not using bjam, especially if boost is just one of many libraries being used.

To illustrate my problem:

ls -l /usr/lib/libboost_regex-*.so /usr/lib/libboost_program_options-*.so

lrwxrwxrwx 1 root root 45 2007-07-08 11:48 /usr/lib/libboost_program_options-gcc41-1_34.so -> libboost_program_options-gcc41-1_34.so.1.34.0 lrwxrwxrwx 1 root root 48 2007-07-08 11:48 /usr/lib/libboost_program_options-gcc41-mt-1_34.so -> libboost_program_options-gcc41-mt-1_34.so.1.34.0 lrwxrwxrwx 1 root root 41 2007-07-08 11:48 /usr/lib/libboost_program_options-mt.so -> libboost_program_options-gcc41-mt-1_34.so lrwxrwxrwx 1 root root 38 2007-07-08 11:48 /usr/lib/libboost_program_options-st.so -> libboost_program_options-gcc41-1_34.so lrwxrwxrwx 1 root root 35 2007-07-08 11:47 /usr/lib/libboost_regex-gcc41-1_34.so -> libboost_regex-gcc41-1_34.so.1.34.0 lrwxrwxrwx 1 root root 38 2007-07-08 11:47 /usr/lib/libboost_regex-gcc41-mt-1_34.so -> libboost_regex-gcc41-mt-1_34.so.1.34.0 lrwxrwxrwx 1 root root 31 2007-07-08 11:47 /usr/lib/libboost_regex-mt.so -> libboost_regex-gcc41-mt-1_34.so lrwxrwxrwx 1 root root 28 2007-07-08 11:47 /usr/lib/libboost_regex-st.so -> libboost_regex-gcc41-1_34.so

Unlike every other library on my system, the Boost libraries have the compiler (gcc41) and threading model (mt|st) and so on embedded *in the library name*. This makes it impossible to discover in an automatic fashion. Since my project is free software anyone can download and build, I don't know what the compiler/toolchain will be, let alone what abbreviation Boost has chosen for it. I expect that Autoconf will set up such things appropriately; my code is relatively compiler-agnostic, but I can't predict the Boost library names without help.

The only means I have are the libboost_program_options-mt.so, libboost_program_options-st.so (and so on for all the libraries) symbolic links which the Debian maintainer has helpfully provided. However, these are not portable, and are so not a good solution. They are, however, the only available solution at the moment.

To further show the problem I am having, this is part of my configure.ac Autoconf template:

---configure.ac---- AC_CHECK_HEADERS([tr1/memory])

AC_CHECK_HEADERS([boost/shared_ptr.hpp] _[

if test $ac_cv_header_tr1_memory = yes; then

:

else

AC_MSG_ERROR([Boost.shared_ptr (Boost C++ Libraries) is not installed, but is required by schroot])

fi])

AC_CHECK_HEADERS([tr1/tuple])

AC_CHECK_HEADERS([boost/tuple/tuple.hpp] _[

if test $ac_cv_header_tr1_memory = yes; then

:

else

AC_MSG_ERROR([Boost.Tuple (Boost C++ Libraries) is not installed, but is required by schroot])

fi])

AC_CHECK_HEADERS([boost/format.hpp] _{[AC_MSG_ERROR([Boost.Format (Boost C++ Libraries) is not installed, but is required by schroot])]) AC_CHECK_HEADERS([boost/program_options.hpp]} [AC_MSG_ERROR([Boost.Program_options (Boost C++ Libraries) is not installed, but is required by schroot])]) AC_CHECK_HEADERS([boost/type_traits.hpp] _{[AC_MSG_ERROR([Boost.TypeTraits (Boost C++ Libraries) is not installed, but is required by schroot])])}

AC_MSG_CHECKING([for boost::program_options::variables_map in -lboost_program_options-st]) saved_ldflags="${LDFLAGS}" LDFLAGS="${LDFLAGS} -lboost_program_options-st" AC_LINK_IFELSE([AC_LANG_PROGRAM(<boost/program_options.hpp>,

[boost::program_options::variables_map::variables_map dummy()])],

[AC_MSG_RESULT([yes])

BOOST_LIBS="${BOOST_LIBS} -lboost_program_options-st"],

[AC_MSG_RESULT([no])

AC_MSG_FAILURE([libboost_program_options (Boost C++ Libraries) is not installed, but is required by schroot])])

LDFLAGS="${saved_ldflags}"

AC_MSG_CHECKING([for boost::program_options::options_description::options() in -lboost_program_options-st]) saved_ldflags="${LDFLAGS}" LDFLAGS="${LDFLAGS} -lboost_program_options-st" AC_LINK_IFELSE([AC_LANG_PROGRAM(<boost/program_options.hpp>,

[boost::program_options::options_description testgrp("test group");

bool notused = testgrp.options().empty();

])],

[AC_MSG_RESULT([yes])

BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS="current"],

[AC_MSG_RESULT([no])

BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS="old"])

LDFLAGS="${saved_ldflags}" AH_TEMPLATE(BOOST_PROGRAM_OPTIONS_DESCRIPTION_OLD, [Set if boost::program_options::options_description::options() is not available]) if test "$BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS" = "old"; then

AC_DEFINE(BOOST_PROGRAM_OPTIONS_DESCRIPTION_OLD, 1)

fi

AC_MSG_CHECKING([for boost::regex in -lboost_regex-st]) saved_ldflags="${LDFLAGS}" LDFLAGS="${LDFLAGS} -lboost_regex-st" AC_LINK_IFELSE([AC_LANG_PROGRAM(<boost/regex.hpp>,

[boost::regex("^foo[bar]$")])],

[AC_MSG_RESULT([yes])

BOOST_LIBS="${BOOST_LIBS} -lboost_regex-st"],

[AC_MSG_RESULT([no])

AC_MSG_FAILURE([libboost_regex (Boost C++ Libraries) is not installed, but is required by schroot])])

LDFLAGS="${saved_ldflags}"

AC_SUBST([BOOST_LIBS])

---configure.ac----

As you can see, that's quite a bit of complexity. It also includes code to work around a backwards compatibility issue in Boost.Program_options. However, it needs to know the library name in order to link the test code, and I'm still needing to use a non-standard name in order to do that.

It would be great if Boost would provide a mechanism to allow such discovery. Such a mechanism already exists, and is called "pkg-config". By installing a small file in LIBDIR/pkgconfig for each Boost library, the pkg-config tool or PKG_CHECK_MODULES Autoconf macro may be used to query this information. As an example:

---

prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include

Name: boost-regex-mt Description: Boost C++ Regular Expression Library (multi-threaded) Version: 1.34.0 Libs: -L${libdir} -lboost_regex-gcc41-mt-1_34 Libs.private: -licui18n -licuuc -lrt -lm Cflags: -I${includedir} -pthread

---

You can generate this from a template:

---

prefix=PREFIX exec_prefix=EPREFIX libdir=LIBDIR includedir=INCLUDEDIR

Name: boost-regex-mt Description: Boost Regular Expression Library (multi-threaded) Version: VERSION Libs: -L${libdir} LIBRARY_NAME Libs.private: LIBRARY_DEPENDENCIES [for static linking] Cflags: -I${includedir} THREAD_OPTIONS_FOR_COMPILER

---

where the capitalised names are where you would substitute in the system- and compiler-specific options. It looks like bjam could probably make this a single rule all libraries could make use of.

For such a setup, all that configure script above could be mostly reduced to

PKG_CHECK_MODULES([boost-regex-st]) PKG_CHECK_MODULES([boost-program-options-st])

I don't know how bjam works, but I do this with Autoconf as a file generated by config.status, but it could also be generated by make with a simple sed command. I guess you could do the bjam equivalent, whatever that might be. I have had a look at the sources to try to implement this, but I am afraid I lack the bjam expertise to do it.

You may find much more detailed discussion of these issues at

​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424038 ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424666 ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425264 ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428419 ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350539

Some of these are due to Debian-specific issues (a change to the symlink name), but the root cause is the inability to identify the Boost library names in an automated fashion.

Regards, Roger

--

.`. Roger Leigh

: :' : Debian GNU/Linux ​http://people.debian.org/~rleigh/ . ' Printing on GNU/Linux? ​http://gutenprint.sourceforge.net/

`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.

[Vladimir Prus]

I have replied to this in ​http://permalink.gmane.org/gmane.comp.lib.boost.devel/162347

I think we'd need further discussion on the mailing list.

[boost@…]

Just noting for people that may google to this bug that the autoconf macro archive:

​http://autoconf-archive.cryp.to/macros-by-category.html#BOOST

does have some autoconf macros that deal with the library naming convention, and set, e.g. @BOOST_THREAD_LIB@ correctly, most of the time

Not quite pkg_config, but possibly usable for some people?

[roland.schwarz@…]

Sorry if this sounds ignorant, but my knowledge of pkg-config is limited:

I could not find an option to select the toolchain. Is it correct, that pkg-config does not allow specifying the toolchain?

Roland

[rleigh@…]

Hi Roland,

pkg-config does not currently support multiple toolchains natively. However, there are plans to support it:

​https://bugs.freedesktop.org/show_bug.cgi?id=130 ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217902

In the meantime, the PKG_CONFIG_PATH environment variable may be used to point pkg-config at the locations of files for different toolchains. In its typical use, the files live in /usr/lib/pkgconfig, for use by the standard system toolchain.

Note that toolchains here may have a different meaning than what Boost uses. It would mean the common CPU-MANUFACTURER-OPSYS triplet, e.g. powerpc-unknown-linux-gnu (my system) to work with the standard cross-compiling setups. This doesn't include compiler information.

Regards, Roger

[smr@…]

I wanted to record here a thread from 2005 discussing pkg-config support in Boost:

​http://lists.boost.org/Archives/boost/2005/06/88432.php

This thread is best characterized as advocating pkg-config (or something like it) and educating some of the boost developers as to the pitfalls of the current nonstandard library naming convention.

[Michael H. Cox <mhcox@…>]

Ticket #2077 is a duplicate of this ticket. The only information from #2077 the might be useful are the links:

It would be easier to use Boost if it would provide pkg-config files.

• ​http://pkg-config.freedesktop.org/wiki/
• ​http://linux.die.net/man/1/pkg-config

[Vladimir Prus]

I am tentatively scheduling this for 1.39. Note that because pkg-config does not support build variant, pkg-config files may only be generated when building a single variant.

[smr@…]

Replying to vladimir_prus:

I am tentatively scheduling this for 1.39. Note that because pkg-config does not support build variant, pkg-config files may only be generated when building a single variant.

Vladimir, for Debian we build with both release and debug variants. If pkg-config is limited to only one variant, I'd still choose to support it but ship only a "release variant" pkg-config. Can that be supported somehow, perhaps by giving bjam an option as to which variant to produce pkg-config files for? Or by generating all of them and letting me select the one to install?

Thanks, -Steve

[Vladimir Prus]

This, apparently, slipped by 1.39. And worse, I'm confused again.

Steven, what name of .pc files do you want? should that be boost_program_options ? Also, do you expect pkg-config boost_program_option to always return, in essense, -lboost_program_options ?

[Braden McDaniel <braden@…>]

Replying to vladimir_prus:

This, apparently, slipped by 1.39. And worse, I'm confused again.

Steven, what name of .pc files do you want? should that be boost_program_options ? Also, do you expect pkg-config boost_program_option to always return, in essense, -lboost_program_options ?

If that's the correct flag for linking, then yes.

The way to support different variants with pkg-config would be to install different .pc files for each variant. Presumably those would be named using the same scheme that gets used for naming library variants.

Those suffixes look like noise on single variant installations; however, the really important thing here is that there is a consistently used name for the "release" variant that is conventionally deployed. If there are a few odd letters hanging off the end, that's okay--as long the name gets used consistently. OTOH, getting that consistency may mean forgoing the variant suffix in the .pc file name. (In fact, the consistency of that name matters more than whether it actually refers to a consistent configuration of Boost.)

And this is probably worth reading: ​http://err.no/personal/blog/2008/Mar/25

[Vladimir Prus]

There's no way we'll be installing more that one .pc file for a given Boost library. That would either require that 8 variants are built by default (not an sensible option), or that we install between 1 and 8 .pc files for a library (and the application will have to choose which one to use -- which is the mess we're trying to fix), or we always install 8 .pc per library, and those corresponding to varians that are not build actually link to different variants, and that will make installing 8 .pc pointless.

So, only one .pc per library.

[Braden McDaniel <braden@…>]

Installing multiple .pc files for a given Boost library makes no less (or more) sense than installing multiple configurations of the library. Similarly, generating multiple names for a .pc file based on the configuration makes just as much sense as doing so for the library name. I will certainly grant that installing multiple configurations of a library is not something that is generally desirable on most modern POSIXy systems. And so even if multiple .pc files were installed, there would be one configuration name that would wind up as a de facto default (just as libboost_foo-mt is what users of these systems link with most of the time now).

The point is that pkg-config doesn't solve the "I don't know which configuration I want" problem. It solves the "I don't know what compiler/linker flags I need" problem while assuming that the .pc file name you provided corresponds to an acceptable configuration.

But don't get the impression that I'm advocating changing the .pc file name based on the configuration. I'm just pointing out that using single name for all configurations of a library (1) is inconsistent with Boost's practice for library naming and (2) doesn't accomplish anything that isn't also be accomplished by not mutating the library name based on the configuration. That said, I think it is perfectly acceptable to amend this practice where .pc files are concerned if only because the library naming ship has already sailed.

[magnus@…]

I'm guessing this has been slipping by again, since 1.43 has been released already. Right?

[Roger Leigh <rleigh@…>]

I've been think about how to better support this. I was recently introduced to /usr/include/boost/config/auto_link.hpp which supports auto-linking on MSVC and Borland compilers. I've been looking at if this would also be a suitable mechanism for getting the information for generating pkg-config .pc files for a boost build.

If we have a simple program that includes each Boost header, e.g. for boost_filesystem:

#define BOOST_PKG_CONFIG_DUMP_LIBS

#include <boost/filesystem.hpp> int main() {

const char *libs = BOOST_PKG_CONFIG_LIBS;

}

and auto_link.hpp defined BOOST_PKG_CONFIG_LIBS if BOOST_PKG_CONFIG_DUMP_LIBS was set

we can write a simple C++ program that's compiled with a range of headers and can then print out the .pc file to stdout. This will ensure consistent linking across platforms.

I've been looking at doing this, but the main sticking point is the C preprocessor. A single include can cause auto_link.hpp to be included multiple times, and the C preprocessor doesn't allow TTBOMK modification of existing macros to allow appending of a value or concatenation so we can store a list of libs across includes. If there was some way of transparently getting the information out, this would be ideal. The existing compilers don't need to deal with this because they all use #pragmas, whereas we can't do that AFAICT.

Maybe the Boost preprocessor macros can help here, but this is outside my current experience. Any ideas?

Regards, Roger

[Roger Leigh <rleigh@…>]

auto_link stores link data

[Roger Leigh <rleigh@…>]

Generate pkg-config .pc file from auto-link data

[Roger Leigh <rleigh@…>]

With the above two attachments, you can do this:

% g++ -DTEST_LIBRARY='"boost_filesystem"' -DTEST_HEADER='<boost/filesystem.hpp>' -o boost-pkg-config-gen boost-pkg-config-gen.cc -lboost_filesystem
% ./boost-pkg-config-gen > boost_filesystem.pc
% cat boost_filesystem.pc 
prefix=/usr
exec_prefix=${prefix}
libdir=/usr/lib
includedir=${prefix}/include

Name: boost_filesystem
Description: Boost C++ libraries (boost_filesystem)
Version: 1.42.0
Libs: -L${libdir} -lboost_filesystem -lboost_system
Cflags: -I${includedir}

Notice that it's correctly picked out the boost_filesystem and boost_system dependencies.

The auto_link.hpp change causes any required libraries to be stored in a boost::pkg_config::library_list class. This is only created if BOOST_PKG_CONFIG_DUMP is defined, so has zero overhead for normal users.

Note, boost/random/detail/auto_link.hpp and boost/iostreams/detail/config/auto_link.hpp may need adjusting as for boost/config/auto_link.hpp so that it's not skipped for non-MSVC/Borland compilers. All compilers should now process boost/config/auto_link.hpp. The object created to trigger list updates could also be put into the anonymous namespace.

The test program needs these macros defining:

• TEST_LIBRARY - library name
• TEST_HEADER - header to include
• PREFIX - install prefix (currently hardcoded)
• LIBDIR - library directory (currently hardcoded)
• include path and exec prefix may also require defining (again currently hardcoded)

I don't know how to use the Boost build system to integrate this directly (I'm a make person I'm afraid), or else I'd do that in the patch. If the various path prefixes are known to the build system, they can be passed directly during compilation (I didn't see them stored in any headers).

So, it's now possible to run the program for each boost module (name and primary header) and get a .pc file generated for it. These need installing in prefix/lib/pkgconfig. Note that this test program needs linking with *every* boost shared object available, since we don't know in advance which will be needed for a given combination of headers (this being the point of the excercise in the first place).

This doesn't use more advanced features such as Requires (which would allow for nested inclusion of .pc files), but this isn't really required.

Also, pkg-config files may be created for all Boost libraries irrespective of whether they have a shared object or not. The include path etc. are still useful.

One implication this scheme has is that the .pc files can't be generated when cross-compiling unless run on the host post-build. However, it's about the best we can do without direct compiler support for the auto-link scheme used by MSVC/Borland.

I hope this useful for inspiration if it's not directly usable for you as is.

Regards, Roger Leigh

(Thanks are also due to a number of other Debian developers who spent some time with me trying to find solutions utilising the C preprocessor only. Unfortunately, we didn't find a clean way to do that.)

[Roger Leigh <rleigh@…>]

Updated patch (use anonymous namespace)

[olafvdspek@…]

prefix=/usr
exec_prefix=${prefix}
libdir=/usr/lib
includedir=${prefix}/include

Why is this being hard-coded?

[Roger Leigh <rleigh@…>]

It shouldn't be hard coded. Ideally it should get these from the configured locations in bootstrap.sh. I just don't understand enough of bjam to do this yet, so I just used those in my proof of concept example. They should definitely be replaced with the actual configured locations.

Regards, Roger

[Roger Leigh <rleigh@…>]

Has any progress been made on pkg-config generation?

Now that most Linux distributions have switched to using --no-add-needed for linking, this is needed quite urgently! Without it, we have to explicitly hard code the link dependencies, and this is simply untenable when multiple boost versions are to be supported, and you want any degree of flexibility e.g. to ensure your code will link with past or future Boost releases. It's just too fragile and impractical.

​http://wiki.debian.org/ToolChain/DSOLinking has some information on the linker changes. Note that this has already been done in Fedora and Ubuntu, and all the derivative distros will pick it up very soon.

Many thanks, Roger

[Roger Leigh <rleigh@…>]

If the above proposed method is unsuitable, e.g. because it's not suitable for cross-compiling, could it be generated by boost-install? If all the information is present at this point, where would be the ideal place to make the change? tools/build/v2/tools/stage.py looks promising; but we need to be able to tell if we're installing a library or something else, e.g. a binary. This would I guess also allow creation of one pc file per library per toolchain variant etc. If this is the case, we can simply output the .pc file directly into the destination libdir/pkg-config/libname.pc.

Regards, Roger

[Sam Hanes <sam@…>]

For those using autoconf, Benoit Sigoure's boost.m4 macro set works better than the ones from the autoconf archive mentioned above. I would certainly prefer pkg-config, but for those of us using autoconf these macros work well enough in the meantime.

​https://github.com/tsuna/boost.m4

[anonymous]

This gives:

boost-pkg-config-gen.cc: In function ‘int main()’: boost-pkg-config-gen.cc:20: error: ‘BOOST_VERSION’ was not declared in this scope boost-pkg-config-gen.cc:24: error: ‘boost::pkg_config’ has not been declared boost-pkg-config-gen.cc:25: error: ‘boost::pkg_config’ has not been declared

Replying to Roger Leigh <rleigh@…>:

With the above two attachments, you can do this:

% g++ -DTEST_LIBRARY='"boost_filesystem"' -DTEST_HEADER='<boost/filesystem.hpp>' -o boost-pkg-config-gen boost-pkg-config-gen.cc -lboost_filesystem
% ./boost-pkg-config-gen > boost_filesystem.pc
% cat boost_filesystem.pc 
prefix=/usr
exec_prefix=${prefix}
libdir=/usr/lib
includedir=${prefix}/include

Name: boost_filesystem
Description: Boost C++ libraries (boost_filesystem)
Version: 1.42.0
Libs: -L${libdir} -lboost_filesystem -lboost_system
Cflags: -I${includedir}

Notice that it's correctly picked out the boost_filesystem and boost_system dependencies.

The auto_link.hpp change causes any required libraries to be stored in a boost::pkg_config::library_list class. This is only created if BOOST_PKG_CONFIG_DUMP is defined, so has zero overhead for normal users.

Note, boost/random/detail/auto_link.hpp and boost/iostreams/detail/config/auto_link.hpp may need adjusting as for boost/config/auto_link.hpp so that it's not skipped for non-MSVC/Borland compilers. All compilers should now process boost/config/auto_link.hpp. The object created to trigger list updates could also be put into the anonymous namespace.

The test program needs these macros defining:

• TEST_LIBRARY - library name
• TEST_HEADER - header to include
• PREFIX - install prefix (currently hardcoded)
• LIBDIR - library directory (currently hardcoded)
• include path and exec prefix may also require defining (again currently hardcoded)

I don't know how to use the Boost build system to integrate this directly (I'm a make person I'm afraid), or else I'd do that in the patch. If the various path prefixes are known to the build system, they can be passed directly during compilation (I didn't see them stored in any headers).

So, it's now possible to run the program for each boost module (name and primary header) and get a .pc file generated for it. These need installing in prefix/lib/pkgconfig. Note that this test program needs linking with *every* boost shared object available, since we don't know in advance which will be needed for a given combination of headers (this being the point of the excercise in the first place).

This doesn't use more advanced features such as Requires (which would allow for nested inclusion of .pc files), but this isn't really required.

Also, pkg-config files may be created for all Boost libraries irrespective of whether they have a shared object or not. The include path etc. are still useful.

One implication this scheme has is that the .pc files can't be generated when cross-compiling unless run on the host post-build. However, it's about the best we can do without direct compiler support for the auto-link scheme used by MSVC/Borland.

I hope this useful for inspiration if it's not directly usable for you as is.

Regards, Roger Leigh

(Thanks are also due to a number of other Debian developers who spent some time with me trying to find solutions utilising the C preprocessor only. Unfortunately, we didn't find a clean way to do that.)

[Roger Leigh <rleigh@…>]

Looks like it just needs an addition of #include <boost/version.hpp> to make it build. Note that this program is purely a proof of concept, it would need some work to include it directly in the Boost source tree e.g. Makefile changes (or the Bjam equivalent, which I would have included had I any clue about how Bjam works).

Regards, Roger

[anonymous]

Any progress on this issue ? -- Johan Boulé

[Roger Leigh <rleigh@…>]

While this ticket was originally opened to provide pkg-config support, the mechanism proposed here could additionally be extended to also generate appropriate CMake configuration files for use with find_package to override the built-in FindBoost.cmake with build-specific configuration.

[germandiago@…]

Is pkg-config support for boost still active?

[bartlomiej.kucharczyk@…]

2 yet-another-years has passed... Is there any progress on this topic, anyone? I'm mostly interested in .pc files for cross-compilation (no autotools/cmake build system...).