H
huang
Guest
i have a lib, it contain same file name .o under different dir, how can i decompress all the .o ? if use ar -x, for same file name, only one file is decompressed.
OP
JasKinasis
Guest
As far as I understand things:
When you add object (.o) files to static library (.a) files, I don't think any directory structure information is used for anything other than identifying objects, if at all. The static library file format doesn't work like compressed archive file formats, like tar, or tar.gz etc.
When you extract the .o files from the library, you can specify which objects to extract, using the original folder names - but I believe all object files are extracted to the current working directory. So if your library has several object files with the same name, I have a feeling that ar is going to overwrite the same object file in the current working directory each time.
From looking at the man-page for ar, I can't see anything that gives you the option to extract object files and replicate the original directory structure. So it looks like it just extracts the object files to the current working directory.
So, this solution probably isn't ideal, but I'd guess that you'd have to manually re-create the directory structure yourself and extract each object file individually.
As an example:
You have downloaded a static library called library.a, which contains three files called object.o - Taken from sub-directories v1/ v2/ and v3/ in the source code when it was built by the package maintainer (IDK, this is just an example!).
So perhaps the shared-library was built using something like:
For the sake of this example, we'll assume that the library itself is in ~/lib/ - a library directory in your home directory.
And you want to extract and examine all of the object files from the library in a project directory in your home directory - ~/Projects/library/
This is how you'd extract the three different versions of object.o:
1. Navigate into your project folder - i.e. where you are going to extract the object files to; And re-create the folder structure you require. You want 3 folders called v1 v2 and v3:
2. cd into the first directory (v1) and extract v1/object.o from the static-library file:
This will extract v1/object.o from the static library and put it into the current working directory (~/Projects/libary/v1/)
So your v1 folder should now have an object file called object.o
3. Repeat the above for v2 and v3:
Now you have the three identically named object files in different sub-directories in your project directory....
Having multiple object files with the same name in a library seems a little odd to me, but there ya go! If the object files were given unique names, this wouldn't be an issue, you could just use 'ar -x library.a' to extract ALL of the object files in the library into the current working directory.
I have to admit, I am not 100% au fait with ar or the static library format, so I might be a bit wrong on one or two points. But I'm pretty certain I'm correct about ar only extracting to the current working directory. Also, I haven't tested any of this out for myself - I'll leave that to you to investigate further!
When you add object (.o) files to static library (.a) files, I don't think any directory structure information is used for anything other than identifying objects, if at all. The static library file format doesn't work like compressed archive file formats, like tar, or tar.gz etc.
When you extract the .o files from the library, you can specify which objects to extract, using the original folder names - but I believe all object files are extracted to the current working directory. So if your library has several object files with the same name, I have a feeling that ar is going to overwrite the same object file in the current working directory each time.
From looking at the man-page for ar, I can't see anything that gives you the option to extract object files and replicate the original directory structure. So it looks like it just extracts the object files to the current working directory.
So, this solution probably isn't ideal, but I'd guess that you'd have to manually re-create the directory structure yourself and extract each object file individually.
As an example:
You have downloaded a static library called library.a, which contains three files called object.o - Taken from sub-directories v1/ v2/ and v3/ in the source code when it was built by the package maintainer (IDK, this is just an example!).
So perhaps the shared-library was built using something like:
Code:
ar rcs library.a v{1,2,3}/object.oFor the sake of this example, we'll assume that the library itself is in ~/lib/ - a library directory in your home directory.
And you want to extract and examine all of the object files from the library in a project directory in your home directory - ~/Projects/library/
This is how you'd extract the three different versions of object.o:
1. Navigate into your project folder - i.e. where you are going to extract the object files to; And re-create the folder structure you require. You want 3 folders called v1 v2 and v3:
Code:
cd ~/Projects/library/
mkdir v{1,23}2. cd into the first directory (v1) and extract v1/object.o from the static-library file:
Code:
cd v1
ar ~/lib/library.a v1/object.oSo your v1 folder should now have an object file called object.o
3. Repeat the above for v2 and v3:
Code:
cd ../v2
ar ~/lib/library.a v2/object.o
cd ../v3
ar ~/lib/library.a v3/object.oNow you have the three identically named object files in different sub-directories in your project directory....
Having multiple object files with the same name in a library seems a little odd to me, but there ya go! If the object files were given unique names, this wouldn't be an issue, you could just use 'ar -x library.a' to extract ALL of the object files in the library into the current working directory.
I have to admit, I am not 100% au fait with ar or the static library format, so I might be a bit wrong on one or two points. But I'm pretty certain I'm correct about ar only extracting to the current working directory. Also, I haven't tested any of this out for myself - I'll leave that to you to investigate further!
Last edited:
OP
rstanley
Guest
Can you explain a little more about what you are trying to do? The word, "decompress" implies a compressed zip file, not a C language library file.
What is this lib file? Why do you need to extract one or more object modules from it rather than linking to a program you are compiling? Is this part of a homework assignment?
OP
huang
Guest
thanks!
OP
huang
Guest
i want to merge several .a into one .a, in some .a exist same file name .o.
OP
huang
Guest
As far as I understand things:
When you add object (.o) files to static library (.a) files, I don't think any directory structure information is used for anything other than identifying objects, if at all. The static library file format doesn't work like compressed archive file formats, like tar, or tar.gz etc.
When you extract the .o files from the library, you can specify which objects to extract, using the original folder names - but I believe all object files are extracted to the current working directory. So if your library has several object files with the same name, I have a feeling that ar is going to overwrite the same object file in the current working directory each time.
From looking at the man-page for ar, I can't see anything that gives you the option to extract object files and replicate the original directory structure. So it looks like it just extracts the object files to the current working directory.
So, this solution probably isn't ideal, but I'd guess that you'd have to manually re-create the directory structure yourself and extract each object file individually.
As an example:
You have downloaded a static library called library.a, which contains three files called object.o - Taken from sub-directories v1/ v2/ and v3/ in the source code when it was built by the package maintainer (IDK, this is just an example!).
So perhaps the shared-library was built using something like:
Code:ar rcs library.a v{1,2,3}/object.o
For the sake of this example, we'll assume that the library itself is in ~/lib/ - a library directory in your home directory.
And you want to extract and examine all of the object files from the library in a project directory in your home directory - ~/Projects/library/
This is how you'd extract the three different versions of object.o:
1. Navigate into your project folder - i.e. where you are going to extract the object files to; And re-create the folder structure you require. You want 3 folders called v1 v2 and v3:
Code:cd ~/Projects/library/ mkdir v{1,23}
2. cd into the first directory (v1) and extract v1/object.o from the static-library file:
This will extract v1/object.o from the static library and put it into the current working directory (~/Projects/libary/v1/)Code:cd v1 ar ~/lib/library.a v1/object.o
So your v1 folder should now have an object file called object.o
3. Repeat the above for v2 and v3:
Code:cd ../v2 ar ~/lib/library.a v2/object.o cd ../v3 ar ~/lib/library.a v3/object.o
Now you have the three identically named object files in different sub-directories in your project directory....
Having multiple object files with the same name in a library seems a little odd to me, but there ya go! If the object files were given unique names, this wouldn't be an issue, you could just use 'ar -x library.a' to extract ALL of the object files in the library into the current working directory.
I have to admit, I am not 100% au fait with ar or the static library format, so I might be a bit wrong on one or two points. But I'm pretty certain I'm correct about ar only extracting to the current working directory. Also, I haven't tested any of this out for myself - I'll leave that to you to investigate further!
thanks a lot!
OP
JasKinasis
Guest
BTW: I've just noticed, I forgot to include the -x parameter in the invocations of ar in steps 2 and 3 of my example.
The steps should be:
Step 2:
Code:
cd v1
ar -x ~/lib/library.a v1/object.oStep 3:
Code:
cd ../v2
ar -x ~/lib/library.a v2/object.o
cd ../v3
ar -x ~/lib/library.a v3/object.oSorry about that!
OP
rstanley
Guest
If this is a library that you have created, then normally you use make to control the whole process, the compilation of the .c files, creation and updating the library.
If this is a library that was created by someone else, then you may run into conflicting license issues. You don't say if you have access to the .c files. If not than I have to wonder about the source (All puns intended!) of the libraries in question.
If you have a .o file that has the same name as the .a library, then it is possible that the .o object module was used to create the .a library of the same name, or the .o file relies on the library of the same name.
Again, we have too little information to advise you further. Please be careful if these are proprietary closed-source libraries!!!
