[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Profiling a library built with libtool
From: |
Joseph Wakeling |
Subject: |
Re: Profiling a library built with libtool |
Date: |
Fri, 13 Jul 2007 18:16:20 +0200 |
User-agent: |
Thunderbird 1.5.0.12 (X11/20070604) |
Bob Friesenhahn wrote:
> It is important to know that profiling is based on both adding special
> code to functions during compilation (influenced by CFLAGS), and use of
> a special startup-module for linking. That means you should add -pg to
> LDFLAGS as well. Profiling will be easiest to deal with in a static
> build (might be a firm requirement). If adding -pg to LDFLAGS does not
> help, then it is quite possible that libtool itself has a bug. Watch to
> make sure that libtool is supplying this option to the linker (or
> compiler if it is used as the linker).
Thanks very much. :-)
Adding -pg to LDFLAGS doesn't help although I think you were right that
previously it was not being passed to the linker. The code is threaded
and I don't know if that might affect things.
Further, there's a slightly bizarre result in that in testing I was able
to run the program in such a way as to control some of the internal
calls that should be made, and functions showed up on the profiling list
that _shouldn't have been called_, while ones which _should_ have been
weren't. (I'm talking about functions in the executable, not the
library, the latter are still unseen by the profiler.) I don't know if
that might be an optimization going wrong ... ? (I'm only using -O2).
If this _is_ a bug in libtool then I would like very much to help in
tracking it down, so any advice here is welcome.