In Windows C++ when you want to link against a DLL you must supply an import library. But in GNU build system when you want to link against .so files which are the equivalent of
The linking model is different in Windows and in Linux. Read Levine's book Linkers and loaders (on Linux, every public symbol of a library is exported, unless you play visibility tricks; on Windows, that is not the case, and exported symbols need to be explicited).
The C++11 standard (read n3337) don't mention dynamic linking. It is an implementation detail.
The future C++20 could have modules.
For more details, be aware that name mangling is different. Read also Program Library Howto, Drepper's How to Write Shared Libraries
On Linux, plugins are loaded (and handled differently than on Windows) by the dynamic loader. See ld-linux(8), dlopen(3), dlsym(3), elf(5)
Inspect, on Linux, ELF files (object files, libraries, executables) with objdump(1) and readelf(1) and nm(1).
See also C++ dlopen mini howto. Read also about the Visibility function attribute. See also this question.
.so files which are the equivalent of dll
A Linux shared object (ELF .so
file) is not exactly equivalent to a Windows DLL. Read the references given above.
I also recommend reading Operating Systems: Three Easy Pieces and the old Advanced Linux Programming (both are freely downloadable). Later read syscalls(2) and the pages referenced from there.
Be also aware that Linux is free software, so you can download and study the source code of most of its components.
PS. Linux and Windows are really different. Don't expect to find in Linux the exact equivalent of every Windows feature. Look into Linux with fresh eyes. Take advantage that Linux is made of free software, and consider studying the source code e.g. of the kernel, binutils, GNU libc or musl-libc (both providing some ld-linux.so
and libc.so
, so a C standard library), GCC or Clang (both providing a C++ standard library above the libc.so
).
To add to Basile's answer, you may occasionally need import libraries on Linux to simulate delay loading of shared libraries (which is useful e.g. if your app rarely needs this library and you don't want to waste resources on it).
Such simulated import libraries would consist of a bunch of wrappers that call dlopen
and dlsym
internally and then goto to implementation in shared library. They can be implemented manually, via project-specific script or via generic tool Implib.so.