On Fri, 10 Jun 2011, Max Vlasov wrote:
2011/6/10 <[email protected]>
On Fri, 10 Jun 2011, Maxim Ganetsky wrote:
09.06.2011 13:17, Max Vlasov пишет:
Finally found that this was because sqlite3 was in the uses list, so
actually it was scenario when fpc linked sqlite dynamically and besides
I did my own dynamic loading with my own unit of another version/file of
sqlite. So probably there was a conflict with shared data. In my case it
looks like everything was ok if the linked library and loaded was the
same file (system libsqlite3.so). But if linked was system libsqlite3.so
and my loaded was a library with a different name/soname the faults took
place.
Just curious, such things occasionally can happen from time to time. Is
this about the way sqlite library is compiled so no two independent
copies of the library coexist dynamically linked/loaded due to
intersetion of the shared data. Or this is about the way linux handles
them?
It is best to ask this question in FPC devel mailing list, this behavior
may be a bug.
It is not a FPC bug; you're not supposed to use the 2 units at the same
time.
There is no way the compiler can detect this. At best the linux linker
should detect it.
Michael,
actually what appeared was that two libraries with different filenames and
different soname (although compiled from the same sources, one dynamically
linked and another dynamically loaded) shared some global data during
run-time. I thought that in this case they should look virtually different
for the linux loader to separate everything, but actually they were not.
What interesting is that a solution was found. It's a flag RTLD_DEEPBIND for
dlopen, I discovered it by chance, wrongly assuming RTLD_LOCAL as having $8
(netware libc) while RTLD_LOCAL=0 in linux. In Linux RTLD_DEEPBIND = $8
RTLD_DEEPBIND is not present in any of lazarus/fpc sources, but after I
added it to my dlopen call, dynamically loaded library started to work when
there was still a dynamically linked sqlite. So they became independent from
each other.
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.
Yes, I can see how this can help.
I'm not sure this will be helpful for everyone, but maybe it is worth to add
this constant to rtl\unix\dl.pp file?
It depends. Does it also exist in FreeBSD and Mac OS ?
If not, then I think this is not such a good idea.
Michael.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
