<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.4.4">
</HEAD>
<BODY>
On Thu, 2013-05-09 at 16:28 +0300, Marinescu, Bogdan A wrote:
<BR>
<BLOCKQUOTE TYPE=CITE>
It's not exactly unconditional, it is conditioned by 'nptl' in ${GLIBC_ADDONS}. <BR>
</BLOCKQUOTE>
<BR>
Well, true, but nptl is more or less mandatory nowadays. That conditional is an artifact from the days when linuxthreads was the default and you had to enable nptl explicitly if you were lucky enough to be using an architecture where it was supported. I'm not sure if linuxthreads even still works and I doubt anybody is building eglibc without nptl any more.<BR>
<BR>
In fact, the whole GLIBC_ADDONS variable appears to be vestigial and, as far as I can tell, no longer does anything useful. EXTRA_OECONF in eglibc.bb is hard-coded to pass just "--enable-add-ons" which causes eglibc to enable all the add-ons it can find (and even this is unnecessary since that is the default behaviour anyway). <BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
I don't know of a better way to handle this, please let me know if you have any suggestions.
</BLOCKQUOTE>
<BR>
There was some previous discussion of how to detect the precise situation that caused libgcc_s to be required, though my recollection of all the details is a bit hazy. I'll see if I can find it in the archives. <BR>
<BR>
In the meantime, it's maybe worth noting that the whole way that eglibc is packaged is basically unchanged from the way that it was first done back in 2003 and, to put it bluntly, is teh suck. (Notably, eglibc.inc mentions LEAD_SONAME, which is usually quite a clear sign that suckage can be found nearby.) If libpthread were packaged separately rather than bundled up into eglibc, the dependency could go there and this would probably solve 95% of the problem.<BR>
<BR>
p.<BR>
<BR>
<BR>
</BODY>
</HTML>