On Thu, Jun 9, 2011 at 6:21 PM, Pavel Ivanov <[email protected]> wrote:
> > 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.). > > Occasionally found the the flag RTLD_DEEPBIND for dlopen helped. I suppose it was a not so old answer for the problems Pavel described. A quote from http://linux.die.net/man/3/dlopen > Place the lookup scope of the symbols in this library ahead of the global > scope. This means that a self-contained library will use its own symbols in > preference to global symbols with the same name contained in libraries that > have already been loaded. This flag is not specified in POSIX.1-2001. > In my case it helped, two instances (one dynamically linked, other loaded) started to act as independent entities without faults But what about the last comment (about POSIX.1-2001). Does it mean some distros could not support it? Max _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
