On Sat, 20 Apr 2019 at 23:49, Bruce Dubbs via lfs-dev
<lfs-dev@lists.linuxfromscratch.org> wrote:
> >> 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
Indeed, I now see why you would want multiple, arch-specific, locations
for arch-specific Pkg-Config files, and a location for arch-agnostic ones,
however, the question, for me, still remains as to why an x86_64 specific
udev.pc ends up in a "common/arch-agnostic" location and not below
/usr/lib/pkgconfig (the home of the x86_64 arch) ?
The content of
/usr/share/pkgconfig/udev.pc
Name: udev
Description: eudev
Version: 220
prefix=/usr
exec_prefix=${prefix}
udevdir=/lib/udev
by virtue of pointing to the /lib/udev, which is arch-specific,
suggests it is no different to, say, the x86_64 variant of
/usr/lib/pkgconfig/uuid.pc, vis:
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib
includedir=/usr/include
Name: uuid
Description: Universally unique id library
Version: 2.33.1
Requires:
Cflags: -I${includedir}/uuid
Libs: -L${libdir} -luuid
Similarly, in the Debian case, reference is still made to a
udev:amd64 "package", which, by virture of the amd64,
is arch specifiic, no ?
I can imagine a Pkg-Config file that provided wholly arch-independent
info about a package that was wholly arch-independent, but I'm not
sure that udev, here, is such a package.
Thanks for the feedback though, as Bruce notes, it is an
excellent description of the underltying approach that has
been taken.
Kevin
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
