Hi,
What's the safest way of making the .exe smaller than default? Is it just to strip debug info?
How would I do this?

Thanks in advance

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120428/4b4049a2/attachment.html>

Richard Mace wrote

Hi, What's the safest way of making the .exe smaller than default? Is it just to strip debug info? How would I do this?

Perhaps this will give you some ideas?
http://wiki.lazarus.freepascal.org/Size_Matters#Incorrect_compiler_configuration

... you can either not generated debug info at all or generate external debug info (.dbg)...

Regards,
Reinier

Thanks, I'll try with the -Xg switch

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120428/e52d3aa9/attachment.html>

my DAU method is in terminal on linux

strip --strip-all ./MyApplication
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120428/77571fae/attachment.html>

my DAU method is in terminal on linux

strip --strip-all ./MyApplication

strip.exe for Win is part of your fpc bin directory:

/lazarus/fpc/2.5.1/bin/i386-win32/strip.exe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120428/9906200b/attachment.html> -------------- next part --------------
An embedded and charset-unspecified text was scrubbed... Name: Attached Message Part
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120428/9906200b/attachment.ksh>

Would this be instead of the -Xg switch or as well as? Or does it do the same thing?

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120428/27f62b3b/attachment.html>

Is there any reason why the -Xg flag is not on at default? What's the disadvantage of using this flag? The reason I say is because there is a "massive" reduction in .exe size?

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120428/d478dc2c/attachment.html>

Yes, that's what I wondered about too.

What's the problem with the .exe size when compiling with debug info? If one compiles with debug settings, one usually wants to have the debug info? If not, don't use debug settings.

What's the problem with the .exe size when compiling with debug info? If one compiles with debug settings, one usually wants to have the debug info? If not, don't use debug settings.

Well, the problem is the size of the exe file. ;-) When I am working on a project I usually want to generate debug information for debugging.
But when I give the generated file to someone else I surely do not need this information in the exe file anymore.
So why should I be forced to search for ways to delete this information from the exe if there could be a way to avoid this hassle?

There is no need to search for ways to delete this information, you need only a proper workflow: exes compiled for distribution shall be compiled with release settings which means:
- no debug info
- symbols fully stripped
- full optimization (which would make debugging harder)
- asserts ignored
- custom debug code ignored
- ...
Using debug and release settings is something very basic when working on software being deployed to others.

Florian Kl?mpfl wrote

Using debug and release settings is something very basic when working on software being deployed to others.

I fully agree. MSEide has project setting groups where you can define debug and release settings. Lazarus IDE I believe now has such functionality too in Trunk. This is even possible from the command line using something like:

fpc @debug.cfg myproject.pas
fpc @release.cfg myproject.pas

The 'debug.cfg' and 'release.cfg' are simply text files with compiler settings (one per line).

Probably it is simple less tested, and therefore it is unknown if in works in all situations.

Also, I guess it is more error prone. Compile with external debug, then make changes, recompile but with release settings. Then you have an outdated debug info file, and if you happen to run that in the debugger, you get a lot of strange things....

Well, most people need 2 build profiles anyway.

For when I debug I have -Crio -O1, heap trc and other flags. On release I have -O2, and no -C...., no heaptrc...

Give the executable different names. When debugging, the exe name is irrelevant since the application will be started by F9.

DoDi

Then you can always generate 2 exe too. One with and one without dbg info... If you generate, the 2 exe individually, people may debug their latest changes, and then ship the release exe, from the day before....

I am not saying, that external debug info could not be made default. And neither do I say, that the current solution has no problems (it obviously has)

In fact I think it would be great if it could be changed to use external dbg info (assuming it is done right).

Just pointing out, it is probably not as easy, as just a new default for that checkbox.
- Test it on various platforms, cross compile, remote debug, .... (ideally add to the debugger test suit)
- Test it for projects with starter/host application (debug libraries with external info)
- different gdb versions (at least 7.0 to 7.4 / 6.3.50 on Mac)
- implement checks in the IDE so no old file will be used accidental (different name; or remove/rename old dbg info file)

Maybe other things I haven't thought of.

In any case, while nice to have, it is nothing I am going to bother about. There is plenty other, that I find more important.

>> Is there any reason why the -Xg flag is not on at default? What's

the disadvantage of using this flag? The reason I say is because there is a "massive" reduction in .exe size?

>> > Yes, that's what I wondered about too. Also, I guess it is more error prone. Compile with external debug,

then make changes,

recompile but with release settings. Then you have an outdated debug

info file, and

if you happen to run that in the debugger, you get a lot of strange

things....

Realy? If you compile without (external) debug info can you still run the debugger from the IDE?
If yes, this has to be disabled of course.
If not, then there is no danger that an outdated debug info file can be used.

Again, not that simple.

