<div dir="ltr"><div>Thanks! I created a bug report, as it is clear now, that is not SBCL fault.<br><a href="https://bugs.dragonflybsd.org/issues/2663">https://bugs.dragonflybsd.org/issues/2663</a><br><br></div>I also found that any library, which mmap's some space at fixed range in its constructor will fail the test. I attached such a library which mimics the behaviour of libthread_xu.so<br>
<div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-16 5:31 GMT+04:00 Matthew Dillon <span dir="ltr"><<a href="mailto:dillon@apollo.backplane.com" target="_blank">dillon@apollo.backplane.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Ah ha! I found it. Testing with dynamically loading a library which<br>
depends on libpthread triggers the problem when libpthread is not<br>
built into the main program.<br>
<br>
For example, if I test with libusb.so.2 with a program compiled without<br>
-pthread, it triggers the problem. If I test with libusb.so.2 with<br>
a program compiled with -pthread, it does not trigger the problem.<br>
<br>
So the issue here is that libpthread is not built into the main<br>
program and it needs to be, simple as that. If the main program is<br>
compiled/linked with -pthread, the problem should go away.<br>
<br>
--<br>
<br>
In terms of making this work as-is with some sort of fix to rtld-elf...<br>
that's problematic. A lot of these shared libraries are not designed<br>
to be unloaded. It would take some time to vet them all.<br>
<br>
For now I think the best solution is to adjust the port to compile/link<br>
SBCL with -pthread.<br>
<br>
-Matt<br>
</blockquote></div><br></div></div>