https://sourceware.org/bugzilla/show_bug.cgi?id=28903
--- Comment #24 from John B Thiel <jbthiel at gmail dot com> ---
(In reply to Nick Clifton from comment #22)
> (In reply to John B Thiel from comment #20)
>
> > 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 ?
As I understand, because of resource constraints, they cannot support this
version anymore, and will not release any further updates. I consider this
very unfortunate, but it appears to be a hard reality. This version was last
of the 2.x series, and has been super reliable for me, for many years.
> 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 ?
Yes, it generates a custom link script on-the-fly, and executes it when
building an executable. As in my demo attachment above, you can see the link
script by using these flags:
-sh Generate script to link on host
-st Generate script to link on target
With '-sh' flag for example, it just compiles into .o files, and generates
ppas.sh and link.res files, which you can run manually, and inspect to see the
exact linking process.
The script is generated line-by-line via code in the compiler. There is some
conditional logic around platform, cpu, compilation mode, what libraries are
being included, etc.
So it needs recompiling the compiler to alter this.
It is definitely not a single boilerplate file you can just swap in.
Code for this generation appears in
/usr/local/fpc-2.6.4/src/fpc-2.6.4/compiler/systems/t_linux.pas
> Could a step be inserted between the generation of the
> script and the invocation of the linker which performs any necessary
> transliterations ?
I think it would be extremely unwieldy and fragile to post-process the script
like that, and it replicates what the compiler already does.
> > 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.
>
While I understand, even agree, with that position, there is also a
long-established tradition of maintaining backward-compatibility in
applications.
Especially a tool like LD linker, which by definition does essentially nothing
useful on its own. It basically exists to serve the many clients -- compilers
and application platforms that rely on it. FPC 2.6.4 was a major client
relying on it, which you are now disregarding, and consequently wholly
breaking; not just some rare outlier case, but every single application.
You frame the recent changes in 2.36+ as a bugfix, which presumably they were,
and someone benefitted. But it's not good service to FPC 264, that's for sure.
From that point of view it's 100% breakage, not a bugfix.
It doesn't matter if the FPC link script was "plainly and obviously broken",
per Alan. The actual fact is, it wasn't broken, because it worked!
And this FPC 264 version works very well on other platforms, on legacy
platforms, old versions of Windows, OSX, etc. It just works. Except now it
doesn't work on Linux because of the binutils/LD change.
To my mind, this is a situation where backwards-compatibility ought be
considered.
Then it's a question of how difficult and much work it would be on your end.
>
> > 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.
Is there a version id in the LD script/response files currently? If not, could
one be added, and then everything without a version would be deemed 2.35 and
older (or whatever a good cut point is).
This would also enable you to support other backward compatible concerns in
future with other clients.
To generalize this point: is there a defined standard for the linker
response/command language? Then both linker and compilers can be working to
the standard, instead of having to chase each other.
And then the linker can more easily and definitively support multiple versions
of the command language, including support for backward-compatibility, errata
and special cases like this, instead of the ever-moving-target of "latest
version".
> 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.
>
> 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.
I have likewise considered trying to patch in the older binutils, as another
absolute last ditch solution.
FPC has a provision for invoking a custom linker, via flag:
-XP<x> Prepend the binutils names with the prefix <x>
Along this line, I would build my own private version of binutils, and use the
linker in there.
I have no idea yet if this is actually possible, and how it would interact with
the system binutils. It seems fraught with complexities and hidden problems,
and extremely onerous and heavyweight. But it might end up being the best/only
solution here.
This general idea is indeed what FPC has moved to -- they have an internal
linker which is used on some platforms, and even Linux in later versions. So
it is tightly coupled with the FPC version.
Currently, on Gentoo, I can have multiple binutils installed simultaneously,
and use the 'eselect' utility to switch between them. But only one is ever
visible at a time. And it is a rolling platform, so binutils-2.35 will
eventually drop out.
> 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.
This issue has almost nothing to do with distros, except that the working
binutils-2.35 is still avail/mainline in most of them, but will be rolled away
soon.
FPC is by design an almost self-contained cross-platform ecosystem with very
few dependencies. On other platforms FPC uses its own internal linker, and I
believe also on Linux they have moved to that in later versions.
--
You are receiving this mail because:
You are on the CC list for the bug.
