<div dir="ltr"><div>> Why would you build
SBCL to only do single threaded applications?<br></div>Because multithreading is not easy in SBCL. Currently, I have no idea how to implement it. For all other platforms -lpthread is used only for multithreaded SBCL (see sbcl-source/src/runtime/Config.x86-64-freebsd for example).<br>
It is strange to supply -lpthread to single threaded app just to avoid some bugs, is it not? But I've already done it as a temporal (I hope!) solution.<br><div><br>> 
or did I misunderstand and the executable built by the SBCL compiler has to be linked with pthread and not the compiler itself?
<br></div><div>No. pthread is being loaded indirectly via rtld  when user (programmer) wants to load any library depending on it. In case of IOLib, SBCL loads(with dlopen) libfixposix which is linked against pthread.<br>
<br></div><div>Just to clear the situation: no, I do not want to save the linker from loading pthreads, and, yes, it would be nice to prevent libthread_xu from allocating the stack guard page for main thread twice.<br><br>
>  please provide all the patches you are
using (including this -pthread addition when you figure it out)<br></div><div>Sure. Build it with "sh make.sh --xc-host=clisp". Do not forget to run all tests: "cd tests && sh run-tests.sh". They must pass, but it will be better to doublecheck. I attach the patch as a single file, will that do?<br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-16 17:37 GMT+04:00 John Marino <span dir="ltr"><<a href="mailto:dragonflybsd@marino.st" target="_blank">dragonflybsd@marino.st</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 4/16/2014 15:17, Vasily Postnicov wrote:<br>
<br>
> I don't know. Anyway, why user should care? Imagine that I'm trying to<br>
> unload not pthread itself (which, of course, I must not do), but a<br>
> random library foo.so, which depends on pthreads indirectly. So why it<br>
> must break otherwise working application? Especially if it is not<br>
> multithreaded?<br>
<br>
</div>I don't get why this matters.  Your problem has been solved. Build the<br>
executable with -pthread and the issue goes away.  Why would you build<br>
SBCL to only do single threaded applications?  That doesn't make sense<br>
to me.  You build it with -pthread, then it can do both single and<br>
multithread.  Are you trying to save the dynamic linker from loading<br>
pthread library?<br>
<br>
or did I misunderstand and the executable built by the SBCL compiler has<br>
to be linked with pthread and not the compiler itself?<br>
<div class=""><br>
<br>
> And adding -lpthread to SBCL is not necessary if it is not<br>
> multithreaded. It's just a hack which prevents unloading of libthread_xu<br>
> by keeping its reference counter above zero.<br>
><br>
> So I am not telling that I found a bug, I am just asking is this<br>
> behaviour OK? I think it is not.<br>
<br>
</div>yes, why not?<br>
It's the first time any kind of issue has come it, and it's probably<br>
related to how SBCL was designed, so it seems pretty application<br>
specific, not a general problem.  At least to me, given only what I've<br>
skimmed on this list.<br>
<br>
If you want SBCL on DragonFly, please provide all the patches you are<br>
using (including this -pthread addition when you figure it out) or<br>
submit them to upstream and we'll eventually get them from ports.<br>
<br>
Thanks,<br>
John<br>
</blockquote></div><br></div>