Can anyone help to shed the light on mysterious bug in SBCL (found it!)

[John Marino]

On 4/16/2014 15:17, Vasily Postnicov wrote:

> I don't know. Anyway, why user should care? Imagine that I'm trying to
> unload not pthread itself (which, of course, I must not do), but a
> random library foo.so, which depends on pthreads indirectly. So why it
> must break otherwise working application? Especially if it is not
> multithreaded?

I don't get why this matters.  Your problem has been solved. Build the
executable with -pthread and the issue goes away.  Why would you build
SBCL to only do single threaded applications?  That doesn't make sense
to me.  You build it with -pthread, then it can do both single and
multithread.  Are you trying to save the dynamic linker from loading
pthread library?

or did I misunderstand and the executable built by the SBCL compiler has
to be linked with pthread and not the compiler itself?


> And adding -lpthread to SBCL is not necessary if it is not
> multithreaded. It's just a hack which prevents unloading of libthread_xu
> by keeping its reference counter above zero.
> 
> So I am not telling that I found a bug, I am just asking is this
> behaviour OK? I think it is not.

yes, why not?
It's the first time any kind of issue has come it, and it's probably
related to how SBCL was designed, so it seems pretty application
specific, not a general problem.  At least to me, given only what I've
skimmed on this list.

If you want SBCL on DragonFly, please provide all the patches you are
using (including this -pthread addition when you figure it out) or
submit them to upstream and we'll eventually get them from ports.

Thanks,
John