CODEWITHSUNDEEP
cgccshared-libraries
Pavan
Pavan

Reputation: 668

how to manage undefined symbols in a shared library

I have a shared library which has undefined symbol 

JNI_CREATEJavaVM

Is there any way i can include the external dependency or tell the compiler to ignore the symbol?

Upvotes: 0

Views: 2866

Answers (2)

sr01853
sr01853

Reputation: 6121

Yes, you can tell the compiler to ignore the symbol.

From man ld,

--unresolved-symbols=method

Determine how to handle unresolved symbols. There are four possible values for method:

   ignore-all
       Do not report any unresolved symbols.

   report-all
       Report all unresolved symbols.  This is the default.

   ignore-in-object-files
       Report unresolved symbols that are contained in shared
       libraries, but ignore them if they come from regular object files.

   ignore-in-shared-libs
       Report unresolved symbols that come from regular object
       files, but ignore them if they come from shared libraries.

Upvotes: 5

Konstantin Vladimirov
Konstantin Vladimirov

Reputation: 6999

1) I think (telepathy mode on) that you are trying to build libdvm.so and get hack around Java NDK, that do not exposes JNI_CREATEJavaVM function. Don't do it. Go and google why not and what are other possible solutions.

2) Since your question sounds like "how to manage", I will present my favorite way to manage such things -- by introducing fake weak definitions. Lets step out building shared libraries, since there are really don't matter what do we building. Consider we have some undesym.c file with code:

int
main(void)
{
  JNI_CREATEJavaVM();
  return 0;
}

It produces undefined reference to `JNI_CREATEJavaVM' error.

Lets add to linking module fakeone.c with fake weak stub:

#include "assert.h"

int  __attribute__((weak))
JNI_CREATEJavaVM(void)
{
  assert(0 == "stub JNI_CREATEJavaVM is not for call");
  return 0;
}

Now everything links ok, but on stub call produces runtime assertion

a.out: fakeone.c:6: JNI_CREATEJavaVM: Assertion `0 == "stub JNI_CREATEJavaVM is not for call"' failed

But why is it weak? Because consider somebody links it with real JNI_CREATEJavaVM code. For example try goodone.c

#include "stdio.h"

int
JNI_CREATEJavaVM(void)
{
  printf("JNI_CREATEJavaVM Ok\n");
  return 0;
}

And compile gcc undesym.c goodone.c fakeone.c Now correct definition overwrites weak stub and you will get correct message.

Surely you must try to avoid this technique, but it helped me several times.

Upvotes: 5

Related Questions