4

I have several object files (from C++) that are spat out of a build system. They have several extern "C"-linkage symbols I want to use in a program and have accessible via dlopen/dlsym from elsewhere.

When compiled into an executable with gcc, these symbols are not listed using nm -D <executable-here> (i.e. afaik they're not dynamic symbols).

How do I get them to become exposed as dynamic symbols within the compiled executable?

I can change the build flags for the object files and for the executable, but changing how the C++ files end up in the final executable (i.e. not making them into object files first) is difficult.

(GCC 4.8, ld 2.24)

EDIT: I came across this question, which may or may not be what I'm asking, but I'm not entirely sure. Use dlsym on a static binary

user
  • 4,920
  • 3
  • 25
  • 38
  • So you want to use your executable file as a shared library too? Typically, building one shared library that is used by multiple applications is the usual approach here. – Mats Petersson Oct 10 '14 at 08:23
  • Response to EDIT: Yes, it pretty much says the same thing my comment says: Either use a common shared library, or don't use `dlopen` and `dlsym`... – Mats Petersson Oct 10 '14 at 08:25
  • Yes... So, the strangeness: I'm embedding a Java VM in the program and it uses JNA/dlopen/dlsym to access extern C functions. It's preferable to keep everything in one executable so I don't need to mess with linker paths during development. If I pretty much *have* to make a shared library, then, meh, 'kay... – user Oct 10 '14 at 08:28

1 Answers1

4

You may like to take a look at --export-dynamic ld option:

   -E
   --export-dynamic
   --no-export-dynamic
       When creating a dynamically linked executable, using the -E option
       or the --export-dynamic option causes the linker to add all symbols
       to the dynamic symbol table.  The dynamic symbol table is the set
       of symbols which are visible from dynamic objects at run time.

       If you do not use either of these options (or use the
       --no-export-dynamic option to restore the default behavior), the
       dynamic symbol table will normally contain only those symbols which
       are referenced by some dynamic object mentioned in the link.

       If you use "dlopen" to load a dynamic object which needs to refer
       back to the symbols defined by the program, rather than some other
       dynamic object, then you will probably need to use this option when
       linking the program itself.

       You can also use the dynamic list to control what symbols should be
       added to the dynamic symbol table if the output format supports it.
       See the description of --dynamic-list.

       Note that this option is specific to ELF targeted ports.  PE
       targets support a similar function to export all symbols from a DLL
       or EXE; see the description of --export-all-symbols below.

Also, if none of the objects during link refers to your extern symbols, you may like to put them into --dynamic-list to make sure they are exported.

Example:

$ cat test.cc
#include <stdio.h>

int main() {
    printf("Hello, world\n");
}

extern "C" void export_this() {
    printf("Hello, world from export_this\n");
}

$ g++ -o test -W{all,extra} -Wl,--export-dynamic test.cc

$ ./test
Hello, world

$ nm --dynamic test | grep export_this
00000000004007f5 T export_this # <---- here you go
Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271
  • I actually gave this a try (sorry for not mentioning that in the question) along with the afaik closely related `-rdynamic` flag, and somehow it didn't work out. I may have just been doing it wrong, though. -.-' – user Oct 10 '14 at 08:36
  • 1
    You could try putting your symbols into `--dynamic-list` to make sure they are exported. – Maxim Egorushkin Oct 10 '14 at 08:38
  • Just did (using gcc via `-Wl,--dynamic-list `); strangely enough still getting symbol-not-found-errors. I think I'm going to throw my hands up and abuse rpaths with shared objects... – user Oct 10 '14 at 08:47
  • That would not be winner's attitude though ;) – Maxim Egorushkin Oct 10 '14 at 09:47
  • :-/ You speak the wise truth. I guess I'll revisit it at some point; I feel like what's written here *should* work. – user Oct 10 '14 at 09:51
  • This is a fairly common requirement, I would be surprised if it did not have a standard solution. From a different angle, [one notable example is `libc` - an executable shared library](http://stackoverflow.com/a/9706172/412080). See http://polentino911.wordpress.com/2013/08/08/make-your-own-executable-shared-library-on-linux/. – Maxim Egorushkin Oct 11 '14 at 01:15
  • Anyway, `--export-dynamic` seems to work as expected, see my update. May be you should review your build command lines. – Maxim Egorushkin Oct 11 '14 at 01:23