I'm trying to create a static library to use inside my PHP extension. To do that, I'm compiling my .c files using gcc -c file.c -o file.o and obtaining .o files. I then use ar rcs lib.a *.o to archive all the compiled objects into an .a file.
After doing this, I'm referring to this .a file when compiling my PHP extension, but I get the following error:
*** Warning: Linking the shared library <extension>.la against the
*** static library lib.a is not portable!
If I use the .o files instead of the .a file, I get:
*** Warning: Linking the shared library <extension>.la against the non-libtool
*** objects file1.o file2.o is not portable!
What am I doing wrong and what's the correct way of doing this?
The short answer: shared libraries (of which a PHP extension is a special case) cannot depend on static libraries.
Actually that's not quite entirely true. As long as your static library is built as position-independent code (PIC), using it from a shared library will work; whatever .o files from the archive are needed to satisfy the undefined symbols in the .o files you explicitly linked to make the .so will get pulled in and become part of the shared library file.
Linking non-PIC .o files into a shared library will also work on some archs (like i386) but it's not portable (and won't work on x86_64).
As for what you should do, if it's possible, I would just forget about the intermediate .a file and link all your .o files explicitly into the .so file for the extension. This is clean and simple. Or you could keep doing it the way you're doing as long as you're sure all your files got built as PIC (i.e. with the -fPIC option).
What I would not do is make and install an extra .so file that the main .so file for the extension will then depend on. All this does is create bloat, increase load time, and make lots of trouble with deployment/integration.
Linking shared libraries to static libraries is not possible (unless you really know very well what you are doing). Don't do it.
The first warning is from libtool. It tells you, that the operation you asked for will do different things on different systems and some of those things are probably not what you want. Often it's just going to fail in various spectacular ways, because code that goes in shared and static libraries needs to be compiled with different compiler flags.
i have faced same problem once but i have solved it by corrcting some linking flag in make file you can see
What is the meaning of “Warning: Linking the shared library against static library is not portable”?
Related
Basically when using SDL2 library why do I need to use both SDL2.dll (dynamic) file and .a (static) for compilation?
For an example to compile a simple program I need to tell gcc where lib files (static .a) are located to compile the program. Why not just use the .dll file instead?
My first thought is that .a files are needed for the compiler to check if program can compile with the library and .dll is only needed when running the program (and program is not statically linked in the end), but still that wouldn't explain why do i need the .a files instead of just .dll file.
example:
gcc -I src/include src/lib -o main.exe main.c -lmingw32 -lSDL2main -lSDL2
There are two .a files: libSDL2.a and libSDL2.dll.a (not counting libSDL2main.a, which is always static).
The first one is a true static library. -lSDL2 doesn't prefer it by default, it prefers libSDL2.dll.a. And if you force it to use the former, because the latter is unavailable, the resulting app won't depend on SDL2.dll.
The second one is an import library. In the old days, MinGW couldn't link against a .dll directly, and you had to use those. Modern MinGW can link .dlls directly, and those should in theory be unnecessary.
I'd still recommend using the import library if it's available, just because it's more common and more widely tested.
I’m quite new to C and the gcc compiler. I have a project where I include some other .h files. In that files there are include from more own .h files. And so on. Its a decent amount of includes.
My problem is, when I try to compile the main file with:
gcc -o test tests_main.c
I get the following error:
Undefined symbols for architecture x86_64:
"_waves_secure_hash_test", referenced from:
_crypto_tests in tests_main-d1ae56.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Thats because the compiler cant find the method "waves_secure_hash_test", but its in the included file:
#include "crypto_tests.h"
So, I searched a little bit and found a solution, just compile it with:
gcc -o test tests_main.c crypto_tests.c
Okay, that work for me with that two test file, where the functions are only some test prints.
For my complete project with a decent amount of includes, I can’t write down all that c files to compile... Is there a way to tell the compiler that he has to compile all needed and included files?
You're mixing up included files (.h files, header files) and source files (.c files). You don't have to do anything about header files, the compiler will process them automatically(1).
You do have to list all source files which you want to compile.They are what defines your project. Based on your source tree organisation, you might get away with using shell pattern expansion (e.g. *.c) to get them, though.
For larger projects, you normally don't type the compilation command by hand, but use some project management tool, such as an IDE, a Makefile, or a buildsystem generator such as CMake.
Also note that the error you're actually getting is not a compiler error, it's a linker error. Linking is a separate step that comes after compiling. The compilation reads source files and produces object files. Linking then reads object files and produces a binary (executable or shared library) out of them.
You should also note that there is not always a 1:1 correspondence between header and source files. The classic example are libraries: you can include one or more header files which are shipped with an external library; these will provide declarations for functions implemented inside that library. This allows you to call the functions in your code. To then make these functions available to the linker (so that they can become part of your program), instruct the linker to link the library into your binary (normally via the -l command-line option).
(1) You may still need to point your compiler at directories where these header files reside, which is usually done using the -I command-line option.
I am converting a set of static libraries to shared libraries and was able to create the shared libraries successfully. The problem is with the exe's because linking with static library can have unresolved symbols in the library but that is not the case with shared libraries. All the symbols in the shared library should get resolved.
Example:
PROG1 calls LIB1.a calls LIB2.a
Now the make file of PROG1 need not have LIB2.a as PROG1 calls to LIB1.a do not result in calling LIB2.a .So some LIB2.a symbols in LIB1.a can remain unresolved.
After conversion
Both LIB1.so and LIB2.so have to be included in the makefile of PROG1. Including LIB2.so resolves few linkage issues of LIB1.so but new issues appear due to inclusion of LIB2.so(as it may be depend on LIB3.so)
SO is there any way to find out the all the dependent libraries of a shared library?
I tried using ldd but it prints nothing.
Please let me know if my analysis is wrong.
This is a slightly personal opinion, but I think you should link your shared libraries so that you get an error for unresolved symbols (with -z defs). That means you sort out each library independently and don't get any nasty surprises at link time.
Of course, this only works if your libraries are clean and don't contain recursive dependencies (which are probably a bad thing anyway) and you aren't trying to do dynamic loading where you can load any of impl_1.so, impl_2.so or impl3_.so to provide code for a client client.so at runtime. But it works well if all you have are link time dependencies.
Indeed, if you don't do this, and are using ld rather than cc to do the linking,, you'll get pretty much what you're seeing - no dependencies, and errors at linktime
Let's say I have a source file, say helper.c, which gets compiled into an object library (helper.a). Now, this uses functionality from many system libraries, so currently when I want to link helper.a into an executable, I end up having to list all the dependencies:
gcc main.c helper.a -o my_app -lrt -lpthreads ...
What's the common approach to avoiding this tedium and maintenance issue? Is there some way of embedding information about the dependencies into the library so GCC can find them at link time? Or does one have to statically link the dependency libraries into helper.a?
Some compilers can generate a text file containing all the dependencies of the file being compiled. Check your compiler's documentation.
Include this text file into your makefile to resolve the dependencies.
I'm sure this question has been asked many times, but I can't figure this out. Bear with me.
So when you download a library, you get a bunch of .c and .h files, plus a lot of other stuff. Now say you want to write a program using this library.
I copy all the .h files into my project directory. It just doesn't compile.
Great, so then I get the library as a bunch of .dll's, and i copy the dlls into my project directory. Still doesn't compile.
How does this work?
What do you do, like right after creating the folder for your project? What parts of the library package do you copy/paste into the folder? How do you make it so that it can compile? Go through the steps with me please.
Where to put the .h files?
Where to put the .dll files?
How to compile?
Thanks.
(the library I'm trying to get working is libpng, I'm in windows with MinGW, and i'm looking to compile from command-line like usual.)
(from what i gather, you put the .h files in directory A and the .dll files in directory B and you can use -l and -L compiler options to tell the compiler where to find them, is this correct?)
Here's a brief guide to what happens when you compile and build a basic C project:
The first stage compiles all your source files - this takes the source files you've written and translates them into what are called object files. At this stage the compiler needs to know the declaration of all functions you use in your code, even in external libraries, so you need to use #include to include the header files of whatever libraries you use. This also means that you need to tell the compiler the location of those header files. With GCC you can use the -I command line to feed in directories to be searched for header files.
The next stage is to link all the object files together into one executable. At this stage the linker needs to resolve the calls to external libraries. This means you need the library in object form. Most libraries will give you instructions on how to generate this or might supply it ready built. Under Linux the library file is often a .a or .so file, though it might just be a .o. Again you can feed the location of the library's object file to GCC with the -L option.
Thus your command line would look like this:
gcc myProg.c -I/path/to/libpng/include -L/path/to/libpng/lib -lpng -o myProg.exe
(Note that when using the -l command line GCC automatically adds lib to the start of the library, so -lpng causes libpng.a to be linked in.)
Hope that helps.
Doing it under windows (supposing you user Visual Studio)
After unpacking add the library include directories to your projects' settings (Project -> Properties -> C/C++ -> Additional Include Directories)
Do the same thing for the Libraries Directory (Project -> Properties -> Linker -> Additional Library Directories)
Specify the name of the library in your Linker Input: Project -> Properties -> Linker -> Input -> Additional Dependencies
After this hopefully should compile.
I don't recommend adding the directories above to the Global settings in Visual Studio (Tools -> Options -> Project and Solutions) since it will create and environment where something compiles on your computer and does NOT compile on another one.
Now, the hard way, doing it for a Makefile based build system:
Unpack your stuff
Specify the include directory under the -I g++ flag
Specify the Library directory under the -L g++ flag
Specify the libraries to use like: -llibrary name (for example: -lxml2 for libxml2.so)
Specify the static libraries like: library name.a
at the end you should have a command which is ugly and looks like:
g++ -I/work/my_library/include -L/work/my_library/lib -lmylib my_static.a -o appname_exe MYFILE.CPP
(the line above is not really tested just a general idea)
I recommend go, grab a template makefile from somewhere and add in all your stuff.
You must link against a .lib or something equivalent i.e. add the ".lib" to the libraries read by the linker. At least that's how it works under Linux... haven't done Windows so a long while.
The ".lib" contains symbols to data/functions inside the .dll shared library.
It depends on the library. For examples, some libraries contain precompiled binaries (e.g. dlls) and others you need to compile them yourself. You'd better see the library's documentation.
Basically, to compile you should:
(1) have the library's include (.h) file location in the compiler's include path,
(2) have the library stubs (.lib) location in the linker's library path, and have the linker reference the relevant library file.
In order to run the program you need to have the shared libraries (dlls) where the loader can see them, for example in your system32 directory.
There are two kinds of libraries: static and dynamic (or shared.)
Static libraries come in an object format and you link them directly into your application.
Shared or dynamic libraries reside in a seperate file (.dll or .so) which must be present at the time your application is run. They also come with object files you must link against your application, but in this case they contain nothing more than stubs that find and call the runtime binary (the .dll or the .so).
In either case, you must have some header files containing the signatures (declarations) of the library functions, else your code won't compile.
Some 'libraries' are header-only and you need do nothing more than include them. Some consist of header and source files. In that case you should compile and link the sources against your application just as you would do with a source file you wrote.
When you compile, assuming you have the libs and the headers in the same folder as the sources you are compiling, you need to add to your compile line -L . -I . -lpng. -L tells the linker where to look for the library, -I tells the compiler where to look for the headers and -lpng tells the linker to link with the png library.
[Edit]
Normal projects would have some sort of hierarchy where the headers are in an /include folder and the 3rd party libs are in a /libs folder. In this case, you'd put -I ./include and -L ./libs instead of -I . and -L.
[Edit2] Most projects make use of makefile in order to compile from the command line. You can only compile manually for a small number of files, it gets quite hectic after that
Also,
you may want to look over Dynamic Loading support in various languages and on various
platforms.
This support is very handy in cases when you want to use a library optionally and you don't want your program to fail in case that library is not available.