On 08/04/15 20:11, Kay Sievers wrote: > Right, we have to find out what we want to support here, cross-compile > or secondary arch things. > > Only one thing is clear at the moment, that the current status makes > no sense. :) > > We got $libdir for the secondary arch: > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=eb39a6239c631873db62f6a942e6cb3dab0a2db4 > > But then we took $libdir as the reason to move the file and make it > inaccessible for the secondary arch: > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=aec432c6134146e138124c4130be2ee89dca07fa
I think the question to be asking is, what API does systemd.pc represent? Is it the architecture-independent "drop unit files in these directories..."-style API of the systemd init system and related things, or is it a C ABI? If it's the various architecture-independent APIs (unit files, D-Bus, etc.) then $datadir/pkgconfig is an appropriate place. If it's a C API then $libdir/pkgconfig would be appropriate, but AIUI the C API is libsystemd, which already has its own separate .pc file. I don't think systemd.pc is really the appropriate place to answer the question "what is the preferred library directory for the primary architecture on this system?", because there doesn't seem to be anything about systemd that makes its CPU architecture particularly important. Yes, systemd is in a unique position because it's pid 1, so there can only be one of it; but it doesn't actually seem to *do* anything with the $libdir? For the normal libraries to which it is linked (libselinux or whatever), it relies on ld.so's configured search path rather than doing its own thing; it doesn't load plugins, which is one situation where applications might need to know the preferred $libdir themselves; and it deliberately always uses /[usr/]lib, never /[usr/]lib/i386-linux-gnu or /[usr/]lib64, for architecture-independent APIs like units and tmpfiles snippets. If I wanted to find "the primary architecture" on a particular system, I'd start by looking at the toolchain (in particular, what /usr/bin/cc produces and where it looks for libraries), the kernel, and/or the package manager (Debian-style multiarch doesn't necessarily need to have a primary architecture at all, but the de facto standard for finding the closest-to-primary architecture where needed is to look in "dpkg -s dpkg" and see which architecture it is). Similarly, when compiling software, I don't think it's the upstream developer's place to be redefining $libdir (or indeed $prefix) according to local practices. GNU-style software defaults to /usr/local/lib, which is not the most appropriate location for *any* packaging system (except possibly *BSD "ports") - but all distributions already know that, and have a standard set of configure arguments to redirect --prefix and --libdir to their preferred paths, whether that means /usr/i686-linux-gnu/lib or /usr/lib/i386-linux-gnu or /usr/lib64. It seems better for third-party software to be predictable about its installation paths, rather than for it to "do what I mean" and alter its defaults depending whether it thinks it's on a Debian or Red Hat derivative. -- Simon McVittie Collabora Ltd. <http://www.collabora.com/> _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
