Hi. I wanted to use gprof to profile a binary of mine that has performance problems. I'm trying to recompiled the fpgui framework and the program with -O- and -pg but the framework fails at the linking stage.

Linking target/fpgui-framework
bootstrap_program.pas(126,1) Warning: "crtbegin.o" not found, this will probably cause a linking failure
bootstrap_program.pas(126,1) Warning: "crtend.o" not found, this will probably cause a linking failure
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libc_nonshared.a(atexit.oS): in function `atexit':
(.text+0x7): undefined reference to `__dso_handle' /usr/bin/ld: target/fpgui-framework: hidden symbol `__dso_handle' isn't defined
/usr/bin/ld: final link failed: bad value
bootstrap_program.pas(126,1) Error: Error while linking bootstrap_program.pas(126,1) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /data/devel/fpc-3.2.2/x86_64-linux/bin/ppcx64 returned an error exitcode

Any ideas? I then did a google search and Gemini came back with this:

The -pg (gprof) flag doesn't work well with Free Pascal — it tries to link against C runtime profiling infrastructure (crtbegin.o, __dso_handle) that FPC's linker setup doesn't support.

Is this true?

Regards,
Graeme

Yes, it is...

Michael.

mailinglists--- wrote

Hi. I wanted to use gprof to profile a binary of mine that has performance problems.

Have you considered valgrind (tool callgrind) and kcachegrind?

It takes a bit (actually significantly) longer to profile/run the app. But the results are usually very informative.

Martin Frb wrote

Have you considered valgrind (tool callgrind) and kcachegrind? It takes a bit (actually significantly) longer to profile/run the app.

Thank you. Yes, that's what I did in the end. It massively slowed down my app, so not sure how accurate the results are, but its better that manual GetTickCount64 everywhere. :-D

Regards,
Graeme

I found a solution - at least on my Ubuntu 24.04 system.

Add "-Fl/usr/lib/gcc/x86_64-linux-gnu/13" to the compiler options (your application or global). The ~/.fpc.cfg had -Fl/usr/lib but that was obviously not extensive enough to find the GCC libraries FPC needed.

And gprof is back in action! :)

Regards,
- Graeme -

Can you please add an issue to the bugtracker:

We should probably scan /usr/lib during installation for this path and add it to the default generated fpc.cfg

Michael.

mailinglists--- wrote

And gprof is back in action! :)

May I be so curious to ask how the results compared to valgrind?

I know that they wont give you "per line", that isn't what I try to ask though. What I mean is, does it point to the same set of routines, with roughly similar time slices attributed to them?

Op 22-3-2026 om 01:06 schreef mailinglists--- via fpc-pascal:

I found a solution - at least on my Ubuntu 24.04 system.

Was that a package manager installed version of FPC? That should have run samplecfg to detect it.

Michael Van Canneyt wrote

Can you please add an issue to the bugtracker:

Done.
https://gitlab.com/freepascal.org/fpc/source/-/work_items/41675

Regards,
G.

Marco van de Voort wrote

Was that a package manager installed version of FPC? That should have run samplecfg to detect it.

I initially had FPC 3.2.2 installed via Ubuntu's package manager, but I then had issues switching between FPC 3.2.2 and FPC 3.3.1. So I uninstall the packaged version. Cloned the repos and compiled my own. I recall using samplecfg to generate the initial fpc.cfg, which I then moved to $HOME and tweaked the version string so I can easily switch between the two FPC versions, but use the same ~/.fpc.cfg file.

Regards,
G.

Martin Frb wrote

May I be so curious to ask how the results compared to valgrind?

I went back to the same commit and retested with Valgrind. The profiling results were very close: 84% (gprof) vs. 80% (Valgrind) of call time spent in one method. Both reported the same overall issue. Valgrind also listed other methods, but they primarily lead up to the actual performance culprit. Overall, I felt gprof provided clearer results.

The biggest difference, however, was performance. With gprof, the application runs normally; I couldn't visually observe a noticeable runtime difference compared to when profiling is disabled. With Valgrind, it’s like playing a game at 2 FPS vs. the normal 60 FPS. It is nearly unusable in comparison.

Regards,
- Graeme -

Well, about what I would have expected. I don't know gprof, never took the time to set it up, but I am using valgrind.

I would expect gprof to have less granularity, so it will concentrate on the big issues, which is ok.
What I like with valgrind is, that sometimes I can even get results for individual lines in a routine.

Don't know if you know, but in case, if you ever need it, one useful trick: Start valgrind with profiling disabled. then enable it just before you start the code that needs to be profiled, and disable it as soon as it finishes (well yes, that means a few minutes of eager waiting). But that way you remove any other execution from the result.