I've done so, following the wonderful tntdb library.
After a great deal of prouding aroung, I have managed to build and load
the shared library, and create an object through a C function in the
shared library:
extern "C" {
void *new_connection()
{
MySql_dbConnection *new_conn = new MySql_dbConnection();
return new_conn;
}
Everything fine up to this, but when in the main program I try to use a
virtual member of this MySql_dbConnection object, I get a segmentation
fault.
The address of the pointers seem wierd to me:
My main function has address: 0x8069ac4 [int main(int, char**)]
The new_connection function in my library has address: 0xb7fb00dc [void*
new_connection()]
The MySql_dbConnection object returned by new_connection() has address:
0x92753d0
And the main connection object declared in the main program (that
contains a pointer to the object in the library) has address: 0xbfdd66c8
It seems to me that the value 0x92753d0 for the connection created by
the library is suspicious. Can it be the reason for my segfault?
Regards,
--santilín
new_connection:0xb7fb00dc [void* new_connection()]
Bob Friesenhahn wrote:
> On Fri, 11 Sep 2009, santilin wrote:
>
>> Hi, I'm quite new to libtool though I have read the tree GNU manuals:
>> automake, autoconf and libtool.
>>
>> I want to solve the typical problem of loading dinamically one of the
>> sql servers drivers from my own shared library.
>>
>> I know I have to create a common interface for the drivers.
>>
>> What I am not sure is wheter I must use dlopen or there is any other way
>> of loading the library. If I use dlopen, lets say, to open mysql.so, I
>> have to read all the symbols and use pointers to them, which is a lot of
>> work. I wonder if there is a way of loading the libraries the same way
>> they are loaded when they are linked within the main program.
>
> I believe that you can use libltdl from libtool 2.X to do this by
> using lt_dlopenadvise() with the lt_dladvise_global option. This
> invokes dlopen() with the RTLD_GLOBAL flag.
>
> I don't recommend that you do this since it introduces ordering
> problems, is NOT PORTABLE, and does not solve the static linkage
> issue. If your code accidentally references a symbol before it is
> defined, then your program goes "poof".
>
> If you design a common interface for the drivers, then you can use
> libltdl to locate just one symbol in the driver which is a
> registration function which registers all of the interface functions
> that the driver supports. You could pass a structure containing all
> of the possible function vectors and the driver module updates it, or
> you could have the module call back into your library (which it can
> do) and add itself as a driver. This is more efficient than using
> libltdl to search for all of the possible symbols (some of which may
> not exist). This allows all of the implementation functions (except
> for the registration function) to be 'static' since they don't require
> external visibility.
>
> Bob
> --
> Bob Friesenhahn
> bfrie...@simple.dallas.tx.us,
> http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
>
>
> _______________________________________________
> http://lists.gnu.org/mailman/listinfo/libtool
>
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
