Dlopen undefined symbol linux

dlopen: undefined symbol

пытаюсь прикрутить к проге поддержку плагинов. однако «не выходит каменный цветок» (ц).

в программе есть несколько глобальных переменных, которые в плагине объявлены как extern. при сборке/запуске самой проги все части проги видят эти символы нормально. плагин тоже собирается нормально, однако при загрузке либы dlerror() говорит:

/opt/editors/lib/polina/sample.so: undefined symbol: main_window: Success

main_window объявляется и инициализируется до загрузки плагина. dlopen() делаю с RTLD_NOW|RTLD_GLOBAL

Re: dlopen: undefined symbol

1) где объявлены эти глобальные переменные
2) где вызывается dlopen и следом dlerror

Re: dlopen: undefined symbol

Re: dlopen: undefined symbol

в параметрах gtk_dialog_new_with_buttons() как раз и есть это самое main_window

Re: dlopen: undefined symbol

Попробуй при компиляции main.c добавить при вызове компилятора ключ -rdynamic.

Re: dlopen: undefined symbol

И ещё. Это написано в мане (man dlopen). Цитирую:

External references in the library are resolved using the libraries in that library’s dependency list and any other libraries previously opened with the RTLD_GLOBAL flag. If the executable was linked with the flag «-rdynamic», then the global symbols in the executable will also be used to resolve references in a dynamically loaded library.

Нужно внимательнее читать.

Ещё. Вызов perror(dlerror()) бессмыслен. dlopen (опять же — см. ман) не выставляет errno. Так что диагностику нужно выводить так:

Источник

Receive «undefined symbol» error when loading library with dlopen

I’m writing some code that uses dynamic shared libraries as plugins.

My command line for building the shared libraries looks like:

Within the module, I can call functions that are in any other shared library that has been loaded within the main executable.

However I cannot access (exported) functions that are in the executable itself (I get undefined symbol errors).

My call to dlopen looks like this:

Can anyone please advise how my module can call back to my executable, without having to put all of the executable’s utility functions into yet another shared library?

3 Answers 3

Correct solution is to add -rdynamic to the link command of the main executable. This will add appropriate option to ld (which, when using GNU ld , happens to be —export-dynamic ).

Adding —export-dynamic directly is technically incorrect: it’s a linker option, and so should be added as -Wl,—export-dynamic , or -Wl,-E . This is also less portable than -rdynamic (other linkers have an equivalent, but the option itself is different).

I’ve found the answer myself.

I had to add the —export-dynamic flags to the link options for the main executable.

When creating a dynamically linked executable, 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 this option, 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.

Источник

Linux c++ error: undefined reference to ‘dlopen’

I work in Linux with C++ (Eclipse), and want to use a library. Eclipse shows me an error:

Do you know a solution?

Here is my code:

11 Answers 11

You have to link against libdl, add

to your linker options

@Masci is correct, but in case you’re using C (and the gcc compiler) take in account that this doesn’t work:

Took me a bit to figure out.

That’s one annoying «feature» for sure

I was struggling with it when writing heredoc syntax and found some interesting facts. With CC=Clang , this works:

as well as all of these:

• $CC -ldl -x c -o app.exe —
• $CC -x c -ldl -o app.exe —
• $CC -x c -o app.exe -ldl —
• $CC -x c -o app.exe — -ldl

However, with CC=gcc , only the last variant works; -ldl after — (the stdin argument symbol).

I was using CMake to compile my project and I’ve found the same problem.

The solution described here works like a charm, simply add $ to the target_link_libraries() call

The topic is quite old, yet I struggled with the same issue today while compiling cegui 0.7.1 (openVibe prerequisite).

What worked for me was to set: LDFLAGS=»-Wl,—no-as-needed» in the Makefile.

I’ve also tried -ldl for LDFLAGS but to no avail.

you can try to add this

to the configure options

You needed to do something like this for the makefile:

That’ll pass the linker flags from make through to the linker. Doesn’t matter that the makefile was autogenerated.

I met the same problem even using -ldl .

