[5/6] temporary hack to fix linking error

See here for more info:
https://sourceware.org/ml/libc-help/2014-04/msg00020.html

Still working on the issue.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
---
 package/glibc/2.18/microblaze-libgcc_eh.patch |   18 ++++++++++++++++++
 package/glibc/2.19/microblaze-libgcc_eh.patch |   18 ++++++++++++++++++
 2 files changed, 36 insertions(+)
 create mode 100644 package/glibc/2.18/microblaze-libgcc_eh.patch
 create mode 100644 package/glibc/2.19/microblaze-libgcc_eh.patch

On 04/13/2014 06:47 AM, Waldemar Brodkorb wrote:

> See here for more info:
> https://sourceware.org/ml/libc-help/2014-04/msg00020.html
> 
> Still working on the issue.

This patch works, but by it being temporary/hacky it should be
conditionally applied just for microblaze since you probably have no
idea how it can affect other architectures.

By the way, how is it that we're not interested in fixing things or
something like that?
(https://sourceware.org/ml/libc-help/2014-04/msg00027.html)
I'm using my (volunteer/spare) time looking at your patchset and testing
it, so i think that's not a fair assessment, and disabling eglibc
because "no time to test" and saying that at the same time sounds pretty
much like double-standards.
I'm not saying this to get you angry or anything like that, it's just
that you're stating it in a very public mailing list and it seems
utterly unfair to many BR contributors. Many people do what they can
when they can.

Now with that out of the way, care to respin this patch with the
consideration i mentioned above?
Regards.

Hi Gustavo,
Gustavo Zacarias wrote,

> On 04/13/2014 06:47 AM, Waldemar Brodkorb wrote:
> 
> > See here for more info:
> > https://sourceware.org/ml/libc-help/2014-04/msg00020.html
> > 
> > Still working on the issue.
> 
> This patch works, but by it being temporary/hacky it should be
> conditionally applied just for microblaze since you probably have no
> idea how it can affect other architectures.
> 
> By the way, how is it that we're not interested in fixing things or
> something like that?
> (https://sourceware.org/ml/libc-help/2014-04/msg00027.html)
> I'm using my (volunteer/spare) time looking at your patchset and testing
> it, so i think that's not a fair assessment, and disabling eglibc
> because "no time to test" and saying that at the same time sounds pretty
> much like double-standards.
> I'm not saying this to get you angry or anything like that, it's just
> that you're stating it in a very public mailing list and it seems
> utterly unfair to many BR contributors. Many people do what they can
> when they can.

Okay, sorry. I thought that there is no interest in my patches,
because I got no feedback at all. Looking at the traffic on the
mailinglist nearly every patch set gets some feedback after 2-3
days. My bug report about the microblaze OOM got no feedback, too. 
I stop whining now, and start hacking.
 
> Now with that out of the way, care to respin this patch with the
> consideration i mentioned above?

I will respin the patches after your gcc 4.9 patch set gets
committed. I tested with gcc 4.9 and the workaround for glibc/eglibc
is not required anymore.

best regards
        Waldemar

On 04/22/2014 02:49 PM, Waldemar Brodkorb wrote:
> Okay, sorry. I thought that there is no interest in my patches,
> because I got no feedback at all. Looking at the traffic on the
> mailinglist nearly every patch set gets some feedback after 2-3
> days. My bug report about the microblaze OOM got no feedback, too. 
> I stop whining now, and start hacking.

Hi.
Ok, cool, now we're talking! :)

> I will respin the patches after your gcc 4.9 patch set gets
> committed. I tested with gcc 4.9 and the workaround for glibc/eglibc
> is not required anymore.

Great.
Only the gcc patch would need a respin i think, the rest can be
committed as they are.
Thanks.
Regards.