libtool
[Top][All Lists]
Advanced

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

Re: TODO


From: Jacob Meuser
Subject: Re: TODO
Date: Tue, 16 Nov 2004 13:02:18 -0800
User-agent: Mutt/1.4.2i

On Tue, Nov 16, 2004 at 09:10:00PM +0100, Ralf Wildenhues wrote:
> * Jacob Meuser wrote on Tue, Nov 16, 2004 at 08:00:28PM CET:
> > On Tue, Nov 16, 2004 at 03:01:06PM +0000, Scott James Remnant wrote:
> > > On Mon, 2004-11-15 at 10:51 -0800, Jacob Meuser wrote:
> > > 
> > > > On Mon, Nov 15, 2004 at 03:45:10PM +0000, Scott James Remnant wrote:
> > > > > It does assume that all library dependencies are registered, yes.  
> > > > > This
> > > > > has never been a problem, because we've never found any 
> > > > > Libtool-produced
> > > > > library that doesn't have all dependencies registered.
> > > > > 
> > > > > If this isn't the case, and at one time Libtool never registered all 
> > > > > of
> > > > > the dependencies, we should check for that.  Otherwise I don't see the
> > > > > need -- we can assume sanity from our own output.
> > > > 
> > > > for a long time, libtool did not handle -pthread properly.
> > > > 
> > > It still doesn't, the current situation is a botch that produces the
> > > right results but does it in the wrong way.  Libraries should record
> > > what compiler/linker flags they need (-pthread is not a dependency
> > > library).
> > 
> > record how?  in the dependency_libs section of an .la file?  you seem
> > to be saying no, so then where?
> 
> It's already in HEAD.  Stored in inherited_linker_flags.
> 
> > > > I can point to at least a few .la files on my system that do
> > > > not have -pthread or even other required libraries registered.
> > > > 
> > > I'd be quite shocked if the current version of Libtool produces
> > > libraries with -pthread in dependency_libs; I specifically wrote the
> > > patch to prevent that, because it causes a lot of problems.
> > 
> > if -pthread is needed but missing, then I get errors about missing 
> > symbols, much like if a library is missing from the link command.
> 
> Note that the patch in HEAD is not a complete solution to the problem.
> It's not portable/right in general to only compile a library thread-safe 
> and not the entire application, or even compile against different thread
> implementations (one library against one, the other against another).
> All this probably cannot be solved by libtool, but some possible
> problems can be warned about (this is not yet implemented).

thanks for the update. I suppose I should probably start looking
into the latest sources ...

> Regards,
> Ralf
> 

-- 
<address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]