I need to gprof a library in our system to examine the function calls and see if we can optimize it any more. Basically, what I have is
Executable A which uses a shared Library myLib.so
I want to gprof the myLib.so. When I compile myLib.so source using -pg option, it produces a .so file just fine.
But, recompiling the Executable A against that library is not producing the *.gmon file for some reason. What needs to be done? Should I link the myLib statically? If so, please tell me how. I am a newbie, so pardon my ignorance. I am learning everyday
thanks in advance.
You can do better than gprof.
You could use a good sampling profiler like RotateRight/Zoom, or you could try this technique. Also lsstack serves well. pstack does too, but is more work for you.
I have the same issue, but I think the best thing to do is to create a small C/C++ program that uses the library with some test calls, compile it with the library using -pg, and profile that.
That way you nicely isolate the profiling issues of the library from other stuff, too.
As http://sourceware.org/binutils/docs/gprof/Implementation.html and https://stackoverflow.com/a/7290284/885650 point out, you need -pg when linking, as it adds extra code everywhere.
Related
So on my current computer I Have a library to use BLAS functions, but I need to run my c++ program on an external server. I know how to transfer files to the server, but I'm having trouble figuring out how to find my blas library that's on my current computer and then how to link it to the compiler.
So here's the command I use current on my computer g++ program -lblas
And this works great. I run the program and everything is swell. How do I move this library to the external server?
Ideally, I'd like to move this library to the same folder as where my program resides and then link the compiler to that library somehow. Does anyone know how to do this?
If it helps, I know how to download a blas library and get a ".a" file out. I have no idea what to do from there though.
Never mind, simple question. I thought it was a lot more complicated.
For anyone that stumbles upon this, here's what you do:
Get your .a file. For me, I downloaded all the Makefile components necessary to make the .a file from here for blas: http://www.netlib.org/blas/
Next, put it in the same folder as your program if you want to do what I'm doing.
Finally, the command! Compiler, code, library
For me, this was g++ program.cpp blas.a
How can i compile my app linking statically glibc library, but only the code needed for my app? (Not all lib)
Now my compile command:
g++ -o newserver test.cpp ... -lboost_system -lboost_thread -std=c++0x
Thanks!
That's what -static does (as described in another answer): unneeded modules won't get linked into your program. But your expectations on the amount of stuff which is needed (in a sense that we can't convince linker to the contrary) may be too optimistic.
If you trying to do it for portability (running an executable on other machines with older glibc or something like that), there is one easy test question to see if you're going to get what you want:
Did you think of the problem with libnss, and are you sure it is not going to bite you?
If your answer is yes, maybe it makes sense to go on. If the answer is no, or the question seems too obscure and there is no answer, just quit your expirements with statically linked glibc: it has more chance to hurt than help.
Add -static to the compile line. It will only add what your application needs [and of course, any functions the functions you application calls, and any functions those functions call, including a bunch of startup code and some other bits and pieces], so it will be around 800K (for a simple "hello world" program) on an x86 machine. Other architectures vary. Since boost probably also calls the standard library at least a little bit, it's likely that you will have more than 800K added to your appliciation. But it only applies functions used by any of the code in the final binary, not the entire library [about 2MB as a shared library].
If you ONLY want link glibc, you will need to modify the linking line to your compile to:
-Wl,-Bstatic -libc -Wl,-Bdynamic. This will prevent any other library from being linked statically [you sometimes need to have more than one of these statements, as sometimes something pulled in by another library requires "more" from glibc to be pulled in - don't worry, it won't bring in anything more than the linker thinks is necessary].
I'm having some problems with a large static library (.lib) file, and am suspecting code bloat from indiscriminate use of template classes. I want to analyse the symbols in the library to confirm which are making up the bulk of the file size.
When I link my executable against this library, the resulting output is much more sensible, size-wise (about 20Mb), so the linker is obviously stripping out lots of redundant symbols. I want to find out what its removing..
I know I can use dumpbin to generate the symbols and headers, but, with the library in question being pretty large (900Mb), this dump is pretty much unusable without a utility for parsing and reporting on it.
Obviously I could write this myself, but was wondering if anyone can recommend any freeware already available for this?
Is this your own library? If so you can generate a link map that describes the layout of the code in the library, which would give you the info you need here in a more friendly form.
If you don't have source code access to do this, you could use Perl or other open-source scripting tools to crack the dumpbin output.
EDIT: you could also give LibDump a spin, it's downloadable from here. I have not used this myself.
I found one (SymbolSort) that works really well, gives me exactly what I need:
I know how to use g++ and all that to compile c++ programs.
My question is, if I have some code which depends on various libraries, how can I compile it into a simple executable that I can send anyone. For this I would be happy with just keeping it on os x.
I would like to know how to compile a "real" program not just an executable I can run locally.
I have tried googling this but haven't found much.
Do I have to use installing software?
I know in windows you can make some simple .exe stuff that use common DLL files.
You a looking for "static linking". That will import all the needed code from the libraries into your executable. Note the executable will get larger. If you are using standard libraries, they should be present on standard OS installation.
You should try "-static" flag of g++.
Running "ldd your_executable_name" should display all libraries your executable uses (linked dynamically).
Since you are talking about Mac OS X, you probably want to make a bundle. Qt Software has a very useful deployment guide for getting started with this kind of activity.
You can use -static or -s option for static linking in gcc or g++
I'm working on a c++ project, and we recently needed to include a small part of boost in it. The boost part is really minimal (Boost::Python), thus, using bjam to build everything looks like an overkill (besides, everyone working on the project feels comfortable with make, and has no knowloedge of jam).
I made quite some tests already, but I cant find a way to include the formerly mentioned library in my makefile and make the build succesful.
All your help is deeply apreciated. :)
You can use Boost's bcp utility to extract only the subset of Boost you need.
That will minimize your build time & size.
That doesn't answer your question, though. You may want to consider building the Boost.Python libraries separately and checking them directly into your source control system. Then nobody would need to build them.
I had the same problem and found a solution in this tutorial. You 1) need to compile the source into an object file with the -fPIC gcc option, and 2) compile this object into a library with the -shared gcc option. Of course you have also to link against the Boost.Python library (generally -lboost_python, however for my debian system it is for example -lboost_python-mt-py25, I have also to add -I/usr/include/pythyon25). In my makefile I end up doing those two steps in one command. See also p. 13 of this presentation.
If you're uncomfortable with bjam, you might want to consider using Boost.Cmake.
Alternatively you should at least be able to see more easily what they are doing then with the bjam files.
Run bjam from the makefile, just for building that part