[C++] Met Libtool een klasse uit een module halen

[LauPro]

Momenteel ben ik bezig met een project waarbij een programma middels libtool een aantal modules kan laden. In deze modules zitten verschillende functies. Om het geheel makkelijk aan te spreken wilde ik dit via een klasse doen naar de hand van de volgende howto: http://www.isotton.com/ho...++-dlopen-mini-HOWTO.html

Echter krijg ik het niet voor elkaar om een klasse vanuit de module in de main-executable te krijgen .

Het zit hem er in dat wanneer ik dus vanuit de module een nieuwe klasse return de library niet kan openen en een 'cannot open shared object file: No such file or directory' krijg. Als ik niets return loopt het wel goed .

De relevante code, eerst de basisklasse voor modules:

C++:

class module {
public:
    virtual void test();
};

En dan een voorbeeld van een module:

C++:

#include <iostream>
#include "../../../modulebase.h"

using namespace std;

class custom_module : public module {
public:
    virtual void test() {
        cout << "hi, this is a test for the module ja";
    }
};

extern "C" module* init_module() {
    std::cout << "hello" << '\n';
    return new custom_module; // <- hier gaat het fout
}

extern "C" void exit_module() {
    std::cout << "bye" << '\n';
}

Het loopt dus al fout als ik in het hoofdprogramma het volgende aan roep:

C++:

lt_dlhandle handle = lt_dlopen(file.c_str());

Want wanneer ik niets return dan wordt er wel vrolijk tekst geschreben naar cout.

Beetje wazig probleem weliicht, maar ik volg het ook niet meer waar het nu op stuk loopt, wellicht dat ik die basisklasse als shared library moet laden? Maar dat wordt nergens vermeld.

[ Voor 12% gewijzigd door LauPro op 06-09-2005 22:21 ]

[Creepy]

Als je dlopen al mis gaat dan kan je de shared lib niet eens openen. Het lijkt me sterk dat het wel of niet returnen van een pointer in een functie veel uitmaakt. Je geeft wel een volledig pad op naar de library of deze staat wel in het path dat libtool doorzoekt?

[LauPro]

Wanneer ik return new custom_module; comment werkt het wel (ik de zin van dat ik de tekst hoi en bye zie zegmaar). Dus het ligt naar mijn idee niet aan de code die dlopen e.d. aan roept, maar meer aan het wel of niet voorkomen van klassen in de module. Blijkbaar neemt hij de baseklasse niet over waardoor er een brakke library ontstaat die libtool niet kan openen .

edit: Heb zojuist even een shared object file gemaakt waar de definitie van de klasse in staat, dit maakt geen verschil voor zover ik zie. Het zit hem toch in het foutief aanmaken van de klasse op de een of andere manier.

[ Voor 32% gewijzigd door LauPro op 06-09-2005 22:17 ]

[LauPro]

Na wat experimenteren werkt blijkmaar het 'morphing' niet goed. Wanneer ik in de module een echt dezelfde klasse definieer als in het hoofdprogramma (maar dan met aparte functies) dan loopt het wel goed:

C++:

#include <iostream> 
 
using namespace std; 
 
class module { 
public: 
    virtual void test() { 
        cout << "hi, this is a test for the module ja"; 
    } 
}; 
 
extern "C" module* init_module() { 
    return new module;
} 

Maar dit is natuurlijk niet praktisch, ik zou wel graag een basisklasse willen blijven houden (aangezien sommige functies liever wel mee moeten zegmaar).

[MSalters]

Even voor de duidelijkheid: dlopen( ) faalt in je main executable als je .so een bepaalde regel code bevat

[Creepy]

* Creepy vindt dat ook enorm vaag ja. dlopen en libtool zal het echt een worst zijn wat je verder in je shared lib doet.
Je kan op de manier die je gebruikt prima subclasses op die manier doorgeven. Als het doorgeven van een subclass een fout oplevert geeft dan zal dat nooit de melding zijn die je in eerste instantie gaf.
Klinkt als een gevalletje: "loop eens met een debugger stap voor stap door je code heen en kijk eens waar en waarom het nu precies mis gaat".

[LauPro]

KDevelop heeft blijkbaar nog geen lekkere support om aparte libraries te debuggen, bij mij krijg ik op dat moment een segfault als hij op het punt staat middels lt_dlopen() de library in te lezen.

Maar voor de duidelijkheid:

C++:

extern "C" module* init_module() {  
    return new module; 
}

Werk maar:

C++:

extern "C" module* init_module() {  
    return new custom_module; 
}

Niet.

Ik heb toch het idee dat ik de klasse niet goed definieer?

[.oisyn]

In welk project is je module gedefinieerd? Want module::test is niet pure, en dus moet de (runtime) linker access hebben tot de implementatie van die functie om de vtable goed te zetten in de (default) constructor van module. Ik vermoed dat als module gedefinieerd is in je applicatie, en je simpelweg een header include in je shared lib, en je applicatie verder niet die symbols van module export, je dlopen() call dus failt.

Dit verklaart ook waarom het wel werkt als je die new statement wegcomment (er is dan geen referentie meer naar een custom_module en dus wordt ie ook niet meegelinkt) of als je geen common base gebruikt (je geeft dan zelf de definitie van module::test in je shared lib).

Dus maak die test functie in module eens pure en probeer het dan nog 'ns?

[LauPro]

Helemaal correct .oisyn , ik heb de functie pure gemaakt en nu werk het .

[LauPro]

Nu ben ik tegen een ander (vergelijkbaar probleem) aangelopen. Het modules laden e.d. werkt nu goed, echter nu wil ik uit een module bijvoorbeeld een andere klasse halen. Ints en stings gaan goed echter een zelfgedefinieerd iets loopt hij op stuk. Hieronder de algemene module declaratie:

C++:

class eigenklasse {
public:
    int getal;
}

class module { 
public: 
    virtual void test() = 0; 
    virtual eigenklasse* testklasse() = 0;
};

Dan bijvoorbeeld een module:

C++:

#include <iostream> 
#include "../../../modulebase.h" 
 
using namespace std; 
 
class custom_module : public module { 
public: 
    virtual void test() { 
        return;
    } 

    virtual eigenklasse* test() { 
        return new eigenklasse();
    } 
};

Dit levert al een "cannot open shared object file: No such file or directory" op. Zo te zien is er dus iets mis met de linking. Maar ik heb echt geen idee wat ik fout doe aangezien het eigenlijk precies hetzelfde is als init_module e.d. alleen nu binnen die klasse .

[LauPro]

Even een update (voor de search). Uiteindelijk ben ik hier terecht gekomen:

http://sources.redhat.com.../autobook_165.html#SEC165

Daar geeft men aan dat je eigenlijk de basisklasse voor dergelijke modules in een shared lib moet gooien. Deze link je dan aan je modules en aan je main executable. Dit is het makkelijkst omdat je anders de modules eigenlijk voor bepaalde functies tegen je main-file aan moet linken. En dat geeft errors zoals het bovenstaande als dat niet goed gebeurd.

Erg vet systeem met libtool overigens .