2014-04-16 10:45 GMT+04:00 John Marino <[email protected]>: > On 4/16/2014 04:59, Vasily Postnicov wrote: > > Thanks! I created a bug report, as it is clear now, that is not SBCL > fault. > > https://bugs.dragonflybsd.org/issues/2663 > > Hmmm, how did you conclude that "it's not SBCL's fault"? > "So the issue here is that libpthread is not built into the main > program and it needs to be, simple as that. If the main program is > compiled/linked with -pthread, the problem should go away." > > Thus SBCL is not being built correctly. It's an SBCL problem. > It needs an LDFLAG of -pthread when it's built. > > > > 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 > > Again, "A lot of these shared libraries are not designed to be > unloaded". So isn't failing the test expected and not an issue? > > John > > > > > > > > 2014-04-16 5:31 GMT+04:00 Matthew Dillon <[email protected] > > <mailto:[email protected]>>: > > > > Ah ha! I found it. Testing with dynamically loading a library > > which > > depends on libpthread triggers the problem when libpthread is not > > built into the main program. > > > > For example, if I test with libusb.so.2 with a program compiled > > without > > -pthread, it triggers the problem. If I test with libusb.so.2 > with > > a program compiled with -pthread, it does not trigger the > problem. > > > > So the issue here is that libpthread is not built into the main > > program and it needs to be, simple as that. If the main program > is > > compiled/linked with -pthread, the problem should go away. > > > > -- > > > > In terms of making this work as-is with some sort of fix to > > rtld-elf... > > that's problematic. A lot of these shared libraries are not > > designed > > to be unloaded. It would take some time to vet them all. > > > > For now I think the best solution is to adjust the port to > > compile/link > > SBCL with -pthread. > > > > -Matt > > > > >
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? 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.
