CODEWITHSUNDEEP
cmacosdynamic-linking
danfuzz
danfuzz

Reputation: 4353

Creating a dylib which gets linked at runtime

I am trying to create a dynamic library which is meant to be linked and loaded into a host environment at runtime (e.g. similar to how class loading works in Java). As such, I want the dynamic library to be left with a few "dangling" references, which I expect it to pick up from its host environment when it is loaded into that environment.

My problem is that I cannot figure out how to create the dynamic library without explicitly linking it to existing symbols. I am hoping to produce a dynamic library that does not depend on a specific host executable (or host library), rather one that is able to be loaded (e.g. by dlopen) in any host as long as the host makes a couple symbols available for use.

Right now, any linking command I've tried results in a complaint of missing symbols. I'd like it to allow symbols to be missing (ideally, just particularly specified symbols).

For example, here's a transcript with the error on OS X:

$ cat frotz.c 
void blort(void);

void run(void) {
    blort();
}

$ cc -c -o frotz.o frotz.c
$ cc -dynamiclib -o libfrotz.dylib frotz.o
Undefined symbols for architecture x86_64:
  "_blort", referenced from:
      _run in frotz.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

If I do the same thing using a GNU toolchain (on Linux), it helpfully tells me:

$ gcc -shared -o libfrotz.so frotz.o
/usr/bin/ld: frotz.o: relocation R_X86_64_PC32 against undefined symbol `blort'
can not be used when making a shared object; recompile with -fPIC

and indeed, adding -fPIC to the C compile command seems to fix the problem in that environment. However, it doesn't seem to have any effect in OS X.

All the other dynamic-linking questions I could find on SO seem to be about the more usual arrangement of libraries, where a library is being built to be linked into an executable before that executable runs, rather than the other way around. The closest related question I found was this:

which unfortunately has very little info, none of it relevant to the question I'm asking here.

UPDATE: I distilled the info from the answer along with everything else I'd figured out, and put together this example:

Upvotes: 1

Views: 429

Answers (1)

user529758
user529758

Reputation:

As far as my knowledge goes, you want to use weak linkage:

// mark function as weakly-linked
extern void foo() __attribute__((weak));

// inform the linker about that too
clang -dynamiclib -o bar.dylib bar.o -flat_namespace -undefined dynamic_lookup

If a weak function can be resolved at runtime, it will then be resolved. If it can't, it will be NULL, instead of generating a runtime (or, obviously, link-time) error.

Upvotes: 1

Related Questions