This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Failure to dlopen libgomp due to static TLS data
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: libc-alpha at sourceware dot org, gcc at gcc dot gnu dot org, rth at redhat dot com
- Date: Thu, 12 Feb 2015 16:26:09 +0100
- Subject: Re: Failure to dlopen libgomp due to static TLS data
- Authentication-results: sourceware.org; auth=none
- References: <201502121519 dot t1CFJMAe018776 at d03av02 dot boulder dot ibm dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Feb 12, 2015 at 04:18:57PM +0100, Ulrich Weigand wrote:
> we're running into a problem related to use of initial-exec access to
> TLS variables in dynamically-loaded libraries. Now, in general, this
> is actually not supported. However, there seems to an "inofficial"
> extension that allows selected system libraries to use small amounts
> of static TLS space to allow critical variables to be defined to use
> the initial-exec model even in dynamically-loaded libraries.
You can always LD_PRELOAD libgomp or link the main app with it if you need
it. Otherwise, sure, there is no guarantee it will work, but usually it
does, and the performance difference is significant enough to make it
worthwhile. Making libgomp -Wl,-z,nodlopen would just make it problem for
everyone, even when it works fine for most people.
And, the restriction you are mentioning is there only if
!RTLD_SINGLE_THREAD_P, so you can also avoid it by dlopening libgomp before
you spawn first threads rather than after that.
Jakub