I have a simple C library that I compile to a .so file on my linux machine. I'd like to do the same on my Mac, but after I compile and move the library to /usr/local/lib, but I'm not sure how to link it seeing as ldconfig isn't a thing.
How would I go about doing this?
While Linux has .so files, OSX has .dylib files. The process is similar, you just invoke compiler as in
clang -dynamiclib -o libname.dylib sources.c
Related
I'm reading a tutorial about C development with the SDL library on MingW and Windows. (The tutorial is actually about C++ but I'm assuming installation and building is the same).
The tutorial gives the following command for building the program:
g++ 01_hello_SDL.cpp -IC:\mingw_dev_lib\include\SDL2 -LC:\mingw_dev_lib\lib -w -Wl,-subsystem,windows -lmingw32 -lSDL2main -lSDL2 -o 01_hello_SDL
In this command we use -L and -l to tell g++ where to find .a files (not .DLL or .so files) for linking. However, as far as I understand - this command is supposed to dynamically link the library. And as we know, .a files are static library files. What am I missing?
Why are we not linking with the .DLL file of the library, but instead we link with these .a files? When executing, the .DLL file will have to be present near the executable, but the .a won't have to as far as I understand. Again, what am I missing?
-l is not only for dynamic libraries. It can also be used to link static libraries.
On Linux, it is normal to directly link with a .so file (equivalent to a .dll). On Windows, it is still possible to do this (I think), but it is more normal to link with a .lib file called an import library, which wraps the .dll (you link to the .lib and the .lib links to the .dll). Since you are not using the Microsoft toolchain, it's possible that your toolchain still uses import libraries, but calls them .a files instead of .lib files.
I have a virtual machine with ArchLinux installed. Here when I compile with GCC by running gcc file.c it gives me a shared library instead of an executable.
Later I find out that the problem is related only to GCC 7.2, in fact, when I compile with GCC 6.4, the output file is an executable.
How do I fix this?
The file utility is just incorrect in calling your program a shared library. It is a position-independent executable (PIE). If you really don't want this, you can specify -no-pie at link time, or build a gcc toolchain with --disable-default-pie, but in general you shouldn't need to change this.
To complement the answer that mentioned file as you pointed out in the comments, the default a.out generated by GCC is not a shared library but instead interpreted as a shared object by file maybe because of the content of your source code. Check this for more information.
Another company gives me three files(demo.c,api.h,libapi.so). they told me that't enough for develop. I'm confuse how to build these thing together.
I use gcc demo.c -o demo -l libapi.so . But's it's said "ld: library not found". I use Mac OS system. Some websites said i should use Linux to use .so file. what should I do?
*.so is "shared object" it works only on Linux. The Windows counterpart of *.so is DLL.These are combiled object code.
What you have to do is
1] "compile" your .c to .o [object file]
2] "Link" the new .o file with the .so
I have a uclibc toolchain that works. I can compile a simple hello.c program statically (arm-linux-gcc hello.c -o hello -static -s) but source packages are automatically compiled dynamically. How can I change the default to static?
You have to edit the makefile of the source packet you are compiling (extra LDFLAG -static, just as you did for the hello.c file). Most of the time source packets are delivered with autoconf. In that case you can probably pass the --enable-static-link flag to configure. See configure --help for the set of possible arguments.
Other note: be careful when cross compiling packages which need other libraries. You do not want to link in your host machine libraries statically.
Are library files .o or .exe files in C?
Neither; generally .o files are object files and .exe files are fully-linked binaries (on Windows).
Static libraries in Linux are .a
Dynamic libraries in Linux are .so
Static libraries in Windows are .lib
Dynamic libraries in Windows are .dll
It's more operating system dependent than language dependent.
In Windows, they are likely to be .dll files.
In Linux, they are likely to be .a or .so files.
In OS X, they are likely to be .a, .so or .dylib files.
Neither. It also depends on the platform. Also, the file extension is only convention and libraries can have any other or no extension at all.
The answer is libraries are neither *.o or *.exe. Also the naming convention depends on the Platform you are compiling.
A *.so file is a shared lib. *.a is a static library on the Linux platform.
You can specify options at compile time to build the libraries.
Here you can check more about shared libraries and compilation and build options for the same.
In linux, library files are an archive of one or more .o files. Linux uses the 'ar' program ( think 'tar' without the tape ), to create the archive. After bundling them together, you then use the ranlib program to add some indexing.
ar rc mylib.a source1.o source2.o source3.o
ranlib mylib.a