@mikde: "Hello!
I'm trying to improve the security/xmlsec1 port to support the
nss-backend (which vendor supports, but the port does not).
Nss (security/nss) use nspr (devel/nspr), which uses threads.
The xmlsec1 executable, built by the security/xmlsec1 port is not
multi-threaded by itself, but it is opening the specified xwhite@example.org.
Do I need to make the executable itself multi-threaded  just in case
it needs to dlopen() a thread-using library, or is there a better way?
Its other possible back-ends  OpenSSL and GNUTLS  do not use
threads.
Thanks!
	-mi"
    @jasone: "<quote>
As long as the dlopen()ed library is correctly linked, your app  
doesn't need to explicitly link against the library's dependencies.   
Dependencies should get pulled in after dlopen() as necessary, on the  
fly, as a result of the dlopen()ed library's dependencies.
There's nothing magical about a threaded app, as compared to a non- 
threaded app.  The first time a pthreads API is called, libpthread  
initializes itself.  It's fine if this happens as the result of  
executing dlopen()ed code; the only issue is making sure that the  
library dependencies are set up correctly.
Jason"
    @MikhailTeterin: "������ 06 ������� 2005 04:55, Jason Evans �� ��������:
<quote>
What is the correct way to link a shared object, that uses threads? Using 
`-pthread' does not seem to change the output of ldd and a non-threaded 
executable is unable to dlopen() such an object. And for good reason  the 
thread-implementation is decided at startup time, not at link-time, is not 
it?
So, what happens, when a main executable calls some libc function directly, 
oblivious to the pthread-wrapper around it, that the dlopen-ed library's code 
is using?
Thanks,
	-mi"
{'source': 'USENET', 'other_information': '{"reply_count": 2, "forum_name": "lucky.freebsd.threads.20140225.mbox"}', 'file': 'data/output/usenet-lucky.freebsd.parquet'}