dynamic library issue: dlsym() failing to find smbol
I've been following Apple's Dynamic Library Programming Topics
docs to create and use a runtime-loaded library using dlopen()
/ dlsym()
.
It seems I'm getting a failure to find the desired symbol on my Mid 2012 MacBook Air, running macOS Mojave.
Library Source Code
// adder.h
int add(int x);
and
// adder.cpp
#include "adder.h"
int add(int x) {
return (x + 1);
}
Compiled with clang -dynamiclib adder.cpp -o libAdd.A.dylib
Main Source
// main.cpp
#include <stdio.h>
#include <dlfcn.h>
#include <stdlib.h>
#include "adder.h"
int main() {
void* adder_handle = dlopen("libAdd.A.dylib", RTLD_LOCAL|RTLD_LAZY);
if (!adder_handle) {
printf("[%s] Unable to load library: %snn", __FILE__, dlerror());
exit(EXIT_FAILURE);
}
while(true) {
void* voidptr = dlsym(adder_handle, "add");
int (*add)(int) = (int (*)(int))voidptr;
if (!add) {
printf("[%s] Unable to get symbol: %snn", __FILE__, dlerror());
exit(EXIT_FAILURE);
}
printf("%dn", add(0));
}
dlclose(adder_handle);
return 0;
}
Compiled with clang main.cpp -o main
I've also set the DYLD_LIBRARY_PATH
environment variable to ensure the library can be found. Everything compiles ok.
Nevertheless, when I run the main executable, I get the error:
[main.cpp] Unable to get symbol: dlsym(0x7fb180500000, add): symbol not found
Running nm -gC libAdd.A.dylib
outputs:
0000000000000fa0 T add(int)
U dyld_stub_binder
Any ideas on what could be wrong, or what I need to do to debug this issue?
Thanks!
c++ dynamic-library
add a comment |
I've been following Apple's Dynamic Library Programming Topics
docs to create and use a runtime-loaded library using dlopen()
/ dlsym()
.
It seems I'm getting a failure to find the desired symbol on my Mid 2012 MacBook Air, running macOS Mojave.
Library Source Code
// adder.h
int add(int x);
and
// adder.cpp
#include "adder.h"
int add(int x) {
return (x + 1);
}
Compiled with clang -dynamiclib adder.cpp -o libAdd.A.dylib
Main Source
// main.cpp
#include <stdio.h>
#include <dlfcn.h>
#include <stdlib.h>
#include "adder.h"
int main() {
void* adder_handle = dlopen("libAdd.A.dylib", RTLD_LOCAL|RTLD_LAZY);
if (!adder_handle) {
printf("[%s] Unable to load library: %snn", __FILE__, dlerror());
exit(EXIT_FAILURE);
}
while(true) {
void* voidptr = dlsym(adder_handle, "add");
int (*add)(int) = (int (*)(int))voidptr;
if (!add) {
printf("[%s] Unable to get symbol: %snn", __FILE__, dlerror());
exit(EXIT_FAILURE);
}
printf("%dn", add(0));
}
dlclose(adder_handle);
return 0;
}
Compiled with clang main.cpp -o main
I've also set the DYLD_LIBRARY_PATH
environment variable to ensure the library can be found. Everything compiles ok.
Nevertheless, when I run the main executable, I get the error:
[main.cpp] Unable to get symbol: dlsym(0x7fb180500000, add): symbol not found
Running nm -gC libAdd.A.dylib
outputs:
0000000000000fa0 T add(int)
U dyld_stub_binder
Any ideas on what could be wrong, or what I need to do to debug this issue?
Thanks!
c++ dynamic-library
Avoid C++ when using shared libraries; if you cannot, at least useextern "C"
– Lorinczy Zsigmond
Nov 13 '18 at 20:38
add a comment |
I've been following Apple's Dynamic Library Programming Topics
docs to create and use a runtime-loaded library using dlopen()
/ dlsym()
.
It seems I'm getting a failure to find the desired symbol on my Mid 2012 MacBook Air, running macOS Mojave.
Library Source Code
// adder.h
int add(int x);
and
// adder.cpp
#include "adder.h"
int add(int x) {
return (x + 1);
}
Compiled with clang -dynamiclib adder.cpp -o libAdd.A.dylib
Main Source
// main.cpp
#include <stdio.h>
#include <dlfcn.h>
#include <stdlib.h>
#include "adder.h"
int main() {
void* adder_handle = dlopen("libAdd.A.dylib", RTLD_LOCAL|RTLD_LAZY);
if (!adder_handle) {
printf("[%s] Unable to load library: %snn", __FILE__, dlerror());
exit(EXIT_FAILURE);
}
while(true) {
void* voidptr = dlsym(adder_handle, "add");
int (*add)(int) = (int (*)(int))voidptr;
if (!add) {
printf("[%s] Unable to get symbol: %snn", __FILE__, dlerror());
exit(EXIT_FAILURE);
}
printf("%dn", add(0));
}
dlclose(adder_handle);
return 0;
}
Compiled with clang main.cpp -o main
I've also set the DYLD_LIBRARY_PATH
environment variable to ensure the library can be found. Everything compiles ok.
Nevertheless, when I run the main executable, I get the error:
[main.cpp] Unable to get symbol: dlsym(0x7fb180500000, add): symbol not found
Running nm -gC libAdd.A.dylib
outputs:
0000000000000fa0 T add(int)
U dyld_stub_binder
Any ideas on what could be wrong, or what I need to do to debug this issue?
Thanks!
c++ dynamic-library
I've been following Apple's Dynamic Library Programming Topics
docs to create and use a runtime-loaded library using dlopen()
/ dlsym()
.
It seems I'm getting a failure to find the desired symbol on my Mid 2012 MacBook Air, running macOS Mojave.
Library Source Code
// adder.h
int add(int x);
and
// adder.cpp
#include "adder.h"
int add(int x) {
return (x + 1);
}
Compiled with clang -dynamiclib adder.cpp -o libAdd.A.dylib
Main Source
// main.cpp
#include <stdio.h>
#include <dlfcn.h>
#include <stdlib.h>
#include "adder.h"
int main() {
void* adder_handle = dlopen("libAdd.A.dylib", RTLD_LOCAL|RTLD_LAZY);
if (!adder_handle) {
printf("[%s] Unable to load library: %snn", __FILE__, dlerror());
exit(EXIT_FAILURE);
}
while(true) {
void* voidptr = dlsym(adder_handle, "add");
int (*add)(int) = (int (*)(int))voidptr;
if (!add) {
printf("[%s] Unable to get symbol: %snn", __FILE__, dlerror());
exit(EXIT_FAILURE);
}
printf("%dn", add(0));
}
dlclose(adder_handle);
return 0;
}
Compiled with clang main.cpp -o main
I've also set the DYLD_LIBRARY_PATH
environment variable to ensure the library can be found. Everything compiles ok.
Nevertheless, when I run the main executable, I get the error:
[main.cpp] Unable to get symbol: dlsym(0x7fb180500000, add): symbol not found
Running nm -gC libAdd.A.dylib
outputs:
0000000000000fa0 T add(int)
U dyld_stub_binder
Any ideas on what could be wrong, or what I need to do to debug this issue?
Thanks!
c++ dynamic-library
c++ dynamic-library
asked Nov 13 '18 at 20:01
Ian TaylorIan Taylor
205212
205212
Avoid C++ when using shared libraries; if you cannot, at least useextern "C"
– Lorinczy Zsigmond
Nov 13 '18 at 20:38
add a comment |
Avoid C++ when using shared libraries; if you cannot, at least useextern "C"
– Lorinczy Zsigmond
Nov 13 '18 at 20:38
Avoid C++ when using shared libraries; if you cannot, at least use
extern "C"
– Lorinczy Zsigmond
Nov 13 '18 at 20:38
Avoid C++ when using shared libraries; if you cannot, at least use
extern "C"
– Lorinczy Zsigmond
Nov 13 '18 at 20:38
add a comment |
1 Answer
1
active
oldest
votes
C++ actually mangles the functionname which results in a different symbolname.
Your are able to spot these mangled symbol names using nm -g <yourlib.dylib>
You can change this behavior by wrapping your method into
extern "C" {
int add(int x);
}
@BradAllred can you elaborate a bit on this? the above solution worked just fine with no changes to the main.cpp file, but I was curious whynm -g
showed the symbol name to be_add
.
– Ian Taylor
Nov 13 '18 at 20:32
1
> but I was curious whynm -g
showed the symbol name to be_add
this is I think some MacOS specific mangling, linux in fact does this not. It names this symbol justadd
– wiomoc
Nov 13 '18 at 20:38
2
In C++ you could overload functions/methods or have the same functionname in different classes, because of that compiler has to map the function name to unique symbols, he does that using mangling.
– wiomoc
Nov 13 '18 at 20:49
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53288637%2fdynamic-library-issue-dlsym-failing-to-find-smbol%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
C++ actually mangles the functionname which results in a different symbolname.
Your are able to spot these mangled symbol names using nm -g <yourlib.dylib>
You can change this behavior by wrapping your method into
extern "C" {
int add(int x);
}
@BradAllred can you elaborate a bit on this? the above solution worked just fine with no changes to the main.cpp file, but I was curious whynm -g
showed the symbol name to be_add
.
– Ian Taylor
Nov 13 '18 at 20:32
1
> but I was curious whynm -g
showed the symbol name to be_add
this is I think some MacOS specific mangling, linux in fact does this not. It names this symbol justadd
– wiomoc
Nov 13 '18 at 20:38
2
In C++ you could overload functions/methods or have the same functionname in different classes, because of that compiler has to map the function name to unique symbols, he does that using mangling.
– wiomoc
Nov 13 '18 at 20:49
add a comment |
C++ actually mangles the functionname which results in a different symbolname.
Your are able to spot these mangled symbol names using nm -g <yourlib.dylib>
You can change this behavior by wrapping your method into
extern "C" {
int add(int x);
}
@BradAllred can you elaborate a bit on this? the above solution worked just fine with no changes to the main.cpp file, but I was curious whynm -g
showed the symbol name to be_add
.
– Ian Taylor
Nov 13 '18 at 20:32
1
> but I was curious whynm -g
showed the symbol name to be_add
this is I think some MacOS specific mangling, linux in fact does this not. It names this symbol justadd
– wiomoc
Nov 13 '18 at 20:38
2
In C++ you could overload functions/methods or have the same functionname in different classes, because of that compiler has to map the function name to unique symbols, he does that using mangling.
– wiomoc
Nov 13 '18 at 20:49
add a comment |
C++ actually mangles the functionname which results in a different symbolname.
Your are able to spot these mangled symbol names using nm -g <yourlib.dylib>
You can change this behavior by wrapping your method into
extern "C" {
int add(int x);
}
C++ actually mangles the functionname which results in a different symbolname.
Your are able to spot these mangled symbol names using nm -g <yourlib.dylib>
You can change this behavior by wrapping your method into
extern "C" {
int add(int x);
}
answered Nov 13 '18 at 20:10
wiomocwiomoc
441311
441311
@BradAllred can you elaborate a bit on this? the above solution worked just fine with no changes to the main.cpp file, but I was curious whynm -g
showed the symbol name to be_add
.
– Ian Taylor
Nov 13 '18 at 20:32
1
> but I was curious whynm -g
showed the symbol name to be_add
this is I think some MacOS specific mangling, linux in fact does this not. It names this symbol justadd
– wiomoc
Nov 13 '18 at 20:38
2
In C++ you could overload functions/methods or have the same functionname in different classes, because of that compiler has to map the function name to unique symbols, he does that using mangling.
– wiomoc
Nov 13 '18 at 20:49
add a comment |
@BradAllred can you elaborate a bit on this? the above solution worked just fine with no changes to the main.cpp file, but I was curious whynm -g
showed the symbol name to be_add
.
– Ian Taylor
Nov 13 '18 at 20:32
1
> but I was curious whynm -g
showed the symbol name to be_add
this is I think some MacOS specific mangling, linux in fact does this not. It names this symbol justadd
– wiomoc
Nov 13 '18 at 20:38
2
In C++ you could overload functions/methods or have the same functionname in different classes, because of that compiler has to map the function name to unique symbols, he does that using mangling.
– wiomoc
Nov 13 '18 at 20:49
@BradAllred can you elaborate a bit on this? the above solution worked just fine with no changes to the main.cpp file, but I was curious why
nm -g
showed the symbol name to be _add
.– Ian Taylor
Nov 13 '18 at 20:32
@BradAllred can you elaborate a bit on this? the above solution worked just fine with no changes to the main.cpp file, but I was curious why
nm -g
showed the symbol name to be _add
.– Ian Taylor
Nov 13 '18 at 20:32
1
1
> but I was curious why
nm -g
showed the symbol name to be _add
this is I think some MacOS specific mangling, linux in fact does this not. It names this symbol just add
– wiomoc
Nov 13 '18 at 20:38
> but I was curious why
nm -g
showed the symbol name to be _add
this is I think some MacOS specific mangling, linux in fact does this not. It names this symbol just add
– wiomoc
Nov 13 '18 at 20:38
2
2
In C++ you could overload functions/methods or have the same functionname in different classes, because of that compiler has to map the function name to unique symbols, he does that using mangling.
– wiomoc
Nov 13 '18 at 20:49
In C++ you could overload functions/methods or have the same functionname in different classes, because of that compiler has to map the function name to unique symbols, he does that using mangling.
– wiomoc
Nov 13 '18 at 20:49
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53288637%2fdynamic-library-issue-dlsym-failing-to-find-smbol%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Avoid C++ when using shared libraries; if you cannot, at least use
extern "C"
– Lorinczy Zsigmond
Nov 13 '18 at 20:38