[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: static real time



On Fri, 2007-09-07 at 21:21 +0000, Mike -- EMAIL IGNORED wrote:
> I have a simple test program using threads, etc. that
> compiles, links, and runs correctly, BUT if I try to
> link with -static, it get various undefined variables
> related to condition variables and mutexes.
> 
> Why is this?  Is there something I can do about it?
> 
> BTW, I do have /usr/lib/librt.a
> 
> Thanks for your help.
> 
> Mike.
> 
Hi, Mike,
	I didn't see an answer to your question, so I'll give it a try...
Static means that the libraries as well as the code is statically
linked.  This would cause the libraries to remain in memory and you
could step through them.  But lots of libraries and drivers are not
re-entrant, a requirement for threading.  Thus when you statically link,
step into one of those bits of code, your system would stop.  
	I suspect your question about the other variables are something to do
with statically linking these non-re-entrant libraries, but I cannot
confirm that.  I haven't used static linking for a long time.  Generally
it is only useful when debugging some errant link between your code and
a relevant library, but some debuggers won't work without static links.
If yours is the latter case, it may be time to look to another debugger.
If the former case, you may have to do some discussion with the relevant
library source code outside the debugger to see if perhaps the
non-re-entrant bits are the original problem, and in that case, a
bugzilla of the relevant library might be in order.  But you should
realize that some libraries are never going to be re-entrant, either due
to the resources they address, or due to the nature of the processing
they handle.

	Of course I could be wrong.

Regards,
Les H


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]