[Top][All Lists]

[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 Friesenhahn
GraphicsMagick Maintainer,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]