[gelöst] Linux SO-Module undefined symbol - wie debuggen?

frank schrieb:

danke für die schnelle Antwort...habe bei c++filt folgendes gefunden:

-_
--strip-underscores
On some systems, both the C and C++ compilers put an underscore in front of every name. For example, the C name foo gets the low-level name _foo. This option removes the initial underscore. Whether c++filt removes the underscore by default is target dependent.

Ja, aber in gtkwidget.h wird die struct _GtkWidget deklariert. Die dürfte hier gemeint sein, der "_" wird dann nicht entfernt. Irgendwo wird diese struct in Gtk umbenannt (per typedef oder Makro), möglicherweise fehlt dir nur ein include des passenden Header.

Aber mit Gtk kenne ich mich nicht aus, mehr kann ich dazu nicht sagen.

_frank_

Wie gesagt, das pagecontrol funktioniert.
Das nutzt vermutlich auch dieses struct.
Von gtk musste ich bisher immer nur die gtk.h importieren.

Gruß Frank

_frank_

Fehler gefunden,
ich habe die ListView.o nicht mit in das Modul gelinkt.

Gruß Frank

_frank_

kann man irgendwie auf der Kommandozeile prüfen, ob es unresolved symbols gibt? sonst werden die ja erst angezeigt, wenn das modul geladen wird.

evtl gibt es ja eine Möglichkeit das Modul direkt zu laden...

frank schrieb:

kann man irgendwie auf der Kommandozeile prüfen, ob es unresolved symbols gibt? sonst werden die ja erst angezeigt, wenn das modul geladen wird.

evtl gibt es ja eine Möglichkeit das Modul direkt zu laden...

ldd -r libfoo.so oder ldd -r programm
zeigt die nicht auflösbaren Symbole an.

Michael

_frank_

mhm, da zeigt er natürlich auch die Symbole an, die in der Lua-Umgebung definiert werden...kann man da bestimmte ignorieren?

frank schrieb:

mhm, da zeigt er natürlich auch die Symbole an, die in der Lua-Umgebung definiert werden...kann man da bestimmte ignorieren?

Hast du das ldd gegen die Lib oder gegen ein Binary ausgeführt?
Im ersten Fall kannst du sie ignorieren oder deine Lib mit der liblua linken, damit sie verschwinden. Letzteres ist meine bevorzugte Lösung, weil du dann nicht jedes Programm, das deine Lib nutzt, explizit mit Lua linken musst.

Michael

_frank_

meine lib ist nur für ein programm, und das hat lua schon integriert.
wenn dann würde ich höchstens nochmal gegen lua linken um den test mit ldd durchzuführen...

welche dateien von lua benötige ich dafür und wie sieht das linken direkt aus?

frank schrieb:

meine lib ist nur für ein programm, und das hat lua schon integriert.
wenn dann würde ich höchstens nochmal gegen lua linken um den test mit ldd durchzuführen...

welche dateien von lua benötige ich dafür und wie sieht das linken direkt aus?

In dem Fall würde ich die fehlenden Lua-Symbole in meiner Lib ignorieren
Welche der lua-Libs du brauchst wenn du linken willst, hängt von den Symbolen ab, die fehlen. Auf alle Fälle die liblua.so würde ich meinen.
Gelinkt wird dann wie dein Programm auch (-llua). Hängt v.a. von deinem Build-System ab, wie's genau ausschaut.
Nutzt du händisch verfasste Makefiles, automake und co, cmake oder ganz was anderes?

Michael

_frank_

ich entwickel nur die lib, das programm ist von jemand anderes

mein Makefile für die lib:
http://c-plusplus.net/forum/viewtopic-var-t-is-274563-and-highlight-is-.html

würde aber das linken außerhalb des makefiles verlagern, da ich das linken nur zum testen auf die unresolved symbols benötige und für die "Auslieferung" nicht benötigt wird. evtl. auch zusätzliches target im makefile

die liblia.so muss ich bei mir mal suchen, denke nicht, dass die bei gcc dabei ist, oder? notfalls muss ich mir mal die kompletten lua-sources ziehen oder mal bei dem Programm schauen, ob die da irgendwo rumliegt

_frank_

ich habs jetzt so hinbekommen:

#if lua not found this is needed: 
# sudo ln -s /usr/lib/liblua5.1.so.0 /usr/lib/liblua5.1.so
debug.so: $(OBJS)
	$(LD) $(INC) -llua5.1 $(LD-FLAGS) $@ $(OBJS)>/dev/null
	ldd -r $@ >/dev/null
	$(RM) $@ >/dev/null

und das makefile so aufrufen:

make -s debug.so

danke an alle

Gruß Frank