[OE-core] [PATCH] eglibc: include libgcc when libpthread is enabled

[Phil Blundell]

On Thu, 2013-05-09 at 16:28 +0300, Marinescu, Bogdan A wrote:

> It's not exactly unconditional, it is conditioned by 'nptl' in
> ${GLIBC_ADDONS}. 


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.

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


> I don't know of a better way to handle this, please let me know if you
> have any suggestions.

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.  

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.

p.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130509/1a9f20c3/attachment-0001.html>