[llvm-bugs] [Bug 52384] New: start-stop-gc default change breaks multiple projects with no viable transition option
llvm-bugs at lists.llvm.org
Tue Nov 2 20:56:12 PDT 2021
Bug ID: 52384
Summary: start-stop-gc default change breaks multiple projects
with no viable transition option
Severity: release blocker
Assignee: unassignedbugs at nondot.org
Reporter: jrtc27 at jrtc27.com
CC: llvm-bugs at lists.llvm.org, smithp352 at googlemail.com
4bbcd63eea4950c38e29f9e29b1d11b7d7894469 (D96914) added a new -z start-stop-gc
to allow the existing "__start_foo retains a section called foo" behaviour to
be disabled, coordinated with GNU ld.
6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 (committed without review 1.5 months
later, within the same release cycle (13)) changed the default of this option,
thereby breaking software that relied on the old semantics.
So far that list of software is:
and 13.0.1 final hasn't even been released yet. For some projects (FreeBSD,
NetworkManager and systemd), build systems can be adjusted to add -z
no-start-stop-gc and restore the traditional behaviour. However, some projects,
like LDC, which in this case is behaving like a driver for LD and thus, just
like Clang, cannot easily know what exact linker (GNU vs LLVM, and version) is
being used at run time, and thus cannot know whether the option even exists (so
cannot just unconditionally pass it without getting an error).
I do not believe this is an appropriate way to go about this transition, and so
the default change in 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 should be
reverted, both in main and in release/13.x, until such time as a proper
transition plan is put forward, akin to how -f(no-)common was handled (except
this time the errors aren't even bugs in the software, they're "your software
was fine but needs to change because we decided that behaviour is no longer
supported by default") where the option exists for enough years before the
default is flipped such that it can just be assumed to exist and the old
behaviour requested unconditionally for projects that need it.
There is the separate issue of the fact that such a plan still breaks static
libraries that wish to use linker sets, as it's up to the consumer of the
library to decide what semantics it wants, not the library (and I cannot
foresee (a) requiring people to use pkgconf-like mechanisms (b) those adding a
-z option to LDFLAGS being a good idea).
https://reviews.llvm.org/D96914 has a lengthier discussion that lead up to this
bug report, and continues.
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-bugs