Re: KITTEN BOF at IETF 60?

Ken Raeburn <[email protected]> Tue, 23 Mar 2004 16:38:15 -0500
Newsgroups gmane.ietf.cat
Message-ID <[email protected]>
(Sorry, this is drifting a bit off topic...)

On Tuesday, Mar 23, 2004, at 15:36 US/Eastern, Love wrote:
> Ken Raeburn <[email protected]> writes:
>> Huh.  I'd gotten the impression that code compiled for a multithreaded
>> environment, but not doing thread stuff itself, was generally safe to
>> use in a single-threaded executable (with code compiled for
>> single-threaded execution).
>
> It depends how the shared object is linked. A threads shared 
> object/module
> must be loaded by a program that used pthread. Its not a requirement 
> that
> that libc (malloc/free/syslog etc) can handle any other situation.

But if you don't make the library depend on libpthread, as you did in 
your example, would it tend to "just work" on most of these systems?  
(Obviously there's a problem if there is no weak reference support, and 
no stub versions of the mutex functions in libc, and the code actually 
tries to lock a mutex or whatever.)

> $ gcc -shared -o o.o o.c -pthread

This creates a shared library that references libpthread.  That would 
definitely be bad to load into a single-threaded program.  If I compile 
o.c with "-c -pthread", and then build a shared object ("-shared" but 
not "-pthread"), I get something that runs successfully (sparc64 
netbsd-current).

Ken

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]