[LLVMdev] Fwd: [windows) how to use weak references with llvm 3.4 and windows?

Carl name.is.carl at gmail.com
Wed Feb 12 02:31:54 PST 2014


So instead of using linkagetypes.weak I should use externalweaklinkage ?
Le 11 févr. 2014 18:29, "Reid Kleckner" <rnk at google.com> a écrit :

> You'd have to use extern_weak linkage.  Clang compiles the foo declaration
> to:
> $ clang -cc1 -emit-llvm -o - t.c | grep declare.*@foo
> declare extern_weak i32 @foo(...) #1
>
>
>
> On Tue, Feb 11, 2014 at 4:16 AM, Carl <name.is.carl at gmail.com> wrote:
>
>> Thanks for your clear answer. Do you know what modifier should I use to
>> declare such weak symbols in my llvm intermediate code?
>>
>> So that it can be compiled to the .o file with the weak attribute ?
>> Le 10 févr. 2014 19:44, "Reid Kleckner" <rnk at google.com> a écrit :
>>
>> COFF doesn't support the same kind of concept of 'weak' that ELF does.
>>>  This is the issue that users brought up with mingw:
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=9687
>>>
>>> Instead, COFF supports weak externals, which you can use like:
>>>
>>> $ cat t.c
>>> int foo() __attribute__((weak));
>>> int main() {
>>>   if (foo)
>>>     return foo();
>>>   return 13;
>>> }
>>>
>>> $ cat t2.c
>>> int foo() {
>>>   return 42;
>>> }
>>>
>>> $ clang t.c t2.c -o t && ./t ; echo $?
>>> 42
>>>
>>> So, we got the definition of foo from t2.c.  If t2.c hadn't been linked,
>>> foo would be null.
>>>
>>>
>>> On Mon, Feb 10, 2014 at 6:28 AM, Carl <name.is.carl at gmail.com> wrote:
>>>
>>>>
>>>> Hello,
>>>>
>>>> I'm generating C code (and the resulting obj files) using llvm 3.4 for
>>>> both unix and windows.
>>>> And I use the dreaded weak references, that, for windows, are not too
>>>> widely supported.
>>>>
>>>> When I link my application on linux, I have no issue.
>>>> But when I'm doing the same on windows using mingw I got a duplicate
>>>> symbol error :
>>>>
>>>> ..\robovm-0.0.8\lib\robovm-rt.jar\dalvik\system\BlockGuard$BlockGuardPolicyException.class.o:(.text$dalvik_system_BlockGuard$24BlockGuardPolicyException_getPolicy__I_lookup[_dalvik_system_BlockGuard$24BlockGuardPolicyException_getPolicy__I_lookup]+0x0):
>>>> multiple definition of
>>>> `dalvik_system_BlockGuard$24BlockGuardPolicyException_getPolicy__I_lookup'
>>>> ..\Temp\robovm3774596063679264132.tmp\linker.o:(.text+0x340): first
>>>> defined here
>>>> ..\robovm-0.0.8\lib\robovm-rt.jar\dalvik\system\BlockGuard$BlockGuardPolicyException.class.o:(.text$dalvik_system_BlockGuard$24BlockGuardPolicyException_getPolicyViolation__I_lookup[_dalvik_system_BlockGuard$24BlockGuardPolicyException_getPolicyViolation__I_lookup]+0x0):
>>>> multiple definition of
>>>> `dalvik_system_BlockGuard$24BlockGuardPolicyException_getPolicyViolation__I_lookup'
>>>> ..\Temp\robovm3774596063679264132.tmp\linker.o:(.text+0x350): first
>>>> defined here
>>>> ..\robovm-0.0.8\lib\robovm-rt.jar\dalvik\system\BlockGuard$BlockGuardPolicyException.class.o:(.text$dalvik_system_BlockGuard$24BlockGuardPolicyException_getMessage__Ljava_lang_String$3B_lookup[_dalvik_system_BlockGuard$24BlockGuardPolicyException_getMessage__Ljava_lang_String$3B_lookup]+0x0):
>>>> multiple definition of
>>>> `dalvik_system_BlockGuard$24BlockGuardPolicyException_getMessage__Ljava_lang_String$3B_lookup'
>>>>
>>>> Because those symbols are declared as weak.
>>>>
>>>> What is the status about the support of weak symbols on windows?
>>>> Are they supposed to work? Are they supposed to *never *work ?
>>>>
>>>> Do you know any way to fix this (or work around it). I use weak symbols
>>>> everywhere in my code generation, so I would prefer a fix that doesn't
>>>> involve to rewrite my code.
>>>>
>>>> I'm considering rewriting the obj files using objcopy.
>>>> Has this any chance to work ?
>>>> Here are the o.
>>>>
>>>> Cheers,
>>>> Carl.
>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140212/bc426218/attachment.html>


More information about the llvm-dev mailing list