libtool-patches
[Top][All Lists]
Advanced

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

Re: libtool problem on FreeBSD 4.1 with -pthread


From: Ralf Wildenhues
Subject: Re: libtool problem on FreeBSD 4.1 with -pthread
Date: Mon, 8 Nov 2004 17:25:16 +0100
User-agent: Mutt/1.4.1i

* Noah Misch wrote on Mon, Nov 08, 2004 at 05:07:20PM CET:
> On Mon, Nov 08, 2004 at 10:55:19AM +0100, Ralf Wildenhues wrote:
> > * Peter Ekberg wrote on Sat, Nov 06, 2004 at 05:29:25PM CET:
> > > Peter O'Gorman wrote:
> > > > 
> > > > If you put it in the .la in $inherited_linker_flags then all should
> > > > be well (I think).
> 
> > I think we should take it, even if:
> 
> > - For different compilers on the same system, different flags might be
> > necessary.  Thus, if you compile the library with a different
> 
> This seems like an acceptable trade-off.

As mentioned, we might want to wrap those in portable flags we put
there.

> > - Other than the second point, this approach is orthogonal to finding
> > out the value of thread_safe_flag_spec.
> 
> > What do the others think?  I don't want to have the last word here.
> 
> A build system for a program that uses threads should compile _every_ _source_
> _file_ with platform-appropriate CPPFLAGS (e.g. -D_REENTRANT -D_THREAD_SAFE).

This is what the whole question boils down to.  Even if the main program
does not use threads (only a shared lib it uses), is it necessary for it
to be compiled with those flags (as opposed to only be linked with)?

Is the answer to this question portable or system-specific?

> -pthread takes care of this where it is available.  Given that, libtool does 
> not
> make a threads-naive build recipe appropriate for threaded operation by merely
> propagating -pthread in the final link line.  I do not think this patch
> increases the number of situations in which libtool will do the right thing.

What we could do now, however, is complain if a library uses threads and
the other program sources weren't compiled with the thread-safe flag.  Not
too brilliant, but better than nothing if at the end of your build it
says
| Sorry, you should have used thread-safe compilation in order to be 
| able to link against libduper.la.  Try again.

or
| Sorry, you are trying to link against a thread-safe-compiled library
| (libduper.la) and a non-thread-safe library (libboo.la).  This might
| not work.

> The ggi build process already supplies the requisite preprocessor flags.  As
> best I can tell, it just needs to also pass -pthread on link in demos/, just 
> as
> it does elsewhere.
> 
> I see that you have already committed the patch; sorry for the lateness.

I don't see this as set in stone just because it's committed.
A decision can be make the better the more information is available.

Regards,
Ralf




reply via email to

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