4

I created a .A and a corresponding .dll file from mingw. This is to be run on windows. Now I am attempting to interface and use the function in the .A library from a different component and I am getting a linker error. I wanted to make sure if my functions were exported properly. I therefore followed this link and decided to do this

> lib.exe /list libSomeLibrary.a

as a result I get something like this

d001861.o
d001862.o
d001863.o
d001864.o
d001865.o
d001866.o
d001867.o
d001868.o
d001869.o
d001870.o
d001871.o
d001872.o
d001873.o
d001874.o
d001875.o
d001876.o
d001877.o
d001878.o
d001879.o
d001880.o
d001881.o
d001882.o
d001883.o
....
....

Is this correct. Is there a way for me to actually get the names of the functions in the lib file.

Community
  • 1
  • 1
MistyD
  • 16,373
  • 40
  • 138
  • 240

2 Answers2

4

Since you are using MinGW, you may use the nm command to list the contents of any libfoo.a archive file; used thus:

nm -A libfoo.a | more

(or better still, if you have the less command, e.g. in MinGW's MSYS shell environment):

nm -A libfoo.a | less

it will list all symbols specified within the archive, grouped and qualified by the name of the embedded object file which provides each one.

Keith Marshall
  • 1,980
  • 15
  • 19
1

A .a library file contains a number of individual object files combined together into a library archive. It is the individual .o object files which actually contain the symbols and code.

You should be able to use the dumpbin tool to examine a library on Windows systems. The /exports option should show exported symbols. I don't have any experience with this tool but the page above implies it should be able to operate directly on windows lib files.

You state you are using MingW which comes with GNU Binutils, including nm and objdump, both of which can be used to examine object files. To use these tools you might find it more convenient to extract the .o files from the .a file, which you can do using the ar command. If you don't do that then it will list all of the information in all of the object files within the archive.

Example (shown on Linux system but these tools should work the same in Windows if using MingW):

Extract corefile.o from libbfd.a

$ ar x /usr/lib64/libbfd.a corefile.o

Examine global (external) symbols in corefile.o

$ nm -g corefile.o 
0000000000000000 T bfd_core_file_failing_command
0000000000000030 T bfd_core_file_failing_signal
0000000000000060 T bfd_core_file_pid
                 U bfd_set_error
0000000000000090 T core_file_matches_executable_p
                 U filename_cmp
00000000000000d0 T generic_core_file_matches_executable_p
                 U _GLOBAL_OFFSET_TABLE_
                 U strrchr
harmic
  • 28,606
  • 5
  • 67
  • 91
  • No need to extract the object files from `lib*.a` archives, when using either `nm` or `objdump`; both work equally well on `*.a` archives, (although `objdump` may be excessively verbose, since it will disassamble every object in the archive). To list the embedded object files, *and* their symbols, just use `nm -A libfoo.a`, and pipe the output through `more`, (or better still `less`, if you have it), to read it more easily. – Keith Marshall Apr 25 '15 at 00:35