[systemd-devel] [PATCH 1/2] build-sys: merge libsystemd-login into libsystemd

[Simon McVittie]

On 20/01/14 17:08, Lennart Poettering wrote:
> On Mon, 20.01.14 17:42, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
>> Anyway, I don't see why using gold would be bad.
> 
> Good question. I have no experience with gold, but it's commonly
> available these days, right?

"Sort of; hardware-dependent". It's better than it used to be (initially
x86-only); among the Debian architectures, it exists on the x86, ARM,
PowerPC and Sparc families, but not mips*, s390x, ia64 or various
unofficial ports. I don't know which one new architecture families tend
to bootstrap with.

> maybe we should just default to gold anyway
> after detection in configur.ac?

Choosing a default linker seems like a system-integration issue rather
than something individual upstreams should be doing. For a while, D-Bus
forced particular "hardening" compiler options if they existed (-fPIC,
etc.), but they were often broken on particular
architectures/toolchains, and we eventually came to the conclusion that
it's far easier for a distribution to do that sort of thing correctly
than it is for an upstream to do it.

If it was my library, I'd be inclined to provide a .pc file for the old
name, that directs API users to link to the library under the new name
(source/API compatibility, but not binary/ABI compatibility); then it's
just like any other SONAME transition, in which you have to keep the old
binary package around until everything depending on it has been rebuilt.

Distributions have to be pretty good at "recompile everything that
depends on libfoo" anyway ("binary non-maintainer uploads" or "binNMUs"
in Debian jargon). If it's a simple recompile, it's easy to automate,
but if source-code changes are needed (even just configure.ac), then
someone needs to edit the source packages and it becomes considerably
more work.

    S