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? 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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel