[systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir

[Kay Sievers]

On Wed, Apr 8, 2015 at 7:52 PM, Marc-Antoine Perennou
<Marc-Antoine at perennou.com> wrote:
> On 8 April 2015 at 19:46, Kay Sievers <kay at vrfy.org> wrote:
>> On Wed, Apr 8, 2015 at 7:34 PM, Marc-Antoine Perennou
>> <Marc-Antoine at perennou.com> wrote:
>>> On 8 April 2015 at 18:47, Kay Sievers <kay at vrfy.org> wrote:
>>>> On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou
>>>> <Marc-Antoine at perennou.com> wrote:
>>>>> ---
>>>>>  Makefile.am | 3 +--
>>>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/Makefile.am b/Makefile.am
>>>>> index 9fa4223..9b769ee 100644
>>>>> --- a/Makefile.am
>>>>> +++ b/Makefile.am
>>>>> @@ -3725,8 +3725,7 @@ udevconfdir = $(sysconfdir)/udev
>>>>>  dist_udevconf_DATA = \
>>>>>         src/udev/udev.conf
>>>>>
>>>>> -sharepkgconfigdir = $(datadir)/pkgconfig
>>>>> -sharepkgconfig_DATA = \
>>>>> +pkgconfiglib_DATA += \
>>>>>         src/udev/udev.pc
>>>>
>>>> This is all backwards. The systemd.pc file is also in the wrong location.
>>>>
>>>> These GENERIC files are supposed to be found by the primary AND the
>>>> secondary arch at the same time, at the GENERIC location, not in a
>>>> arch-specific libdir.
>>>>
>>>> How would the 32bit build find this file on a 64bit compat-arch/multilib system?
>>>>
>>>> Kay
>>>
>>> Well, let's imagine a full cross-compilation toolchain, with
>>> CHOST-prefixed tools.
>>>
>>> x86_64 stuff will get built with x86_64-pc-linux-gnu-gcc
>>> i686 stuff will get built with i686-pc-linux-gnu-gcc
>>> (and you could add a lot of non-native archs here like arm, mips & co)
>>>
>>> x86_64-pc-linux-gnu-pkg-config will look into /usr/lib64/pkgconfig and
>>> /usr/share/pkgconfig
>>> i686-pc-linux-gnu-pkg-config will look into /usr/lib32/pkgconfig and
>>> /usr/share/pkgconfig
>>>
>>> You says that systemd is in the wrong location, so let's see what's
>>> going on with its
>>> current location, and then if we move it to /usr/share
>>>
>>> Current location, libdir/pkgconfig/systemd.pc
>>>
>>> x86_64-pc-linux-gnu-pkg-config finds /usr/lib64/pkgconfig/systemd.pc containing,
>>> amongst other things, libdir which is arch specific, /usr/lib64 and
>>> systemdutildir
>>> which contains arch-specific binaries (yes, /usr/lib64/systemd/systemd *is* an
>>> ELF64 binary using an x86_64 interpreter.
>>>
>>> i686-pc-linux-gnu-pkg-config finds /usr/lib32/pkgconfig/systemd.pc (since it has
>>> been cross-compiled too) and is pretty happy with that.
>>>
>>> arm-whatever-pkg-config finds /usr/arm-whatever/lib/systemd.pc and is
>>> happy with it.
>>>
>>> If you move it to /usr/share/pkgconfig
>>>
>>> x86_64-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc
>>> and is happy with it
>>>
>>> i686-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc and
>>> tries linking to
>>> x86_64 libraries
>>>
>>> arm-whatever-pkg-config finds /usr/share/pkgconfig/systemd.pc and
>>> tries linking to
>>> x86_64 libraries + it gets the path towards binaries its target won't
>>> even be able to execute.
>>>
>>>
>>> Hope that helps understanding the rational of putting pkgconfig files
>>> pointing to
>>> arch-specific libs/bins into an arch-specific place.
>>>
>>>
>>> A good example of a pkgconfig file that is ok to install into
>>> /usr/share/pkgconfig is
>>> xorg-macros.pc which only leads to arch-independants macros.
>>
>> The point is, the purpose of that file is not cross-compiling. It is
>> meant to provide information for the i686 toolchain which is nativly
>> compiled on a x86_64 primary host.
>>
>> How is the i686 tool supposed to find the primary values of the
>> installed native x86_64 tools if things are moved like you propose?
>>
>
> Why would it need to?

Because it is the purpose of that file. The version of systemd which
is installed is described in that file. Tools that build on this host
want the values of this systemd.

>> The entire idea of adding $libdir to a file that is installed in
>> $libdir to point to itself makes no sense at all, but that was the
>> reason it was moved in the first place.
>
> Agreed about the redundancy, but what if the arm tool wants to find
> installed arm tools, and not x86_64?

This is not a systemd problem. Systemd is the base system, and that is
described in that file, not something that is foreign to the base
system.

With the original intended purpose of these files, they just belong
into one single common location describing the currently
running/primary/common system values.

$libdir was added to indicate the primary architecture. That only
makes sense when the file is in a common location, not in libdir. Like
described in the man page:
  http://www.freedesktop.org/software/systemd/man/file-hierarchy.html#/usr/lib/arch-id

Kay