| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This effectively reverts c9c4fed39339ffde45123013a117e06d0bb9c488.
The mutation was originally removed because no one knew why it was done,
the spec suggests the fields should be independent of the static or
shared nature, the mutation bears risk of overlinking and no other
project I looked at did such a thing.
This works out well for full shared and full static builds. Mixed
builds with some libraries linked static and others shared were not
considered when removing the mutation and apparently pkg-config did
not consider this case either.
Using a custom static-only build of the desired libraries with a mutated
pc-file has become a common workaround for poor mixed build support of
pkg-config and many buildsystems. It's still very much an imperfect
workaround and doesn't do anything for mixed builds when both library
variants were built. Ideally pkg-config and buildsystems should be
improved to be able to handle this in the general case. Realistically
this won't happen in the foreseeable future though.
At least for the pkg-config side and when using a major (modern) linker
the effect can be emulated without mutating the pc-file by using
pkg-config's `--static` flag and telling the linker to only link
actually used libraries (`--as-needed` for GNU bfd, GNU gold, LLVM lld
and mold; `-z ignore` for illumos' linker).
In between the mutation being removed from libass and now being added
again, FriBidi and FreeType adopted this mutation workaround, FreeType
citing meson doing the same as a motivation. Indeed HarfBuzz's meson
build (but not the autotools build) will also mutate its pc-file.
meson itself started mutating pc files in 2018 (see meson commit
3f7c6cf3d6a204e9665faad3c05bb5049f08ac74). Going further back, FFmpeg
already mutates its pc-files since 2009 (see FFmpeg commit
12701f6e31f465377462c0fc2d5b34477c1c422b).
Reinstate the mutation (now with explaining comment) in libass to help
out affected builders and to foster consistency with other projects
while hoping no one runs into overlinking issues.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Libs.* are to be used for libraries not supplying a pc-file, eg system
libs, while Requires.* is meant for libraries which do supply a
*.pc-file.
The public version of those fields is only to be used for libs whose
symbols end up being exposed by our lib, by eg including one of their
headers in our own headers. Those libs must be linked to both for
dynamic and static builds.
The private versions are not directly exposed to users of our lib and
will only be linked to if an static build is requested. Those libs don't
need to be linked for dynamic builds, but _will_ be linked in static
builds. This also has implications for package maintainers, see eg
https://lists.debian.org/debian-devel-announce/2005/11/msg00016.html .
The intent in 7393996cfe0136f130a6a23bb9fb6f4ddce82d87, seems to have
been making this static/dynamic build distinction ourselves. However
this is both a needless complication in our config script as pkg-config
already handles this, and prone to fail as requesting a static build is
required anyway to get the *.private link flags of our dependencies as
well.
The correct way to handle a static build is to request one, eg one way
to do this for an executable built with autotools and pkg-config is:
LDFLAGS="-static" PKG_CONFIG="/usr/bin/pkg-config --static" ./configure
|
| |
|
|
|
|
|
| |
Add library and package dependencies to the default (non-private)
pkg-config fields for static-only builds. This makes sure the packages
and libraries are always picked up and used, even if the --static option
is not supplied to the pkg-config commandline.
|
| |
|
|
|
| |
* Add enable/disable flags for enca, fontconfig and libpng.
* Add dependent libraries to pkg-config file to allow static linking.
|
| |
|
