Re: Building shared libraries at configuration time

[Ralf Wildenhues]

Hi Bob,

* Bob Friesenhahn wrote on Tue, Jun 01, 2010 at 04:48:48PM CEST:
[ __thread ]
> 
> You will likely find that 'valgrind' is not particularly friendly or
> helpful to diagnose memory problems in applications using this
> extension.

Is that still the case with valgrind 3.5?  Its testsuite contains tests
for __thread.  You might want to report a bug with a testcase that is
not supported well.

Cheers,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Building shared libraries at configuration time

[Ludovic Courtès]

Hi Bob,

Bob Friesenhahn  writes:

> On Tue, 1 Jun 2010, Ludovic Courtès wrote:
>>> On Tue, 1 Jun 2010, Ludovic Courtès wrote:
>>>
 Hello,

 GNU Guile relies on TLS (thread-local storage) support where available,
 and can live without it on inferior systems.  However, I haven’t found a
 reliable way to check whether TLS is supported.
>>>
>>> Why aren't you using the POSIX TLS APIs?
>>
>> Because using __thread allows you to choose a more efficient TLS model
>> without changing your code (see
>> ), and because it requires
>> less initialization-related code.
>
> I can see why this ELF-based TLS extension is attractive (especially
> when updating old code) but it seems wrong for portable software like
> guile to be using it and therefore penalizing standard environments
> which don't support it.  It seems best reserved for OS-specific
> libraries which have no need to be portable.

As I said, Guile has a fallback method for when TLS is not available.
The maintenance cost of having both methods with an #ifdef is actually
low in the case of Guile because there’s currently only one thread-local
variable.  The performance benefit can be noticeable (depending on the
TLS model) because it’s accessed quite often.

Besides, I feel that GNU software should be portable, as it’s always
been, but it should also take advantage of GNU extensions when doing so
doesn’t hinder portability and is beneficial on the GNU system.  It’s
actually the spirit of the GCS (info "(standards) System Portability")
and that of Gnulib, AIUI.

Thanks,
Ludo’.

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Building shared libraries at configuration time

[Bob Friesenhahn]

On Tue, 1 Jun 2010, Ludovic Courtès wrote:

On Tue, 1 Jun 2010, Ludovic Courtès wrote:


Hello,

GNU Guile relies on TLS (thread-local storage) support where available,
and can live without it on inferior systems.  However, I haven’t found a
reliable way to check whether TLS is supported.


Why aren't you using the POSIX TLS APIs?


Because using __thread allows you to choose a more efficient TLS model
without changing your code (see
), and because it requires
less initialization-related code.


I can see why this ELF-based TLS extension is attractive (especially 
when updating old code) but it seems wrong for portable software like 
guile to be using it and therefore penalizing standard environments 
which don't support it.  It seems best reserved for OS-specific 
libraries which have no need to be portable.


Operating systems and compilers not supporting this non-standard 
extension are not 'inferior' because it is a non-standard extension. 
If they fail to implement a standard interface then they can be called 
'inferior'.


You will likely find that 'valgrind' is not particularly friendly or 
helpful to diagnose memory problems in applications using this 
extension.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Building shared libraries at configuration time

[Ludovic Courtès]

Hi Ralf,

Ralf Wildenhues  writes:

> * Ludovic Courtès wrote on Tue, Jun 01, 2010 at 01:15:32AM CEST:
>> So it seems that the right test, when compiling natively, involves
>> building a shared library and an executable linked against it, and
>> running that executable.  That’s where you come in.  ;-)
>> 
>> How can libtool’s knowledge of compilers and linkers be leveraged from
>> ‘configure’ to write such a test?
>
> Use LT_OUTPUT after the other libtool macros in configure.ac, at which
> point you have a ./libtool script you can use in further hand-written
> configure tests.  In case you still need this.

OK, thanks for the hint!

Ludo’.

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Building shared libraries at configuration time

[Ludovic Courtès]

Hi Bob,

Bob Friesenhahn  writes:

> On Tue, 1 Jun 2010, Ludovic Courtès wrote:
>
>> Hello,
>>
>> GNU Guile relies on TLS (thread-local storage) support where available,
>> and can live without it on inferior systems.  However, I haven’t found a
>> reliable way to check whether TLS is supported.
>
> Why aren't you using the POSIX TLS APIs?

Because using __thread allows you to choose a more efficient TLS model
without changing your code (see
), and because it requires
less initialization-related code.

Thanks,
Ludo’.

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Building shared libraries at configuration time

[Ralf Wildenhues]

Hello Ludovic,

Bob has already addressed the rest of this I think, so:

* Ludovic Courtès wrote on Tue, Jun 01, 2010 at 01:15:32AM CEST:
> So it seems that the right test, when compiling natively, involves
> building a shared library and an executable linked against it, and
> running that executable.  That’s where you come in.  ;-)
> 
> How can libtool’s knowledge of compilers and linkers be leveraged from
> ‘configure’ to write such a test?

Use LT_OUTPUT after the other libtool macros in configure.ac, at which
point you have a ./libtool script you can use in further hand-written
configure tests.  In case you still need this.

Cheers,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Building shared libraries at configuration time

[Bob Friesenhahn]

On Tue, 1 Jun 2010, Ludovic Courtès wrote:


Hello,

GNU Guile relies on TLS (thread-local storage) support where available,
and can live without it on inferior systems.  However, I haven’t found a
reliable way to check whether TLS is supported.


Why aren't you using the POSIX TLS APIs?  That is what my software 
uses and I have not encountered any difficulties across a broad span 
of platforms.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___
http://lists.gnu.org/mailman/listinfo/libtool