> I know that I should avoid such things, but just curious, is it something > inside sqlite that probably makes one dynanmically linked and other > dynamically loaded library share global data and can this be avoidable?
No, it's Linux linker who works like that. If you have several libraries loaded into the process with the same exported symbols then everybody using those symbols will be linked against ones located in the library loaded first. Any symbols located in libraries loaded after that won't be used. This is the default behavior of Linux linker (it can be changed but AFAIK it's changed very rarely) and this feature can produce sometimes very nasty results. E.g. if you try to load the same library located in different directories then initialization code will be executed in both of them, but they both will be executed against the same global/static variables. And it could lead to problems during initialization and definitely will lead to problems during finalization (like double frees, segmentation faults etc.). So if you ever want to use dlopen() you should be really really careful to avoid loading the same library several times (even if the same library have different file names). Pavel On Thu, Jun 9, 2011 at 9:56 AM, Max Vlasov <max.vla...@gmail.com> wrote: > On Tue, Jun 7, 2011 at 9:22 PM, Martin Gadbois <mgadb...@gmail.com> wrote: > >> On Tue, Jun 7, 2011 at 12:52 PM, Jay A. Kreibich <j...@kreibi.ch> wrote: >> >> > On Tue, Jun 07, 2011 at 07:47:25PM +0400, Max Vlasov scratched on the >> wall: >> > > Hi, >> > > >> > > I'm trying to use sqlite with linux (Ubuntu, Pascal, Lazarus). I'm >> still >> > not >> > > very familiar with linux development so I might miss something >> essential. >> > > >> > > Two scenarios work ok >> > > - statically linked latest version compiled (3.7.6.3), no options or >> > defines >> > > changed >> > > - Dynamically loaded (dlopen) sqlite used from the installed package >> > > libsqlite3 (libsqlite3.so) >> > >> > That's not how dynamic libraries work (not normally, anyways). >> > Generally you simply tell the compiler/linker to link in the library >> > at build time, and allow the usage of dynamic libs. The dynamic >> > link is then done on application start-up by the OS. In Windows >> > terms, it is like using an .DLL by linking in the associated .lib >> > file. Moving from a static library to a dynamic library requires no >> > code changes. >> > >> >> >> There is a way to do a _good_ shared library. I suggest reading the >> excellent paper: http://www.akkadia.org/drepper/dsohowto.pdf >> >> As for the OP question, do >> gcc -shared -Wl,-init=sqlite3_initialize -o libsqlite.so sqlite3.o >> >> and then link your application with >> gcc -L. -lsqlite -o test test.c >> >> This assumes that libsqlite.so is in your current path: . (thus the -L.) >> >> > > Martin and Jay, thanks for the info. > > The hint helped be to track the problem. > > It appears that my problem was that I forgot to remove dynamic linking of > libsqlite3.so library and had my own dynamic loading of another sqlite > binary. Since the exceptions was when sqlite accessed sqlite global config > (sqlite3GlobalConfig), I suppose they were probably magically sharing the > global data or something like that. > > I know that I should avoid such things, but just curious, is it something > inside sqlite that probably makes one dynanmically linked and other > dynamically loaded library share global data and can this be avoidable? I > thought that two libraries having different filenames and sonames virtually > different for the system, but it looks like they're not. > > Thanks > > Max > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
