On Wed, Apr 8, 2015 at 8:10 PM, Marc-Antoine Perennou <marc-anto...@perennou.com> wrote: > 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.
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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
