On Windows it is possible to dynamically link to an executable with exported symbols. For example following code:
// main.c
void __declspec(dllexport) interface_function() {}
int main() {}
// ext.c
void interface_function();
void extension_function() {
interface_function();
}
With
cl.exe main.c
cl.exe ext.c /LD /link main.lib
would produce an executable main.exe, a static library main.lib for implicit linking, and a dynamic library ext.dll.
Similar behavior can be achieved in OSX with shared libraries:
// main.c
void interface_function() {}
int main() {}
// ext.c
void interface_function();
void extension_function() {
interface_function();
}
With
gcc main.c -o main
gcc ext.c -bundle -bundle_loader main -o ext.bundle
it is virtually equivalent to the Windows setup.
But for dynamiclib:
> gcc ext.c -dynamiclib -o ext.dylib
and shared:
> gcc ext.c -shared -o ext.so
I cannot get them to work because of undefined symbols on one hand and unable to load an executable with -l flag on the other.
I can let them resolve undefined symbols in runtime with -undefined dynamic_lookup. But this is not a sustainable way because all the link errors are now happening in run-time instead.
Is there a way to provide the list of symbols to dynamically load from an executable when linking as -shared and -dynamiclib?
Yes this is possible, but then you'll want to create a bundle rather than a shared library (see this answer for more detail).
If you have a main application like so:
#include <stdio.h>
#include <dlfcn.h>
int func(void)
{
return 42;
}
int main(void)
{
void *dl = dlopen("plugin.so", RTLD_LOCAL);
if(!dl) return -1;
int (*derp)(void) = dlsym(dl, "derp");
if(!derp) return -1;
printf("derp(): %i\n", derp());
return 0;
}
clang -o main main.c -Wall -Wl,-export_dynamic
Then you can compile bundles against it like so:
int func(void);
int derp(void)
{
return -func();
}
clang -o plugin.so plugin.c -Wall -bundle -bundle_loader ./main
Related
I have a statically linked library, containing a global variable barvar. I can compile the library with no problems with either gcc-10 or clang (this is on macOS Catalina). Interestingly, the behavior differs between the two when I try to link it into a program that uses the library. Here's the code:
In globvars.h, int barvar is declared:
#ifndef H_GLOBVARS_H
#define H_GLOBVARS_H
extern int barvar;
#endif
In globvars.c, int barvar is defined:
#include "globvars.h"
int barvar;
In foo.c, the function foo sets and prints barvar:
#include <stdio.h>
#include "globvars.h"
void foo()
{
barvar = 10;
printf("barvar is: %d\n", barvar);
return;
}
Here's test.c, the program that uses the library:
void foo();
int main(int argc, char **argv)
{
foo();
return 0;
}
When I compile and link with gcc-10, no problems:
gcc-10 -c foo.c -o foo.o
gcc-10 -c globvars.c -o globvars.o
gcc-10 -c test.c -o test.o
gcc-ar-10 rcs liblinktest.a foo.o globvars.o
gcc -o testlinkrun test2.o -L. -llinktest
When I compile and link with clang, I get an undefined symbol error at the last step:
cc -c foo.c -o foo.o
cc -c globvars.c -o globvars.o
cc -c test.c -o test.o
ar rcs liblinktest.a foo.o globvars.o
cc -o testlinkrun test2.o -L. -llinktest
with error:
Undefined symbols for architecture x86_64:
"_barvar", referenced from:
_foo in liblinktest.a(foo.o)
Any ideas? Interestingly, it appears the only step that has to be done with gcc-10 is compiling globvars.c. I can use clang and the clang linker for all other steps, and everything is fine. Is it possible that clang is optimizing away all the variables in globvars.c? How can I prevent this?
As #EricPostpischil observed in this comment, the issue is that clang defaults to treating barvar as a common symbol. Either changing int barvar; to int barvar = 0;, or compiling with -fno-common, fix the issue.
Beginning with gcc-10, gcc's default behavior is -fno-common instead of -fcommon.
I'm in a situation that's quite similar to the following. There's libA.so that depending on some compile time flags exhibits slightly different behaviour (it's an external lib, and I can't modify the source). Then, I have libB.so that depends on libA.so (compiled with say -DVALUE=1), and in my executable I depend both on libB.so, as well as on libA.so, but compiled with -DVALUE=0. However, once I launch it, ld resolves all symbols with one of libA.so versions, so both my executable and libB.so are using the same functions.
Is there any way to specify that I want to load resolve undefined symbols of libB.so only using its dependencies? I've tried using -Wl,-Bgroup flag when building libB.so, but it didn't change anything. I know there's dlmopen that can load the library in a new namespace, but I'd like to have it loaded automatically at startup.
I'm attaching a set of files that reproduce the behaviour:
libA.so:
#include <stdio.h>
#define _STR(x) #x
#define STR(x) _STR(x)
#ifndef VALUE
#define VALUE default
#endif
void func2() {
printf(STR(VALUE) "\n");
}
void func() {
func2();
}
libB.so:
#include <stdio.h>
extern void func(void);
void b_func() {
func();
}
executable:
#include <stdio.h>
extern void b_func(void);
extern void func(void);
int main() {
func(); // should print "default"
b_func(); // should print "other"
}
build commands:
gcc -fPIC -shared A.c -o libA.so
gcc -fPIC -shared -DVALUE=other A.c -o libA2.so
gcc -fPIC -shared B.c -L. -lA2 -o libB.so
gcc main.c -L. -lA -lB -o main
Curiously, it all works fine on OS X.
I have a shared library which I want to access symbols from the main program. For example:
main.c
#include <stdio.h>
void bar(void) { puts("bar"); }
extern void foo(void);
int main(void) {
foo();
return 0;
}
foo.c
#include <stdio.h>
extern void bar(void);
void foo(void) {
puts("foo");
bar();
}
I compile and run like:
gcc -c -fpic foo.c
gcc -shared -o libfoo.so foo.o
gcc -L$(pwd) -o test main.c -lfoo
./test
And I get the output I expect:
foo
bar
However, I must use dlopen() and dlsym() because I want to have control over when the library is loaded. The changed files are:
main.c
#include <stdio.h>
#include <dlfcn.h>
void bar(void) { puts("bar"); }
int main(void) {
void *handle = dlopen("./libfoo.so", RTLD_LAZY);
void (*foo)(void) = (void(*)(void))dlsym(handle,"foo");
foo();
return 0;
}
foo.c
#include <stdio.h>
#include <dlfcn.h>
extern void bar(void);
void foo(void) {
puts("foo");
bar();
}
I instead compile and run with:
gcc -c -fpic foo.c
gcc -shared -o libfoo.so foo.o
gcc -o test main.c -ldl
./test
However, this time I get the output
foo
./test: symbol lookup error: ./libfoo.so: undefined symbol: bar
How can I reference symbols in the main program from libfoo?
You have to add the -rdynamic option when linking test:
gcc -o test main.c -ldl -rdynamic
From here:
-rdynamic
Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of dlopen or to allow obtaining backtraces from within a program.
I'm trying to call a "core" function from a shared library's function but I get:
./a.out: symbol lookup error: ./libtest.so: undefined symbol: testf
The code I'm using is very basic because I'm just getting into writing shared libraries and it's just for testing purposes:
main.h
extern void testf();
main.c
#include <stdio.h>
#include <dlfcn.h>
extern void testf()
{
printf("bla bla\n");
}
int main () {
void *handle = NULL;
void (*testlib)(void) = NULL;
handle = dlopen("./libtest.so" ,RTLD_LAZY);
testlib = dlsym(handle, "testfunc");
if ( testlib == NULL )
{
printf("Error: %s \n", dlerror());
}
else
{
testlib();
}
}
libtest.c
#include <stdio.h>
#include "main.h"
void testfunc() {
printf("Test plugin\n");
testf();
}
And the commands I compile it with:
gcc -fPIC -g -c -Wall libtest.c
gcc -shared -Wl,-soname,libtest.so.1 -o libtest.so libtest.o -lc
gcc main.c -ldl
Is it possible to achieve this? Tried to find the answer, but don't really know how to form the question right so I can search better for it.
Thanks!
here you are trying to call a function of a executable from the library. I think you actually required reverse of this.
Sorry, managed to find the answer:
I was compiling the main program with wrong parameters, should use:
gcc main.c -ldl -rdynamic
In the following example, the program should print "foo called\n":
// foo.c
#include <stdio.h>
__attribute__((constructor)) void foo()
{
printf("foo called\n");
}
// main.c
int main()
{
return 0;
}
If the program is compiled like this, it works:
gcc -o test main.c foo.c
However, if foo.c is compiled into a static library, the program prints nothing.
gcc -c main.c
gcc -c foo.c
as rcs foo.a foo.o
gcc -o test foo.a main.o
Why does this happen?
The linker does not include the code in foo.a in the final program because nothing in main.o references it. If main.c is rewritten as follows, the program will work:
//main.c
void foo();
int main()
{
void (*f)() = foo;
return 0;
}
Also, when compiling with a static library, the order of the arguments to gcc (or the linker) is significant: the library must come after the objects that reference it.
gcc -o test main.o foo.a
As it was stated, unreferenced symbols from archive does not make it to the output binary, because linker discards them by default.
To override this behaviour when linking with static library, --whole-archive/--no-whole-archive options for the linker may be used, like this:
gcc -c main.c
gcc -c foo.c
ar rcs foo.a foo.o
gcc -o test -Wl,--whole-archive foo.a -Wl,--no-whole-archive main.o
This may lead to bloated binary, because all symbols from foo.a will be included by the linker to the output, but sometimes it is justified.