I am constantly using strip -s to reduce the size of the application binary and now I wonder if there is a way to make Lazarus NOT include the symbols in the first place?

It seems like these are only used when debugging and that is started by clicking the green arrow button, so Lazarus should be able to figure out when the symbols are needed (for debug) and not add them when not needed...

The reason I have for finding a way to do this is that the binary will be added to version control and then it may happen that one forgets the strip -s step before committing the state, thus sending an overly bloated binary into subversion.

Hi,

Στις 13/12/2021 10:01 μ.μ., ο/η Bo Berglund via lazarus έγραψε:

I suppose one way is to use Lazarus's build modes.

i.e.

Add a "release" build mode to your project with the settings you want including strip -s support.

Then make a script /batch which builds it using that build mode (i.e.  lazbuild with --build-mode=<project/ide build mode> or --bm=<project/ide build mode> ) and copies the "release" stripped to the relevant location ( i.e. local repocitory) before commits it .

Or if you don't want a script / batch, I think that you can add the copy functionality for that "release" build mode to the "Project Options -> Compiler  Options -> Compiler Commands -> Execute after -> Command" and leave only the build checkbox checked. With such a configuration, every time you build that mode you'll have a stripped "release" binary which will be copied to the location after the build ends .

regards,

This sounds like what I need.
I looked at the project options and found that there is one box to enter the Execute after command. And checkboxes to set when it is used.

But I would need *two* commands:
- copy to the svn location
- strip -s on that copy

Does this mean I will have to use a batch file (on Windows) to perform both steps?
How do I then transfer the name of the executable into that command?

And will Lazarus use the standard binary or the one created in the release folder when debugging?

In compiler options you can set various debugging related options as well. One is to strip symbols.
- uncheck: "generate infor for the debugger"
- check: Strip symbols from executable
You apply those debugging options to your "Release" build mode. You keep all relevant debugging options checked for your "Debug" build-mode.

Now you develop in "Debug" build-mode.
Once you're ready to release: swicth build-mode to "Release" and compile.

(You might want a "Release and copy to svn" build mode with the "Execute after command", sou you can also test your release mode build (if you use e.g. different optimizations, some yet unnoticed bug may crop up.)

On Mon, Dec 13, 2021 at 10:01 PM Bo Berglund via lazarus <

wrote: ... the binary will be added to version control ...

You are misusing a version (or revision) control system, Subversion in your case if I understand right.
Generated binaries should not be added there. It is only for source files. A revision control system stores diffs between revisions. A diff between 2 binaries is not useful information.
You can share the binaries through a file system, FTP server, web page or something like that.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20211214/6d500b78/attachment.html>

Thanks, I went there and found where I could add the release mode. I did not even need to enter a copy command because I could set the "Target filename" for Release to include the subdirectory bin. So now my Default mode saves the executable to the project dir and the Release saves to subdir bin.
This is exactly what I needed, thanks for explaining it! :)

Bo Berglund wrote

On Mon, 13 Dec 2021 22:44:16 +0100, Bart via lazarus

< snip >

< snip >

Just FYI, I usually put in the "Target filname" this :

bin\$(TargetCPU)-$(TargetOS)\$(BuildMode)\projectname

and in the "Unit output directory" this :

lib\$(TargetCPU)-$(TargetOS)\$(BuildMode)

The result is that I have a dir structure dependent on OS, CPU and BuildMode values .

i.e.

CPU=i386
OS=win32
BuildMode=debug

bin\i386-win32\debug with lib\i386-win32\debug

CPU=i386
OS=win32
BuildMode=release

bin\i386-win32\release with lib\i386-win32\release

CPU=x86_64
OS=win64
BuildMode=test_for_scm

bin\x86_64-win64\test_for_scm with lib\x86_64-win64\test_for_scm

etc

regards,

Bo Berglund wrote

This is exactly what I needed, thanks for explaining it! :)

don't you love it when a plan comes together? :)

Bo Berglund wrote

Thanks, I went there and found where I could add the release mode.

Forgot to say this about my modes creation:

When I only had a Default mode then when I clicked the [..] button there was a button to the upper left that says "Create Debug and Release modes", which I used rather than the + button to add a Release mode. This resulted in two new modes and I could set the Release one as described before to my liking.

But when I tested the new Debug and Release modes the Debug one worked in a different way from the Default mode in that it creates two files on compile, app.exe and app.dbg.
The exe file in this case is not very much different from the release exe in size, only some 10:s of kb. But the app.dbg file (wich was not present before) is quite big, larger than the exe file.

Since I did not know what to do about that I removed the Debug mode from the list and use Default when writing code and test run, then switch to Release to make the final output.

Question1:
----------
What did Lazarus do to the Debug mode it created automatically?

Next:
I also tested on a RaspberryPi project on an RPi3B (using 2.0.12 + 3.2.0): In this case I have a service application (non-GUI app), which I basically never run in the Lazarus debugger. Its mode has never been dealt with so it was the out-of-the-box default.
Now I added the Release mode by just clicking the + button and naming it Release.
Then I did as before and disbled the "Generate info for the debugger" item. I also checked the "Strip symbols from executable" box.

The result was a bit surprising:
Using Default
Binary size: 9,572,660 after strip: 4,547,712

Using Release:
Binary size: 6,311,022 after strip: 6,311,020

So in this case the original binary size was a lot larger than the stripped result from the Default mode, why was this?

And every time I now switch mode for compliling my app it also recompiles the Indy10 package, why?

Question 2:
-----------
Does my action to create the Release mode as a copy of Default using the + button affect the way the Release mode is actually configured? On my Windows project discussed earlier I used the "Create Debug and Release modes" button and then deleted the Debug mode and modified the Release a little concerning the debug and strip.
And on RPi I used the + button instead, but did the same config on debug settings.

I will need to document this behaviour and note the "correct" way to do it...

I went back to he RPi and removed the Release mode I created from the + button, then used the "Create Debug and Release modes" button to create two new modes. Deleted the Debug mode and configured Release as described above.

Now my compile results in a file of size 3,251,612 bytes and when going back to the Default mode it is (after recompiling the Indy10 package) 9,572,660

Strange...