At present it doesn't present anything useful in response to --version. Reviewing the binary, I notice the string FPC 2.6.4 [2015/08/20] for x86_64 - Linux towards the end... is this string, verbatim, accessible in e.g. system so it can be displayed as part of help/version output? I'm not interested in reconstructing it in my program, I want this specific string, including compiler date, i.e. what somebody would see if he waded in with a binary debugger.
I'm a bit concerned about binary size. The runtimes were built with -CX in fpc.cfg, nothing is imported into the single source file other than Classes and SysUtils, the project options include -CX and -XX, but even after stripping it's still 300+K.
33280 tempty.exe ; just "begin end."
33280 tempty-objfpc.exe ; added "{$mode objfpc}" which adds unit "objpas"
89088 tempty-sysutils.exe ; added "uses SysUtils"
189952 tempty-classes.exe ; added "uses Classes" (Classes uses SysUtils)
Damningly, it's full of literal text identifying itself as being from rtlconsts and sysconst... why isn't this being chopped?
You're better of using the various {$I %xxx%} directives to build this string manually:
The SysUtils and Classes units simply provide a certain size due to them having initialization and finalization sections. Take the following sizes for an empty program with various units used (i386-win32):Code: [Select]33280 tempty.exe ; just "begin end."
33280 tempty-objfpc.exe ; added "{$mode objfpc}" which adds unit "objpas"
89088 tempty-sysutils.exe ; added "uses SysUtils"
189952 tempty-classes.exe ; added "uses Classes" (Classes uses SysUtils)
[/quote]Damningly, it's full of literal text identifying itself as being from rtlconsts and sysconst... why isn't this being chopped?
Because they are used. These are simply parts that are directly or indirectly referenced due to the initialization sections of SysUtils and (mainly) Classes.
But I have to conclude that either "smart linking" doesn't exactly live up to its name, [...]
You're better of using the various {$I %xxx%} directives to build this string manually:
Thanks, both methods noted. TBH given a choice I'd be happier using the "naughty" way: either it will work or it won't work, and there will be no messing around trying to find out exactly what versions of the compiler document their support for the predefines. In practice (using grep) I see that the predefines you've given all go back at least as far as 2.6.4, while the "naughty" way appears to have come in with 3.2.0.
Adding SysUtils I get 105,528. Removing SysUtils and adding Classes I get 230,888 which is still not unreasonably unlike yours. But I have to conclude that either "smart linking" doesn't exactly live up to its name, or there's something sufficiently convoluted in the RTL/FCL that it's unable to cope.
QuoteDamningly, it's full of literal text identifying itself as being from rtlconsts and sysconst... why isn't this being chopped?
Because they are used. These are simply parts that are directly or indirectly referenced due to the initialization sections of SysUtils and (mainly) Classes.
Not by me they're not.
for no obvious reason, which is what I found particularly irritating. I'll try to work out what's going on.
The data itself exists for ages, but the __fpc_ident symbol was only added in light of the introduction of the LLVM backend.
Adding SysUtils I get 105,528. Removing SysUtils and adding Classes I get 230,888 which is still not unreasonably unlike yours. But I have to conclude that either "smart linking" doesn't exactly live up to its name, or there's something sufficiently convoluted in the RTL/FCL that it's unable to cope.
Using the Classes unit will also indirectly use the SysUtils unit.
Also smart linking is working exactly as it should. The “problem” is that both Classes and SysUtils have initialization and finalization which in turn causes quite some code to be linked in as well (e.g. the complete TComponent class even if it's not used).QuoteDamningly, it's full of literal text identifying itself as being from rtlconsts and sysconst... why isn't this being chopped?
Because they are used. These are simply parts that are directly or indirectly referenced due to the initialization sections of SysUtils and (mainly) Classes.
Not by me they're not.
Yes, they are, because you're simply using the units. As soon as a unit has an initialization or finalization section (in this case Classes and SysUtils) it must be used by the compiler and that includes linking in all code that might be required from there.for no obvious reason, which is what I found particularly irritating. I'll try to work out what's going on.
You can use -Xm to have the compiler generate a map file that contains information about which sections are referenced (at least the first reference that triggers the section to be used). You can find out this way what chain leads to the use of the resource strings.
The data itself exists for ages, but the __fpc_ident symbol was only added in light of the introduction of the LLVM backend.
Thanks, noted. However for me there appears to be a "sweet spot" around FPC 3.0.4 and Lazarus 2.0.6, the (by default) break of backward compatibility in Lazarus 2.0.8 is a killer from my POV and now that I can't even run Lazarus trunk built with 3.2.0 I think the writing's on the wall.
TBH I've long felt that Lazarus 1.0 and FPC 3.0 had synchronised as a long-term supported release, rather than muddying the water with things like OPM (in Lazarus) and generics in FPC.
I don't know what you're doing, I run Lazarus trunk with FPC 3.2.0 without any problems.
Those strings I C&Ped earlier do not appear in the minimal programs I ran off yesterday, and the program that's suddenly sprouted them does nothing out of the ordinary. But it's clear that /something/ I've put into it has caused them to erupt... I'll try to work out what later but unlike the error messages etc. visible when a program has SysUtils/Classes they're very public cruft that looks bad to anybody inclined to look.
three notes
strippimg is not debugger friendly.
-XX -Xs (or in one go -XXs) often does a somewhat better job than calling strip.
The -Xg option stores debug info in a separate file and creates a debuginfo section to use it
So I suppose the residual question is whether one of the other debugging formats allows smartlinking to proceed, and whether the IDE could (should?) choose this as the default if the local debugger (gdb etc.) is capable of using it.
As for the fpc warning, it would be an idea for the IDE to compile an empty prog, and report any warnings (each time project opts are changed)
TL;DR What I was seeing was caused by the Lazarus IDE's debugging option breaking smartlinking, which left strings imported with Classes in the final binary.
So I suppose the residual question is whether one of the other debugging formats allows smartlinking to proceed, and whether the IDE could (should?) choose this as the default if the local debugger (gdb etc.) is capable of using it.
Ah right, I forget about that, cause on Windows the internal linker can handle this correctly while GNU's ld can't.