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

Wed Apr 8 11:50:14 PDT 2015

On 8 April 2015 at 20:24, Kay Sievers <kay at vrfy.org> wrote:
> 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

Well, on one hand, we may have the need for multilib stuff to find the
native binaries, as you said.

On the other hand we have my case. Just a bit of background so that
you understand where these patches come from:
I'm developper for the Exherbo distribution, and we recently changed
completely our filesystem layout when we introduced full
cross-compilation support.
We now have everything in /usr/arch (when you put stuff into /usr/lib/arch).
We thus have complete trees for each arch with
/usr/arch/{bin,sbin,lib,libexec,include} and want those to be
completely independant.
We try to keep as vanilla as possible and I think we're quite good at
it, but inevitably we reach corner cases where it's impossible.

If you think it might make sense to have everything in
libdir/pkgconfig (depite the redundancy of information), I'd be very
happy.
If instead you go and put everything into /usr/share/pkgconfig, it
won't hurt that much for us to keep this patch downstream.

Marc-Antoine