Is the Function 'Dlopen()' Private API

Is the function 'dlopen()' private API?

I've had success using dlopen on iOS for years. In my use case, I use dlopen to load public system frameworks on demand instead of having them loaded on app launch. Works great!

[EDIT] - as of iOS 8, extensions and shared frameworks are prohibited from using dlopen, however the application itself can still use dlopen (and is now documented as being supported for not only Apple frameworks, but custom frameworks too). See the Deploying a Containing App to Older Versions of iOS section in this Apple doc: https://developer.apple.com/library/ios/documentation/General/Conceptual/ExtensibilityPG/ExtensibilityPG.pdf

[EDIT] - contrived example

#import <dlfcn.h>

void printApplicationState()
{
    Class UIApplicationClass = NSClassFromString(@"UIApplication");
    if (Nil == UIApplicationClass) {
        void *handle = dlopen("System/Library/Frameworks/UIKit.framework/UIKit", RTLD_NOW);
        if (handle) {
            UIApplicationClass = NSClassFromString(@"UIApplication");
            assert(UIApplicationClass != Nil);
            NSInteger applicationState = [UIApplicationClass applicationState];
            printf("app state: %ti\n", applicationState);
            if (0 != dlclose(handle)) {
                printf("dlclose failed! %s\n", dlerror());
            }
        } else {
            printf("dlopen failed! %s\n", dlerror());
        }
    } else {
        printf("app state: %ti\n", [UIApplicationClass applicationState]);
    }
}

Linux c++ error: undefined reference to 'dlopen'

You have to link against libdl, add

-ldl

to your linker options

dlopen fails in a library instantiating an object

No error is reported, except that the library pointer returns NULL

A library pointer can't return anything. You probably mean dlopen() returns NULL.

If that's what you mean, that is the error being reported. If you want to know more about why the error was returned, use dlerror() to find out.

is dlopen use inside a static library in iOS allowed

dlopen is not allowed on the iOS versions < iOS 8. See e.g. here.

Wrapping different C API implementations in C++

First thing's first, if you are going to be wrapping up a C API in C++ code, you should hide that dependency behind a compilation firewall. This is to (1) avoid polluting the global namespace with the names from the C API, and (2) freeing the user-code from the dependency to the third-party headers. In this example, a rather trivial modification can be done to isolate the dependency to the C APIs. You should do this:

// In NFoo.h:

#include "Foo.h"

class NFoo : public Foo
{
  public:
    virtual void foo(void);
};

// In NFoo.cpp:

#include "NFoo.h"

#include <nfoo.h>

void NFoo::foo(void) {
  ::foo();   // calling foo from the nfoo C-API
}

The point of the above is that the C API header, <nfoo.h>, is only included in the cpp file, not in the header file. This means that user-code will not need to provide the C API headers in order to compile code that uses your library, nor will the global namespace names from the C API risk clashing with anything else being compiled. Also, if your C API (or any other external dependency for that matter) requires creating a number of things (e.g., handles, objects, etc.) when using the API, then you can also wrap them in a PImpl (pointer to a forward-declared implementation class that is only declared-defined in the cpp file) to achieve the same isolation of the external dependency (i.e., a "compilation firewall").

Now, that the basic stuff is out of the way, we can move to the issue at hand: simultaneously linking to two C APIs with name-clashing symbols. This is a problem and there is no easy way out. The compilation firewall technique above is really about isolating and minimizing dependencies during compilation, and by that, you could easily compile code that depends on two APIs with conflicting names (which isn't true in your version), however, you will still be hit hard with ODR (One Definition Rule) errors when reaching the linking phase.

This thread has a few useful tricks to resolving C API name conflicts. In summary, you have the following choices:

• If you have access to static libraries (or object files) for at least one of the two C APIs, then you can use a utility like objcopy (in Unix/Linux) to add a prefix to all the symbols in that static library (object files), e.g., with the command objcopy --prefix-symbols=libn_ libn.o to prefix all the symbols in libn.o with libn_. Of course, this implies that you will need to add the same prefix to the declarations in the API's header file(s) (or make a reduced version with only what you need), but this is not a problem from a maintenance perspective as long as you have a proper compilation firewall in place for that external dependency.

• If you don't have access to static libraries (or object files) or don't want to do this above (somewhat troublesome) approach, you will have to go with a dynamic library. However, this isn't as trivial as it sounds (and I'm not even gonna go into the topic of DLL Hell). You must use dynamic loading of the dynamic link library (or shared-object file), as opposed to the more usual static loading. That is, you must use the LoadLibrary / GetProcAddress / FreeLibrary (for Windows) and the dlopen / dlsym / dlclose (all Unix-like OSes). This means that you have to individually load and set the function-pointer address for each function that you wish to use. Again, if the dependencies are properly isolated in the code, this is going to be just a matter of writing all this repetitive code, but not much danger involved here.

• If your uses of the C APIs is much simpler than the C APIs themselves (i.e., you use only a few functions out of hundreds of functions), it might be a lot easier for you to create two dynamic libraries, one for each C API, that exports only the limited subset of functions, giving them unique names, that wrap calls to the C API. Then, you main application or library can be link to those two dynamic libraries directly (statically loaded). Of course, if you need to do that for all the functions in that C API, then there is no point in going through all this trouble.

So, you can choose what seems more reasonable or feasible for you, there is no doubt that it will require quite a bit a manual work to fix this up.

Change library load order at run time (like LD_PRELOAD but during execution)

AFAIK, that is not possible. The general rule is that if the same symbol appears in two libraries, ld.so will favor the library that was loaded first. LD_PRELOAD works by making sure the specified libraries are loaded before any implicitly loaded libraries.

So once execution has started, all implicitly loaded libraries will have been loaded and therefore it's too late to load your library before them.

---

Related Topics