RE: libtool problem on FreeBSD 4.1 with -pthread

[Peter Ekberg]

Noah Misch wrote:
> 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:
>> 
>> - On AIX, users will still have to set their compiler.
> 
> Agreed.
> 
>> - 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.
> 
>> - 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).
> -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.

It seems to do the right thing for the libgii/libggi/etc family of
libraries (on FreeBSD 4.10, and it doesn't break anything to our
knowledge) so that is at least some increase :-)

> 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.

It is easy to add -pthread to the stuff inside the build of libgii, but
in order to do it in libggi (which depends on libgii) the exact same
checks has to made there (which means code duplication) and even if
the same checks are done you still don't cover the case when the user
overrides the behaviour of the thread detection checks in libgii and/or
libggi and/or any of the other libraries in the ggi family (there are
several more). The patch solves this problem for us. There are
certainly other ways to do it though, not as elegant IMO, but I'm not
very familiar with libtool internals so I can't really judge neither
the "beauty" nor the portability of the patch.

Cheers,
Peter