[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pkg-conf and LD* variables
From: |
Bob Friesenhahn |
Subject: |
Re: pkg-conf and LD* variables |
Date: |
Sun, 28 Oct 2018 22:17:01 -0500 (CDT) |
User-agent: |
Alpine 2.20 (GSO 67 2015-01-07) |
On Sat, 27 Oct 2018, Harlan Stenn wrote:
pkg-conf offers the following ways to get "link flags":
--libs All link flags
--libs-only-L The -L/-R stuff
--libs-only-l The -l stuff
--static Output ilbraries suitable for static linking
and then says the union of -only-L and -only-l may be smaller than the
output of -libs because the latter might include flags like -rdynamic.
We're already having to parse the output of pkg-config to try and
separate LDADD stuff from LDFLAGS stuff, And this is before we start to
address static v. dynamic things.
This is because we really don't want -L stuff in LDADD, because we end
up with things like:
No rule to make: -L /usr/local/lib
I see the same problems. It would have been useful if the inventors
of pkg-config read the GNU coding standards, the GNU make manual, and
the GNU Autoconf and Automake manuals, before they started.
As soon as header files and libraries need to be found in multiple
directories the wheels come off since there is total loss of control
of where the files are searched for.
A common scenario for me is that newer libraries are in one directory
tree (e.g. under /usr/local) with older libraries in other directory
trees (e.g. part of an OS distribution).
PKG_CONFIG_PATH is not powerful enough given that the options are
muddled together.
GraphicsMagick also makes sure that options are put in the correct
build variables. I don't see a way to accomplish this other than via
parsing pkg-config output and trying to make the best of it.
The GNU standard is that the user (the person controlling the build)
should have control over the configuration.
Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/