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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
