When I am compiling code using GCC, it is giving two outputs .o and .d file.
While creating library(.a) do I need to add(.d) files also. If yes then how?
No you only need to add the .o file, a static library archive is just a collection of .o files.
The .d file is a makefile fragment for specifying the dependencies used to build the object file, and is only needed when you are compiling the .o file itself.
Related
I am tring to build linux kernel using clang/llvm. I am trying to save the .bc file while generating the .o file . I find LLVM have the API "writebitcodetofile" whcich can save the bc code to certain file, but I am not sure how to use it.
There is a number of flags that can do that for you:
-flto enables Link-time optimization, which uses LLVM bitcode. In this case (almost) all the .o files will in fact contain the bitcode.
-save-temps tells clang to put the results of each intermediate phase into a separate file. Simple clang -save-temps main.c may output main.o, main.bc, main.i, main.s, or object file, bitcode file, preprocessed file, and assembly file, respectively.
-fembed-bitcode tells clang to include the bitcode representation of a file into the resulting object file. You can learn more about this here: https://jonasdevlieghere.com/libebc-ebcutil/
Note, however, that you won't get bitcode for assembly files.
The platform is mac osx, and the library's platform is arm64.
I have a static library which name is arm64.a.
Using ar -x arm64.a, I got some .o files.
And then I used ar rcs libarm64.a *.o, trying put all .o files into libarm64.a.
However, arm64.a and libarm64.a is not the same size.
libarm64.a is smaller than arm64.a.
I also tried to link libarm64.a, and linker complained undefined reference xxx.
Have I done wrong somewhere?
Is it possible to convert or maybe extract a file from .la library to .a?
I've a project where I have my application linked statically against all libraries, but some of them are generated with libtool (.la libs), while others are created with gcc (.a lib). In this answer one says, that in the .libs subdirectory should be .a libfile, but I've found there only .la, .so, and .o files, probably because the lib project was not configured with --enable-static.
that in the .libs subdirectory should be .a libfile, but I've found there only .la, .so, and .o files, probably because the lib project was not configured with --enable-static.
That's what it sounds like to me as well. You'll need to do that to get a .a file. The libs you are building with libtool are probably being compiled with gcc.
Is it possible to convert or maybe extract a file from .la library to .a?
No. There's no object code in a .la file to extract to a .a file. As the link to the other answer says, it's basically a metadata file of how to link and where the files are, etc. A .la file is humanly readable, so if you really want to know what's going in there you can examine it.
I have "library" folder with multiple object (.o) files. These files contain subroutines which are not changing from project to project. Each new project uses some of those object files, but not all of them.
Could you please tell me is there any way to tell gfortran to look up that folder for necessary .o files?
I've tried -I and -L options, but no way. When I write .o names directly, it works:gfortran main.for ./library/obj1.o ./library/obj2.o but I have many of .o files and write all of them waste time.
I could write gfortran main.for ./*.o but then main program will be linked with all .o files, but it needs only some of them.
I hoped that something like gfortran main.for -L./library/ will work, but it doesn't.
I use OS X with gcc version 5.1.0.
And I'm pretty sure that I should use makefile for such case
You are confusing object files with static libraries. An object file
is not a static library and the gfortran linker - which is simply
the GNU system linker, invoked by gfortran - will not treat it as such.
You need a static library and you are trying to use object files in lieu.
The linker recognizes an object file by the extension .o. It recognizes
a static library by the extension .a, and it expects the contents of an .a file
to have the form of a static library, not the format of an object file. (So you
cannot make an object file into a static library just by renaming it).
The linker will link into your program every object file that appears on its
commandline, whether or not it is needed. It does not expect you to mention
object files if you don't want them linked. The linker options -L and -l for
locating libraries have no application to object files.
A static library is a fairly simple archive containing some number of
object files, plus a house-keeping header and typically an index of the
public symbols defined in the contained object files.
When the linker encounters a static library on its commandline, it does not
link the entire contents of the library (unless you expressly tell it to). It inspects
the contained object files to determine which, if any, of them contain
definitions for symbols that are as yet undefined at that point in the linkage
of the program. If any object file in the library is found to provide any
of the missing definitions, then that object file is extracted from the library
and linked into the program. Object files in the library that provide no
missing definitions are not linked. Libraries on the commandline are sequentially
inspected in this way until either all the symbols referred to by the program
have definitions in linked object files or there are no more libraries.
If as you say the object files that you are trying to use as libraries are stable
resources that you never have to build for your projects, then you can just make a static
library out of them and link that library with your per-project programs.
To make a static library from object files, use the ar tool.
See man ar.
When you have made your library, say, libsubs.a, and have decided it shall reside
in some directory, /path/to/subs, then you link it with a program by adding
-L/path/to/subs -lsubs
to the commandline in which your program is linked. This will cause the linker
to search for a library called libsubs.a in directory /path/to/subs.
So if you are compiling and linking in a single step, use it like:
gfortran -o myprog myprog.f90 -L/path/to/subs -lsubs
And if you are compiling and linking in distinct steps, use it like:
gfortran -c -o myprog_1st_file.o myprog_1st_file.f90
gfortran -c -o myprog_2nd_file.o myprog_2nd_file.f90
gfortran -o myprog myprog_1st_file.o myprog_2nd_file.o -L/path/to/subs -lsubs
This is how you are supposed to use a set of object file resources of which
different subsets will be required for linkage with different programs: you put
them in a library and link the library.
I have a make system I just completed, and my goal is to have one Monalithic .so file at the end. So far I have compiled all the seperate parts into .a files. I did this just to compact the number of .o files I would have to work with.
My idea so far is to just unpack the .a files at the end and then rebuild all of them into the large .so file. Is this sincable or is there another (better) way to do this?
See the --whole-archive option in the man page for the ld command to combine static libs into a dynamic lib.