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