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.
Related
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.
I have added libxxx.a in /usr/lib but when I perform otool -L myproject.so, libxxx.a was not included in the list of libraries. I have also included libxxx.a in my build file so I was thinking that I have successfully added it.
How can I like .a file?
I didn't have a problem with .dylib files though.
otool won't show the static library as they are included within the executable binary (a .dylib in this case). This is because static libraries are a collection of object (.o) files and it's pretty much the same as adding file1.o ... fileN.o to the linker command line and you can't see object files from otool either.
One way to check that your static library is part of the executable (other than it successfully linking) is to use the nm command which lists symbols. Providing the executable binary is not stripped, you would do something like:
$ nm /path/to/libLibrary.dylib | grep aClassOrFunctionInStaticLibrary
and the symbol being searched should have the letter t next to it, to indicate that it's part of the executable text section.
Also as mentioned by #PaulR, /usr/lib is part of the operating system and you should not add files there; use /usr/local/lib instead as /usr/local is designed for site-specific additions to the system and files there will survive an operating system update.
I compiled an open source library and it turned out that there are unresolved symbols within the generated shared library (.so). The natural next step seemed to me finding out which object has the unresolved symbols, but I could not apply nm or objdump to the intermediate libtool object files (.lo). Is there any way I can take a look at the list of symbols within .lo files?
You need to run nm or objdump on the object files (.o files), not the .lo files. The .lo files are used by libtool and are text files that can tell you where your object files really are:
# Name of the PIC object.
pic_object='.libs/libfoo_la-foo.o'
# Name of the non-PIC object
non_pic_object='libfoo_la-foo.o'
Since you need to know about a DSO (the .so file), the pic_object files are probably the ones you want to examine.
I have an Autogen Makefile.am that I'm trying to use to build a test program for a shared library. To build my test binary, I want to continue building the shared library as target but I want the test program to be linked statically. I've spent the last few hours trying to craft my Makefile.am to get it to do this.
I've tried explicitly changing the LDADD line to use the .a version of the library and get a file not found error even though I can see this library is getting built.
I try to add the .libs directory to my link path via LDFLAGS and still it can't find it.
I tried moving my library sources to my test SOURCES list and this won't work because executable object files are built differently than those for static libraries.
I even tried replicating a lib_LIBRARIES entry for the .a version (so there's both a lib_LTLIBRARIES and a lib_LIBRARIES) and replicate all the LDFLAGS, SOURCES, dir and HEADERS for the shared version as part of the static version (replacing la with a of the form _a_SOURCES = _la_SOURCES. Still that doesn't work because now it can't figure out what to build.
My configure.ac file is using the default LT_INIT which should give me both static and dynamic libraries and as I said it is apprently building both even if the libtool can't see the .a file.
Please, anyone know how to do this?
As #Brett Hale mentions in his comment, you should tell Makefile.am that you want the program to be statically linked.
To achieve this you must append -static to your LDFLAGS.
Changing the LDFLAGS for a specific binary is achieved by changing binary_LDFLAGS (where binary is the name of the binary you want to build).
so something like this should do the trick:
binary_LDFLAGS = $(AM_LDFLAGS) -static
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.