On 8 April 2015 at 20:02, Kay Sievers <k...@vrfy.org> wrote: > On Wed, Apr 8, 2015 at 7:52 PM, Marc-Antoine Perennou > <marc-anto...@perennou.com> wrote: >> On 8 April 2015 at 19:46, Kay Sievers <k...@vrfy.org> wrote: >>> On Wed, Apr 8, 2015 at 7:34 PM, Marc-Antoine Perennou >>> <marc-anto...@perennou.com> wrote: >>>> On 8 April 2015 at 18:47, Kay Sievers <k...@vrfy.org> wrote: >>>>> On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou >>>>> <marc-anto...@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. Marc-Antoine _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
