I'm checking a makefile, and see that the libraries used are:
LIBS = -lcppunit -ldl
lcppunit is the unit testing library. What is ldl then?
This is the interface to the dynamic loader, which provides a client program with ability to do things such as explicitly load other libraries, lookup symbols within, etc.
Most programs do not need to do such things explicitly, since the linker does what is needed to enable ordinary usage of shared libraries while loading the program and libraries themselves. However programs that are clever or try to explore and manipulate the dynamic linking system and its data need explicit access. Some of the capabilities are distantly similar to reflection in Java, though with major limitations (such as applying only to dynamic symbols)
libdl is the dynamic linking library.
libdl is the dynamic link library used in plugin architectures with well defined interfaces. At least that's how I've seen it used.
Related
Will linking a static cpp lib and a dynamic cpp lib, both containing different versions of boost, violate ODR?
I am working on an iphone application. For final executable, I need to link a static library say libstatic1.a and a dynamic framwork say libdyanamic1.
libstatic1.a contains some version of boost, say boost 1.x and libdynamic1 contains another version of boost say boost 1.y. Now will final executable which links both of these, violate ODR rule?
Symbol visibility in libdynamic1:
I inspected symbols present in libdynamic1 using nm -g -C libdynamic1 and observed that symbols of boost threadpool and boost filesystem are present in the list.
If I am violating ODR, what are my options to handle the situation?
(So far I have tested the executable on multiple devices and have not experienced any issue.)
The standard only talks about "programs" where a "program" is a set of translation units "linked together", each consisting of a sequence of declarations [basic.link]. Arguing the ODR, which also concerns itself only with "programs", when it comes to questions involving dynamic libraries is not that straight forward. Since a "program" is required to contain a main function [basic.start.main]/1, a dynamic link library will generally not qualify as a "program" on its own.
Strictly speaking, I think a dynamic library would have to be viewed as just another set of translation units that are "linked" with the rest to form the final program. Thus, the program would really only be complete once all images have been loaded into memory and dynamic linking is finished (run-time dynamic linking would seem to further complicate the matter, but can be ignored here I guess). In this sense, the program described in your question (linking both the static and the dynamic library where each is using a different version of boost) will almost certainly be violating the ODR since you are going to have multiple translation units which are, e.g., using different definitions of the same entities [basic.def.odr]/12.
In practice, however, this issue is highly platform- and toolchain-dependent. At the ABI level, you typically find that the types of linkage a symbol can have are more differentiated than what you find at the language level within C++. On Windows, for example, you typically have to explicitly specify which symbols should be exported when building a dynamic library, all names are internal to the library by default. On ELF-based Linux, on the other hand, that is famously not the case. It would seem, however, that you can use the -fvisibility=hidden option to switch GCC to a more Windows-like default where your library will only export what you explicitly tell it to. Note that you must not have anything to do with boost in the interface your library exports as that will obviously lead to undefined behavior in your case…
On a UNIX system is there a simple way to identify whether a dynamic (shared) library depends on other dynamic libraries?
I'm exploring system level APIs such as dlopen and friends in C and C++. I have a controlled environment where I will be calling dlopen and mapping specific functions. The idea is that people will be able to write native plugins to the application (and let us assume for the moment that it is in the author's best interest to make sure the library actually performs the correct function and is not malicious).
However, as a security measure I would like to ensure at runtime that the loaded dynamic library does not link to any other dynamic libraries (the intention being to disallow system calls and only permit functions from the local maths library) - and if it does, don't load it.
Some (long and/or difficult) solutions I've come up with:
Write a compiler shim that compiles the plugin code with a very specific set of compiler options, and injects some sort of checksum function that can be used to validate that the compiler shim was used.
Individually slice out all function calls referencing function names I don't want to be used.
Intercept all syscalls with some linker path trickery.
Is there a simple(r) way of checking dynamic libraries' dependencies?
However, as a security measure I would like to ensure at runtime that the loaded dynamic library does not link to any other dynamic libraries
Note that a dynamic library can import a symbol without explicitly linking to any other dynamic library. For example:
int foo() { return open("/etc/passwd", O_RDONLY); }
gcc -fPIC -shared -o foo.so foo.c -nostdlib
Now foo.so does not have any DT_NEEDED shared library dependencies, yet will still open /etc/passwd at will.
(the intention being to disallow system calls and only permit functions from the local maths library) - and if it does, don't load it.
There is so much wrong with your intention, it's not even funny.
For a start, you don't need to link to any external library to execute system calls directly, it can be trivially done in assembly.
Also, the plugin can find and modify dynamic loader's data, and once it does, it can make your main program do arbitrary things. For example, it can hijack all of your main program's calls into libc.so, and redirect them elsewhere.
Once you run untrusted code in your process, it's game over.
solutions I've come up with
None of them have even remote chance of working. Any time you expend on this is time totally wasted.
I have a limited knowledge of dynamic libraries and I usually have problems related to libraries that I do not understand.
I recently learned of libraries from google search and especially from the following links:
Difference between shared objects (.so), static libraries (.a), and DLL's (.so)?.
http://www.ibm.com/developerworks/library/l-dynamic-libraries/. That article was very useful in understanding the dynamic libraries and their usage:
If I understood well (correct me if I am wrong), there are two possible usages of shared objects:
dynamic linking: the shared object is automatically loaded by the dynamic linker when the program starts.
dynamic loading: the share object is loaded and used under the program control at runtime through the dynamic loading API (dlopen, dlerror, dlsym and dlclose). That option is useful for plugins.
If I got everything right, in the case of dynamic linking, all the symbols are verified at compilation time. This allows the compiler/linker to know exactly which shared object is effectively used by the program and which one is not used.
Now, it happens that the dynamic linker is always invoked at runtime even if the shared object is not used. It can be verified by linking an empty program against libraries that are not in locations searchable at runtime, and the execution will fail. Linking a program against library that is not actually used in the program can happen when there are updates and the use of a library is no longer necessary. It also happen when one isolates a part of the program for debugging, and link against all the libraries of the main program.
My question is: is there an option to ask the compiler/linker to not include reference to shared objects that do not have symbols referred to in the program?
Is there any issue that prevent the compiler from doing that?
The following posts share some similarities with the present question, but none of them has an accepted answer, nor an answer that satisfies my curiosity:
https://stackoverflow.com/questions/22617744/how-to-disable-the-runtime-checking-of-shared-object-if-they-are-not-used
Delay-Load equivalent in unix based systems
If you happen to use g++/ld there are a few suggestions spelled out on How to remove unused C/C++ symbols with GCC and ld?
For example:
gcc -Os -fdata-sections -ffunction-sections test.cpp -o test.o -Wl,--gc-sections
-dead_strip
-dead_strip_dylibs
However I'm actually not sure it's possible for the compiler to do this in the general case. Consider a dependent shared library that has a weak reference to the library that you want to remove from your link line: How would the compiler know that it's safe to remove the library and/or symbols at that point?
I maintain our in-house infrastructure library - lets call it libcluracan. This library has to be statically linked because it doesn't exist on outside computers where the code is used.
This means that instead of creating a libcluracan.so file using the linker I create a libcluracan.a file using the ar command
Now I'm trying to add some new functionality to libcluracan, but it requires linking with an outside library - specifically -lfltk, but the specifics aren't important. What is important is that I can assume the outside computers have this library (and any other publicly available library I need).
The biggest problem is that I can't change how the in-house programmers compile (well, link) their code.
Had we been using a dynamic libcluracan.so library I'd just add -lfltk to the linker and forget about it - the programmers would continue to link with -lcluracan and get -lfltk automatically.
I need to find a way to do the same thing with our static libcluracan.a library.
TL;DR
Is there a way to create a static .a library that automatically links to another dynamic .so library when used?
The biggest problem is that I can't change how the in-house programmers compile (well, link) their code.
That is indeed a big problem. Your in-house programmers should be using make (or a similar automated build system), and the change would be trivial.
There is no way to achieve what you want on an arbitrary UNIX system.
IF you are using GNU toolchain, and in particular GNU-ld or gold, THEN you can achieve what you want by linking with libcluracan.so, where libcluracan.so is not a shared library, but a linker script, which looks like this:
GROUP ( libcluracan.a libfltk.so )
First, I don't know if there is a solution to my problem at all.
I have the following situation:
I have developed a framework library that depends on several other libraries for specific hardware access, etc.
Until now this framework library was only statically linked against.
For the executable that uses the framework library only the dependencies of code that is actually used by the executable have to be linked. (If I don't access a specific hardware at all I don't have to depend on its associated libraries.)
Now I need to also make a shared object of the framework library. Also the dependencies are available as shared libraries, so there is no need for any static linking.
The problem I have now:
When building an application that links dynamically to the framework library I have to either link all dependencies dynamically to the framework library or the application. (Otherwise I get undefined references complaints from ld)
My questions:
Is there any way to ignore certain shared object dependencies if I know that my application will not use any code of the framework library that depends on this shared object?
Is there any way to do this without or with minimal code changes? (linker / compiler switches)
I also need the static linking as described in the original situation to still work.
Additional Info:
Operating system: Linux (Debian Lenny)
Compiler: gcc-4.3
You can, but you basically have to do all of the dynamic library handling yourself. i.e. dlopen the library, and then look up the symbols you need directly with dlsym.
It will make your code more complicated, how much depends on the interface you've got into the libraries.
From man ld
--as-needed
--no-as-needed
This option affects ELF DT_NEEDED tags for dynamic libraries mentioned on the command line after the --as-needed option. Normally,
the linker will add a DT_NEEDED tag for each dynamic library mentioned on the command line, regardless of whether the library is
actually needed. --as-needed causes a DT_NEEDED tag to only be emitted for a library that satisfies a symbol reference from regular
objects which is undefined at the point that the library was linked, or, if the library is not found in the DT_NEEDED lists of other
libraries linked up to that point, a reference from another dynamic library. --no-as-needed restores the default behaviour.
I haven't used it myself but sounds like what you're looking for.
g++ -o your_app -Wl,--as-needed -lframework -la -lb -lc -Wl,--no-as-needed
Edit (suggested by Hanno)
--warn-unresolved-symbols
If the linker is going to report an unresolved symbol (see the option --unresolved-symbols) it will normally generate an error.
This option makes it generate a warning instead.