[fpc-devel] fp IDE and gdbint on Debian Wheezy/testing

[Sergei Gorelkin]

On 05.11.2012 18:00, Jonas Maebe wrote:
>
> On 05 Nov 2012, at 14:40, Vincent Snijders wrote:
>
>> I found out the cause of *my* problem. The ld provided by Ubuntu
>> (version 2.22) was in /usr/bin. There was also an older version 2.21
>> in /usr/local/bin which was actually chosen. Fixing that solved my
>> problem.
>
> Yes, the default system linker's built-in linker script contains the search path for all system
> libraries. That is the reason why we don't use the "-T" option the linker complains about, because
> doing so would tell the linker to ignore the built-in linker script and hence also those
> system-specific library search paths.
>
> We could also very easily get rid of the -T warning by getting rid of all the built-in linker
> scripts in the compiler, and replacing them with just the parts that are FPC-specific (basically
> keeping the ".fpc" section), but for reasons I still don't understand some people think this would
> cause problems.
>
The current setup causes *everything* except sections (symbols, constants, etc) to be linked 
incorrectly, because the script is being executed twice, first time the built-in script, the second 
time FPC-supplied one. Fortunately, most linking is governed by built-in script, and most of 
FPC-supplied script is effectively ignored, that's why we get working executables in the end.

I've experimented with removing all but .fpc section from linker script on x86_64-linux and 
i386-linux targets, and encountered no issues. In the nearest future, I'm going to commit these 
changes, and also write a test that will fail if linking with current setup.

> The only argument in favour of keeping the compiler-internal linker scripts for Linux targets that I
> currently can think of is that it would probably make the built-in ELF linker harder to realise (it
> would probably have to ask the system linker for the default linker script then). We could also let
> the internal linker use a compiler-internal linker script and the external linker the system default
> one, but that's probably not a good idea (ideally the internal and external linker would use the
> same settings, both from a support and from a predictability perspective).
>
The internal ELF linker has been already implemented for x86 targets, it only misses appropriate 
RegisterInternalLinker calls in initialization section of t_linux.pas. It uses an internal script.
Reusing the system-default script in its entirety would require closely following ld inner structure 
(e.g. ld composes .rela.dyn section from .rela.text,.rela.data,etc input sections, while internal 
linker writes it directly), and probably is not worth the trouble. At the same time, I had to 
implement a basic parser of ld script files anyway, so partially using the system-default script for 
e.g. search paths can be done fairly easily.

Regards,
Sergei