libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] test-static-link broken on ARM


From: Zach Welch
Subject: Re: [Libunwind-devel] test-static-link broken on ARM
Date: Thu, 28 Oct 2010 22:54:40 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101026 Lightning/1.0b3pre Thunderbird/3.1.5

On 10/28/2010 09:44 PM, Arun Sharma wrote:
> On Thu, Oct 28, 2010 at 7:08 PM, Zach Welch <address@hidden> wrote:
>>
>> /home/zwelch/libunwind/src/.libs/libunwind.a(Lglobal.o):(.data+0x4):
>> multiple definition of `_UIarm_unwind_method'
>> ../src/.libs/libunwind-arm.a(Gglobal.o):(.data+0x4): first defined here
>> collect2: ld returned 1 exit status
> 
> I think this is coming from:
> 
> include/tdep-arm/libunwind_i.h:
> 
> #define unwi_unwind_method   UNWI_ARCH_OBJ(unwind_method)
> extern int unwi_unwind_method;
> 
> src/arm/Gglobal.c:
> 
> /* Unwinding methods to use. See UNW_METHOD_ enums */
> HIDDEN int unwi_unwind_method = UNW_ARM_METHOD_ALL;
> 
> I think the "extern int" declaration above is problematic (drops the
> HIDDEN attribute).

Right, I'd gotten this far on my own. Trying to fix it by adding HIDDEN
to the extern declaration results in a similar but slightly different error:

.../libunwind/src/.libs/libunwind.a(Lglobal.o): In function `.LANCHOR1':
Lglobal.c:(.data+0x4): multiple definition of `_UIarm_unwind_method'
../src/.libs/libunwind-arm.a(Gglobal.o):Gglobal.c:(.data+0x4): first
defined here

Remove the HIDDEN from the definition also fails to solve the problem,
as that change produces this same error permutation.

Still, that doesn't seem like it should be necessary, as there are
numerous other plain "extern int" declarations that reference HIDDEN
variables without problems (e.g. tdep_needs_initialization, which
appears in the very same header and source files). These do not produce
similar errors, which I would expect to see if that was the root cause.

>From my perspective, there seems to be something bizarre happening to
this particular variable. I can't quite see what it is, but I have begun
to suspect that my toolchain may be slightly wonky. Any other
explanations? Honestly, I'd love to hear that it works for someone else
on ARM, as that would help to confirm my current hypothesis.

-- 
Zach Welch
CodeSourcery
address@hidden
(650) 331-3385 x743



reply via email to

[Prev in Thread] Current Thread [Next in Thread]