https://sourceware.org/bugzilla/show_bug.cgi?id=28903
--- Comment #20 from John B Thiel <jbthiel at gmail dot com> ---
Given that the root cause is a bug in the linker script from FPC, still the
observable end-user fact is the combination of FPC 2.6.4 + binutils/LD up to
2.35 works, and has for years. It runs and produces correct output, a working
executable. The newer version of binutils-2.36/37 does not.
So it is a change in binutils/LD version 2.36 and later that "caused" the
problem, in this sense. There were apparently offsetting bugs, where the older
binutils/LD accepted and worked with the faulty input script. By tightening
up/bugfix/improving on the binutils side, it has rendered the legacy FPC
approach inoperable.
>From an overall system perspective, it does not do the end-user any good to
say, bug there not here.
Because FPC 2.6.4 is a legacy version, the way it produces the linker script is
basically "etched in stone". The FPC team cannot release a new version in that
branch. And it is neither possible for end-user developers to customize the
link scripts on-the-fly, to my knowledge. (and even if so, would require a
very expert knowledge level beyond most developers' expertise)
So I think it is fair to consider the onus on binutils/LD developers to make a
compensating change, to maintain backwards compatibility. Because the breaking
change has been introduced on this end.
As I see, a couple options:
1) You could rollback or relax whatever got fixed/tightened in
binutils/LD-2.36, so it still fully accepts the legacy linker scripts produced
by FPC 2.6.4. This would be most preferable from an FPC end-user perspective,
requiring no change in usage.
2) If accepting the faulty linker script in LD is considered very troublesome,
like a security hole for example, you could put the backwards compatibility on
an option flag. This would allow usage from FPC via its flag
-k<x> Pass <x> to the linker
This is not ideal for FPC devs, because they will encounter the segfaulting
executable, and have to research this problem, and update their build
parameters. But at least it provides some workaround, so legacy applications
remain buildable.
3) Additional options, suggestions... ?
I stress again, this incompatibility between LD / FPC completely breaks the
entire FPC 2.6.4 series toolchain, which is a giant stack of high quality
software, including a comprehensive LIBC equivalent, plus cross-platform GUI,
which is widely used for custom business, industrial, scientific, and gaming
applications.
You do not necessarily hear about these applications because they are in
specialized fields. FPC/Lazarus developers and their customers just install
some version of Debian, etc and deploy their app. Also, 1) many of these
developers and applications might not be well-connected with the open-source
community, or use Windows, etc. and 2) most Linux distros are still using the
older versions of binutils. This won't start majorly affecting downstream
until the mainline Debian/Ubuntu, for example, goes past 2.35. It's a
potential tidal wave of damage waiting to happen.
SUMMARY: Binutils/LD is the only working linker for FPC 2.6.4 series toolchain.
It is a relatively tiny piece of a huge stack, and has changed in a way which
systemically breaks the compiler and every single application developed with
it. Backward compatibility is crucially needed. Please find a way to support
this.
--
You are receiving this mail because:
You are on the CC list for the bug.