Besides this option, source files need to be placed before libraries, see undefined reference to `dlopen’.

In order to use dl functions you need to use the -ldl flag for the linker.

how you do it in eclipse ?

Press Project —> Properties —> C/C++ build —> Settings —> GCC C++ Linker —>
Libraries —> in the «Libraries(-l)» box press the «+» sign —> write «dl» (without the quotes)-> press ok —> clean & rebuild your project.

Источник

Linux shared library that uses a shared library undefined symbol

two shared libraries liba.so and libb.so. liba.so uses libb.so. All c files are compiled with -fPIC. Linking uses -shared. When we call dlopen on liba.so it cannot find symbols in libb.so. we get the «undefined symbol» error. We can dlopen libb.so with no errors. We know that liba is finding libb because we don’t get a file not found error. We get a file not found error when we delete libb.so. We tried -lutil and no luck.

oh yeah. gcc 4.1.2

update: We use rpath when linking liba so it can find libb.

ldd liba.so returns:

is it significat that there is no .# at the end of libb.

2 Answers 2

You can easily check where libb.so is expected to be with ldd command:

If it’s not found , libb.so ‘s path should be added to /etc/ld.so.conf or shell variable LD_LIBRARY_PATH .

Another way is setting rpath in the liba.so itself — it’s basically hardcoding its path so when the binary is started the dynamic linker would know where to search for the shared libraries.

If rpath is not set it will first search in LD_LIBRARY_PATH , then the paths mentioned in /etc/ld.so.conf (or /etc/ld.so.conf.d/). After adding to ls.so.conf don’t forget to execute /sbin/ldconfig

Dynamic linker searches the dependent shared libraries by their soname (if it’s set) — if soname is not set (with -Wl,-soname,libb.so.1 for example), it will be searched by library’s name.

Example: libb.so.1.0 is your actual library, having soname — libb.so.1 . You would normally have the following files structure:

where libb.so and libb.so.1 are symlinks.

You usually link to libb.so , when building some application or other library, depending on libb.so .

When the application is started (or dlopen is executed — your case) — the dynamic linker will search for file with name libb.so.1 — the soname of dependent library, if the soname is set, not libb.so .

That’s why you need that symlink libb.so.1 , pointing to the actual library.

If you use ld.so.conf and ldconfig , it will create the symlink with soname ‘s name, pointing to the library file, if this symlink is missing.

You can see ld-linux man page for more useful info.

If the library is found but some of the symbols are missing, try building libb.so with -Wl,—no-undefined option

It should give you an error if you missed to define some symbol.

Источник

Shared Library Undefined Symbol for Linux #1746

Comments

ghost commented Sep 8, 2016

Trying to «dlopen» a shared library using Ubuntu 16.04 with the latest release of ldc2. Results in the following error:

undefined symbol: _d_eh_personality

The text was updated successfully, but these errors were encountered:

dnadlinger commented Sep 9, 2016

Loading shared libraries from C as well as D hosts processes on Linux is tested as part of our test suite, so I’m afraid you’ll have to provide some more information as to what exactly you are trying to do. LD_DEBUG=all might also help.

ghost commented Sep 10, 2016

The contents of the shared library:

The application loading the shared library:

The library fails to load using dlopen and dlerror spits out the undefined symbol. Compiled using dub. Same code and such works with DMD, not entirely if the compiler parameters are wrong from dub but I tried messing around with them a bit and still couldn’t get it to work properly.

dnadlinger commented Sep 10, 2016

Do you have a shared library build of LDC (i.e. druntime/Phobos)? Are the standard libraries on the search path? Does ldd libmylib.so correctly find libdruntime-ldc.so? There should be no special compiler arguments necessary.

ghost commented Sep 10, 2016

Got it working, dub sets the default lib to phobos2, which makes ldc use dmd’s phobos. Also any reason why the shared libraries aren’t included in the release?

dnadlinger commented Sep 10, 2016

That’s a pretty severe bug in Dub, then. Could you please file it there?

Shipping both by default is just an issue of figuring out a last few details, see #1282.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник