01-22-2007 03:09 AM
aCC -Wl,-m myfile.c
This will output a map on stdout.
01-22-2007 05:28 AM
that will tell used runtime libraries (and more).
01-22-2007 06:51 AM
01-22-2007 03:03 PM - edited 10-21-2011 05:32 PM
Why would you want to use -m?
You can get this info from elfdump(1):
$ elfdump -S -h a.out
You can use aCC +help or the following for aC++ help:
If you want to display the objects/libs you are linked with: -Wl,-t
>Clay: Essentially that means that you have to turn on some compiler options to make the code relocatable. In HP-UX, .so's are more often .sl's
The default on IPF is PIC, so no options are needed. Also on IPF, you should name your shlibs as .so, not the the PA convention of .sl.
>nm will dump the symbol table of an object file, library, or executable.
elfdump -t is the correct tool to work on shlibs and executables, if you are using tricky linker options:
$ elfdump -s -n .dynsym a.out
01-23-2007 02:11 AM
Rather starting a new thread, I would like ask here, this is regarding stack trace. I know there are a macro we can use U_STACK_TRACE, just wondering if there are any other ways ? I have a program which crashed very strangely. I don't know the signal would be when it crashes. I tried SIGQUIT, but it wasn't. What I would like to do is whenever it crashes, it creates a stack trace. Any suggestions ?
01-23-2007 01:41 PM - edited 10-21-2011 05:32 PM
>I don't know the signal would be when it crashes. I tried SIGQUIT, but it wasn't. What I would like to do is whenever it crashes, it creates a stack trace.
You can use a debugger to figure out the signal. Also "file core" should tell you the signal.
You could call U_STACK_TRACE() from your signal handler. You must arm your handler for the signals you expect to catch. The latest version of libunwind will print the signal #.