I've a little problem: I have to open a linker file, that have .a extension. I use Dev-C++, I don't know if it would be useful for you :-P
I hope you will answer soon!
Oh, and excuse me for my bad English, tell me if I made some mistakes! Thanks!!
Ale
Try fstream, or fstream file_op("c:\\test.a",ios::in);, and dont forget to include fstream.h.
Files with the .a extension are static libraries using Unix file naming conventions. They're not much more than an indexed collection of object code. You don't so much open them (unless you've got a tool like nm or gdb available, both of which can do sensible things with a library if not necessarily what you might want) as tell the linker to use them when linking. With most linkers, it's important to put all libraries (both static and dynamic/shared) after your main program code on the linker command line and the order of libraries matters too.
.a files are ar archives (something like zip archives) of object (.o) files. You can list files in .a file using ar program:
ar t file.a
And extract all files:
ar x file.a
Do you really mean that you want to open the file, or rather that you wish to link it with your code?
Dev-C++ by default is installed with the MinGW/GCC compiler. If the archive is not specifically built to work with MinGW (for example it may be a Cygwin or Linux archive), you will not be able to link it to MinGW generated code.
If the archive is a MinGW/GCC compatible library, then you simply link it to your code. In Dev-C++ you need to add the archive to the project linker options, either by adding the full path to the archive (there's a button for that in the project options), or by placing the archive in a path defined by a -L<path> option, and then adding a -l<archive> option. Note that id the archive is called libXXX.a, then the -l<archive> option will be `-lXXX'; the "lib" prefix and ".a" extension are implicit.
If you simply want to inspect an archive to determine what external symbols it provides, then the nm utility can be used for that. If you want to extract the individual object files, then use the ar, though I cannot think of a good reason why you'd want to do either.