On 4/20/19 1:34 AM, Armin K. via lfs-dev wrote:
On 20.4.2019. 07:30, Kevin Buckley via lfs-dev wrote:
Because I have been performing a PkgUser build, I have
noticed, when coming to install Xen, that Eudev appears
to install its two PkgConfig files in seperate locations.
pkg xen:xen-master> ls -l /usr/lib/pkgconfig/
-rw-r--r-- 1 eudev eudev 503 Mar 24 11:29 libudev.pc
pkg xen:xen-master> ls -l /usr/share/pkgconfig/
-rw-r--r-- 1 eudev eudev 95 Mar 24 11:29 udev.pc
FWIW, the reason that this comes to light is that Xen, by
default, was looking to install its PkgConfig files into
the latter, however, as that directory had been created by
the Eudev PkgUser, it couldn't write files there.
If, after the configure step has been preformed, I look
at Eudev's
src/udev/Makfile
I can see that Eudev apparently makes a distinction between
a "pkgconfiglibdir" and a "sharepkgconfigdir", vis:
...
pkgconfiglibdir = /usr/lib/pkgconfig
prefix = /usr
program_transform_name = s,x,x,
psdir = ${docdir}
rootlibdir = /lib
rootlibexecdir = /lib/udev
rootprefix =
rootrundir = /run
sbindir = /sbin
sharedstatedir = ${prefix}/com
sharepkgconfigdir = ${datarootdir}/pkgconfig
...
and the latter of Eudev's PkgConfig files being installed into
against the sharepkgconfigdir.
Should LFS modify its install of Eudev, so that both PkgConfig
files end up in the pkgconfiglibdir, which is where every other
package that gets installed appears to place them ?
I have to say that,whilst I have followed the FHS over the years,
I've never quite worked out why /usr/lib/pkgconfig seems to have
gained favour, as PkgConfig files are not "libs" and can provide
non-lib info, as opposed tobeing below /usr/share.
Perhaps though, this is one for the Eudev developers to come slean
about, given that they so appear to have made a distinction between
a PkgConfig file for a "lib" and one for a "utility", by seperating
them ?
Hi,
Think of it as following:
/usr/lib is arch specific. You can have /usr/lib64/pkgconfig,
/usr/lib32/pkgconfig, /usr/lib/pkgconfig, and all of them would point to
libs in the located in the respective parent directory.
On the other hand, /usr/share is not arch specific. In your cases, only
one udev binary (probably native one, i.e. x86_64, but not x86_32 or
x86_x32) will be present on a normally built system. In real multi arch
system (i.e. debian), you can install libudev1:amd64 and libudev1:i386,
at the same time, but you cannot install udev:amd64 and udev:i386 at the
same time due to them providing the same files in same locations.
To summarize: /usr/share/pkgconfig is for things that are not tied to an
architecture (i.e some headers in /usr/include or some configuration
files in /usr/share), while /usr/lib*/pkgconfig is for architecture
specific things (i.e libraries). pkg-config itself is not (does not have
to be) used for finding includes and libraries, but other installation
paths as well (package dependent, no real standard and no limitation).
Thanks Armin for the great explanation.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