Currently, I can start the app (without debug info) by pressing F9. Just as a way to run it. Not to debug it.
So if that was no longer possible, then alternate means need to be created, to just run (there is a feature request for that already)

But *IF* such a check would be added.....
the appropriate way for the IDE to check is not to see, if the last compile did have dbg info. It is to check, if the debug info is available.

Example: I often use the "Run Param" > "Host App" to debug a different version of the executable. It works perfect. Of course that still works, even if the last compiled exe has no debug info.

And one can also compile the project outside the IDE, and debug it in the IDE .....

And, of course that makes it even more complicated: because if I debug a dll, I might have a project loaded that does uses the dll. I would have to test, if the debugger can use the dll's debug info, if the host app has no debug info.... (I do not know)

-----------
Again, yes the situation can (and need/should) be improved. But again: not that simple.

While I am personally ambivalent about the default state of -Xg switch, I'd like to point out another use case where it matters: compiling on Windows on slow machine with antivirus installed.

When I tried to persuade my students to switch to Lazarus from Delphi, I've got many complaints about Lazarus being too slow. About a third of these complaints were fixed by either excluding Lazarus directory from AV's monitoring list, or turning -Xg on.

Sorry, I might have missed this, but what would be the main disadvantage for a newbie of having the -Xg switch don't really understand about the difference between having the debug info internal to the .exe or external, and I am guessing that the majority of people coming to Lazarus won't either. I just think the more people will be complaining about the default size of the .exe as apposed to having the debug info stored externally, unless I am really missing the point (quite possibly).

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120430/d08ac9a3/attachment.html>

AV software tends to affect Delphi and its compiled projects, too. It's not a good idea to use AV software on a Windows development machine.

DoDi

for a newbie of having the -Xg switch on at default.

I don't really understand about the difference between having the debug

info internal to the .exe or external, and I am guessing that the majority of people coming to Lazarus won't either. I just think the more people will be complaining about the default size of the .exe as apposed to having the debug info stored externally, unless I am really missing the point (quite possibly).

The main disadvantage is that -Xg is rather untested (especially considering the things that Martin wrote about the IDE) so in the end it might be less "newb friendly" than the debug info included in the executable (co.Audrey questions like "why can't I debug anymore?").

Also AFAIK FPC's lineinfo units (for both Stabs and Dwarf) don't work with external debug info (I don't remember exactly so this needs to be tested).

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120430/3b94c31c/attachment.html>

Hans-Peter Diettrich wrote

AV software tends to affect Delphi and its compiled projects, too.

Yes, but in recent years Delphi was included in "safe" lists of most AV products.

It's not a good idea to use AV software on a Windows development machine.

It is also not a good idea to use Windows on a development machine :) However, we live in imperfect world.

Martin wrote

.... Then you have an outdated debug info file,

The "release" build could just delete this file (provided it's there where a corresponding "debug" build would create it).

-Michael

Alexander Klenin wrote

When I tried to persuade my students to switch to Lazarus from Delphi, I've got many complaints about Lazarus being too slow. About a third of these complaints were fixed by either excluding Lazarus directory from AV's monitoring list, or turning -Xg on.

Dud you not try to persuade them to use Linux (where Viruses are no big problem) . :-)

-Michael

Please don't oversimplify a release build. At least one other difference is smart linking. You shouldn't smart link for debug purposes, but it would be a good idea to smart link for release. Also optimizations should be turned of for debug while they should (or at least could) be enabled for release.

It helps to have several checks (overflow, range, etc.) on during debug too, but not for release.

It is (or should) not simply (be) a matter of debug info.

In that light I find the big exe even good as it gets users to find out why and think about debug/release builds. If they simply ship a "debug" exe (without actual debug info) they might still find bad things like slow performance etc, which might be caused by enabled checks and/or missing optimizations.

I think you have to understand the full package to properly build release ready software. And a far too huge size might be the best indicator that something isn't right yet :-)

This is interesting, I'd had never actually thought of a work flow like this. So, would you have 2x different projects? 1 with as dubug and the 2nd as release, or is there a better way of doing it?

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120430/8bb5405c/attachment.html>

2012/4/30 Richard Mace :

This is interesting, I'd had never actually thought of a work flow like this. So, would you have 2x different projects? 1 with as dubug and the 2nd as release, or is there a better way of doing it?

There are build modes. There is a page in the project options dialog where you can set up different build modes and each can have different settings. There is also a toolbar button in the IDE main window to change the currently active build mode. The UI to configure the build modes is not yet as intuitive as it could ideally be but it works.

Bernd wrote

There are build modes.

In fact I do understand that I can create build mode variables (macros) that can be checked with "{$if" in the source code, but I don't know how to use those to select different compile options (such as smart linking, optimizing or debug info creation).

-Michael

Build modes are not macros.
You can read here to know more about build modes:
http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Build_modes

Regards,
?ilvinas