I had tried in remote times to activate the "use external gdb debug symbols file" option, and it didn't work properly, so I forgot about it. But some time ago I tried again, and now it turns out to work perfectly, at least under Linux.

Wouldn't it be nice to set it active by default?

This could make unnecessary in many cases a different build mode for testing and for deploying, and would stop the complaints about "long executable".

Giuliano

External debug symbols file?

+1 for ON default

Giuliano Colla wrote

Wouldn't it be nice to set it active by default?

Alexey wrote

External debug symbols file?

No, please.

Bart

Il 20/05/2017 13:20, Bart via Lazarus ha scritto:

> External debug symbols file? No, please.

Why?

Giuliano

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20170520/2148cd01/attachment.html>

1) It would need a lot of testing.
- On ALL platforms.
- With lots of different versions of gdb
- and with fpdebug
- and with -gl (dump line numbers in traces)
- and with the IDE tool "Leaks and traces", the button "resolve"

2) The statement "make unnecessary in many cases a different build mode..." is wrong.
If you are serious about developing or teaching to do so, then I see no case where this applies.
Debug mode still needs -Criot -gt -gh and assertions, and maybe others.

---------------------
Also people complain about the size of a debug free exe too. So the problem persists, yet with less people complaining.

Anyway the issue is not to change the size of the debug exe, the issue is to make sure people realize that there is debug and release (so the benefit from -Criot... in debug too).

If you have ideas how to highlight them better...
Maybe the debug mode can be set to create it's output in a folder named debug? Then people who look at the exe will be forced to notice (well, some may notice the obvious, others may not)

Giuliano Colla wrote

>> External debug symbols file? > No, please. Why?

1. I regularly deploy applications with debug info.
2. There are reports (or at least I remeber seeing them) that antivirus programs tend to barf on external debug files.
3. Any serious developer should have a debug and release mode for anything he releases, which would make the "why are my executales so big" discussion a bit obsolete.
4. The "why are my executales so big" is in the FAQ, just refer people to the FAQ, don't discuss with them.
5. I don't like it when you alter default settings for compilation/linking.
6. I don't like changes (unless introduced by me) in general.
7. I'm out of arguments right now.

Bart

Il 20/05/2017 14:04, Bart via Lazarus ha scritto:

I'm afraid that there's a big misunderstanding (which also explains Martin's answer).

I wasn't suggesting to make the external debug symbol file the default Lazarus behaviour, removing the flexibility which is currently provided.

I was just suggesting to change the default of the "external debug symbol file" checkbox from *unchecked* to *checked*, when you start a new project. This would provide a new user a better experience, before he learns how to take advantage of different build modes, and gets acquainted wit all the extra options available to generate debug and production compiler switches.

The default checkbox settings are intended to provide users with a minimum starting point, and to suggest some reasonable options. External debug symbol file is one of them, IMHO.

Giuliano

I also agree with "Use external gdb debug symbols file" being ON by default for a new Lazarus project.

Unless of course some debug info formats didn't support it, which would raise other questions.

This is only a default option for new projects, which would affect mostly new users or quick test projects, where it should always be beneficial to keep executable file small.

Denis

Giuliano Colla wrote

...would stop the complaints about "long executable".

How about strip -s <filename> as a post-compile step before shipping?

Il 26/05/2017 23:14, Bo Berglund via Lazarus ha scritto:

That way you erase the debug symbols. If later a user complains about a bug, or about a supposed bug, you're forced to recompile everything, and if something has changed in between, you can't tell what's the cause of the trouble.

If you keep the debug symbols in a separate file, you have the best of both worlds. You may choose whether to ship debug symbols or not, you may debug again exactly the same binary you shipped, you may ship later the debug symbols if you need to have someone debug on the field, etc. etc. It's just a compiler flag you never need to change. Then it's up to you to decide what to ship and what to keep.

Giuliano