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

[Kay Sievers]

On Wed, Apr 8, 2015 at 8:10 PM, Marc-Antoine Perennou
<Marc-Antoine at perennou.com> wrote:
> On 8 April 2015 at 20:02, Kay Sievers <kay at vrfy.org> wrote:
>> 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
>
> Even if I don't fully agree with it, I understand your point, we'll
> then maintain this patch downstream.
>
> Thanks for the details about this refusal.

Still, things need to be fixed in git:
Putting udev.pc in share/ and systemd.pc in $libdir looks broken.

Putting $libdir into systemd.pc and installing the file itself into
$libdir makes zero sense.

I'm not against redefining all that, and make it more suitable for
cross-compilation, if that is what makes the most sense.

The current mess needs to be fixed, it is just confusing and really broken.

Kay