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? > 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. > > Kay Agreed about the redundancy, but what if the arm tool wants to find installed arm tools, and not x86_64? _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
