Profiling a library built with libtool
I have a small library which is built using the GNU autotools. It also includes some executable programs which use the main library. I would like to profile the performance using gprof or another tool but have been having trouble working out how to do so. I tried simply adding -p to the CFLAGS but the resulting gmon.out appeared to contain no data (e.g. running gprof on the executable or on the .la file resulted in an error, not in executable format, while running it on one of the object files produced no information). I wonder if someone could give me a brief run-through on how to profile the library---what options I need to place in the autotools-related files and when using ./configure, and how to use gprof effectively on the library once built. Thanks in advance, -- Joe P.S. Apologies if this would be better placed on the autoconf or automake mailing list; since it's library related I assumed this would be the appropriate place. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Profiling a library built with libtool
Benoit SIGOURE wrote: The .la file is a piece of shell script that contains information useful to libtool. Now the answer to your question is to ask libtool to run gprof (or gdb) for you: ./libtool --mode=execute gprof ./foo Ah! That explains much. Thank you. I still get results that I don't understand. This is the beginning of what I get for profiling my executable: - Flat profile: Each sample counts as 0.01 seconds. no time accumulated % cumulative self self total time seconds secondscalls Ts/call Ts/call name 0.00 0.00 0.0056133 0.00 0.00 data_start 0.00 0.00 0.00 19 0.00 0.00 MG_sigma2_Theta_threaded - There's a record of calls but not of times, and _nothing_ for the library functions. The library and this executable are all built together in one big ./configure make. I don't know whether I need to do more than add -pg to the CFLAGS when building the library or whether it's simply gprof I'm not using correctly. Thanks again, -- Joe ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Profiling a library built with libtool
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. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Profiling a library built with libtool
Bob Friesenhahn wrote: The profiling support might not be thread safe. While it may seem counter-productive to program tuning, it is usually recommended to use limited optimization, or no optimization at all. I have an option for my program to use no threads and the same results were produced. Incidentally, this earlier comment, and functions showed up on the profiling list that _shouldn't have been called_, while ones which _should_ have been weren't. was a reference to that, and was incorrect. The right functions show up, just not any within the library. If I try to run gprof on the library file itself, I just get the output, /: Success Anyway, my guess is I've exhausted libtool-related queries so I'll take this over to the gprof people and ask their advice. Thanks to everyone for your helpful comments! ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Profiling a library built with libtool
Benoit SIGOURE wrote: Hmm you are right, I didn't notice during my test that I also had zeros. Build a static version of your project and it'll work. ./configure --disable-shared make clean all CFLAGS='-pg -all-static' Ahh, brilliant! Thank you ever so much. The -all-static option generates an error but I can leave it out and still get the full profile info. Problem solved! ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: C flags and headers in a C library
Noah Misch wrote: Add a line like this to Makefile.am: AM_CFLAGS = $(MINGA_CFLAGS) or simply: AM_CFLAGS = -ansi -pedantic -Wall Note that it's usually unwise to add such flags unconditionally; many compilers do not support them. Thanks very much. I hadn't thought about the compiler issue; can you suggest a conditional check that would sort this out? Alternatively, is there some way I can just request the extra flags when calling autoreconf or the ./configure script? After all, it's only really necessary for me, as the code author, to check ANSI compatibility. I thought of placing a line in configure.ac, CFLAGS=$USER_CFLAGS $CFLAGS where USER_CFLAGS is meant to be defined via ./configure USER_CFLAGS=... but I'm not sure that is an elegant or safe solution. Adding such a line is generally correct. It sounds as though the headers do not exist under the names you call them from Makefile.am. If you do generate these headers during your build process, look at documentation for BUILT_SOURCES in the GNU Automake manual. I think you're right: the main Makefile.am was unable to see the existence of the files, which are in a subdirectory. But I was able to include them via the sublibrary makefiles. A last query. When building a library, is it advisable to link to other libraries when compiling? e.g. if my library uses functions from libmath, should I compile my library with -lm, or leave that to the person creating executables linked with my library? Thanks again for all the advice and suggestions, -- Joe ___ http://lists.gnu.org/mailman/listinfo/libtool
C flags and headers in a C library
Hello, I'm a novice user of the GNU autotools trying to create the appropriate configuration for a small simulation library I'm writing, called Minga. From web tutorials, and examining configure.ac and Makefile.am files in other free software projects, I've been able to put together something that appears to allow the library to compile and install but there are a couple of things that don't work. First, I'm not sure how to add cflags and library flags to gcc as called by libtool. I've tried using AC_SUBST() but the requested flags don't show up when make is called. An example of what does show up is, -- gcc -DHAVE_CONFIG_H -I. -g -O2 -MT minga_version.lo -MD -MP -MF .deps/minga_version.Tpo -c minga_version.c -fPIC -DPIC -o .libs/minga_version.o -- when I have been trying to add the flags -ansi -Wall and the appropriate flags for the GNU Scientific Library (on which my program is dependent). Second, I can't work out how to tell the program that it should copy header files to the $(prefix)/include directory. Adding an include_HEADERS line to Makefile.am, for example, results in an error that there is no rule to build the header files. I've attached the configure.ac and Makefile.am files to this email and I wonder if anyone can advise what's wrong? Thanks for any advice, -- Joe AC_INIT([minga],[0.0.1],[EMAIL PROTECTED]) AC_CONFIG_AUX_DIR([build-aux]) AM_INIT_AUTOMAKE([-Wall -Werror foreign]) AC_LANG(C) AC_PROG_CC AC_PROG_LIBTOOL PKG_CHECK_MODULES([DEPS], [gsl = 1.8]) AC_SUBST([DEPS_CFLAGS]) AC_SUBST([DEPS_LIBS]) MINGA_CFLAGS=-ansi -pedantic -Wall AC_SUBST([MINGA_CFLAGS]) AC_CONFIG_HEADERS([config.h]) AC_CONFIG_FILES([Makefile minga/Makefile agents/Makefile anal/Makefile error/Makefile games/Makefile]) AC_OUTPUT MINGA_VERSION_INFO = 0:0:0 SUBDIRS = minga agents anal error games SUBLIBS = agents/libmingaagents.la anal/libmingaanal.la error/libmingaerror.la games/libmingagames.la #pkginclude_HEADERS = minga_agents.h minga_agent_config.h minga_anal.h minga_error.h minga_game.h minga_game_config.h minga_rng.h pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = minga.pc lib_LTLIBRARIES = libminga.la libminga_la_SOURCES = minga_version.c libminga_la_LIBADD = $(SUBLIBS) libminga_la_LDFLAGS = -version-info $(MINGA_VERSION_INFO) ___ http://lists.gnu.org/mailman/listinfo/libtool
