This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Avoid use of libgcc_s and libgcc_eh when building glibc
On Tue, Aug 14, 2012 at 10:29 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Sat, Aug 11, 2012 at 10:43 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> On Monday 28 May 2012 17:43:04 Joseph S. Myers wrote:
>>> I've tested this patch for x86_64 and also done a test build for ARM.
>>> To go in it will certainly need more architecture testing (libc
>>> architectures and IA64) - but since it seems likely that review will
>>> point out changes that should be made, perhaps we could sort out any
>>> such changes first so the architecture maintainers are testing a patch
>>> that could, subject to such testing, go in?
>>
>> i tested glibc-2.16 with the patch merged into latest git (and tweaking it a
>> little to apply). after disabling the long standing -lgcc_eh hack in our
>> build system, i was able to bootstrap an ia64 cross-compiler fine: binutils,
>> kernel/glibc headers, gcc stage1 (static C-only), full glibc, gcc stage2 (full
>> C/C++/etc...).
>> -mike
>
> I am getting this error below. I see that libunwind.o is included in
> libgcc.a when building gcc-static
>
reason I think is csu/libc-start.o is compiled with -fexceptions which
generated undefined ref to __aeabi_unwind_cpp_pr0
which is then resolved from unwind-arm.o in libgcc.a and unwind-arm.o
needs libunwind.o to resolve bunch of its symbols
and that pulls libunwind.o from libgcc and causes the duplicate provider