On Monday 16 November 2015 20:03:29 Yves Guillemot wrote: > I had a look to bug #1468 using the cmake debug build. > I got the crash and launched gdb with the core file. > > I was surprised to wait a _very very long_ time before getting the gdb prompt > (at first I thought gdb was bugged and running inside an infinite loop). > > To compare this time with the usual one, I recompile RG in debug mode, but > with a static link. To get it, I just comment out the if instruction around > "set(BUILD_TESTING OFF)" near line 180 of CMakeLists.txt. > > Here are the gdb startup times : > with dynamic link : 2'35" > with static link : 10" > > This times are repeatable. > > I'm running gcc 4.9.2 and gdb 7.8.1 on a 64 bits Intel Core2 Quad CPU at 2.83 > GHz with a 8 Gb RAM.
Yep, I see the same. I asked my colleagues (including the one who wrote elf-dissector and gdb-indexer, so he knows this kind of low-level stuff), but even he doesn't know why gdb would be so much slower with a shared lib than with a static lib. I have a theory though: $ nm -D $QTDIR/lib/libQtCore.so.4.8.7 | wc -l 4682 $ nm -D $QTDIR/lib/libQtWebKit.so.4.9.4 | wc -l 3112 $ nm -D $KDEDIR/librosegardenprivate.so | wc -l 54854 In *all* the libs I have in $KDEDIR/lib, the one with most symbols is libkdeui.so: 11535. rosegarden's lib is far above that. So I'll try enabling -fvisibility=hidden and adding the necessary export macros, it should at least help with this. BTW you can use gdb-indexer [1] on the lib, after that gdb is fast, but since it has to be redone every time the lib is recreated, it's useless when doing development. [1] http://www.davidfaure.fr/kde/gdb-indexer -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ------------------------------------------------------------------------------ _______________________________________________ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
