<br><br><div class="gmail_quote">2011/6/10  <span dir="ltr"><<a href="mailto:michael.vancanneyt@wisa.be">michael.vancanneyt@wisa.be</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im"><br>
<br>
On Fri, 10 Jun 2011, Maxim Ganetsky wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
09.06.2011 13:17, Max Vlasov пишет:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Finally found that this was because sqlite3 was in the uses list, so<br>
actually it was scenario when fpc linked sqlite dynamically and besides<br>
I did my own dynamic loading with my own unit of another version/file of<br>
sqlite. So probably there was a conflict with shared data. In my case it<br>
looks like everything was ok if the linked library and loaded was the<br>
same file (system libsqlite3.so). But if linked was system libsqlite3.so<br>
and my loaded was a library with a different name/soname the faults took<br>
place.<br>
<br>
Just curious, such things occasionally can happen from time to time. Is<br>
this about the way sqlite library is compiled so no two independent<br>
copies of the library coexist dynamically linked/loaded due to<br>
intersetion of the shared data. Or this is about the way linux handles<br>
them?<br>
</blockquote>
<br>
It is best to ask this question in FPC devel mailing list, this behavior may be a bug.<br>
</blockquote>
<br></div>
It is not a FPC bug; you're not supposed to use the 2 units at the same time.<br>
There is no way the compiler can detect this. At best the linux linker<br>
should detect it.<br>
<br></blockquote></div><br>Michael, <br>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.<br>

<br>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<br>

<br>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. <br>

<br>Quote from <a href="http://linux.die.net/man/3/dlopen">http://linux.die.net/man/3/dlopen</a><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">

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.<br></blockquote><br>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?<br><br>Max<br>