https://sourceware.org/bugzilla/show_bug.cgi?id=28903
Nick Clifton <nickc at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nickc at redhat dot com
--- Comment #22 from Nick Clifton <nickc at redhat dot com> ---
(In reply to John B Thiel from comment #20)
> From an overall system perspective, it does not do the end-user any
> good to say, bug there not here.
Well we are not talking to users or developers, we are talking to you.
> 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.
Really ? Why not ? What if a security bug is found in the compiler ?
Plus are you saying that the FPC compiler actually manufactures a
program specific linker script on the fly ? Ie it does not just have
a script as a single file as part of the FPC package which it uses
whenever it needs to perform a link ?
If the script is manufactured, how is it manufactured ? Can it be
edited ? Could a step be inserted between the generation of the
script and the invocation of the linker which performs any necessary
transliterations ?
> 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)
Well if everything is totally fixed and unchangeable then you really
need to have a set-in-stone version of the linker too, and not be
attempting to use newer versions. Otherwise problems like this will
arise again when even newer versions of the linker are released.
> 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.
No - the breaking change was fixing a bug. We are not going to
reintroduce that bug just for you. If you want the old behaviour,
use the old linker.
> 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.
There would still need to be some way for the linker to detect if it
is handling these old legacy scripts, which would involve adding
something - either a new linker command line option or a new keyword
in the linker script. So I do not think that this alternative will
work.
> 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.
Unless of course the FPC compiler automatically adds this option for
the developer without them having to do anything.
> 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.
And we will reiterate that if the FPC 2.6.4 compiler cannot be changed
then do not change the version of the binutils that you use with it
either.
I am guessing however that you will tell me that this is not possible.
Ie that the FPC compiler cannot have its own linker and that it has to
use the system provided linker.
So, how to move forward ?
If FPC 2.6.4 cannot change, and we are unwilling to make a change in
the upstream binutils sources, then I think that you are going to have
to talk to the distributions themselves. (Is this just a Debian
problem or do other distributions support FPC 2.6.4 ?) Distribution
specific patches to the binutils are certainly possible. so maybe that
is the way to proceed.
--
You are receiving this mail because:
You are on the CC list for the bug.
