[cfe-dev] Loading Static Analyzer plugin fails with CommandLine Errors

[Jordan Rose]

These are link arguments when compiling your plugin, and like Laszlo said you should use them instead of linking to the Clang libraries, since they'll be found by the dynamic linker at runtime.

I'd guess that in 32 bits things get linked differently and either don't overlap or can't easily be reported...or perhaps just aren't reported for historical reasons.

Jordan


On Sep 4, 2013, at 2:11 , Gábor Kozár <kozargabor at gmail.com> wrote:

> Thanks Jordan. My issue is that this error is reported when I try running clang. So where do I specify these args? When compiling Clang, or when compiling my plugin...?
>  
> Also, it doesn't really explain why everything works fine on the 32-bit system.
>  
> -- 
> Gábor Kozár -- ShdNx
> kozargabor at gmail.com
>  
>  
>  
> On Tue, Sep 3, 2013, at 18:08, Jordan Rose wrote:
>> Right. On a Mac there's a heavy-handed way to do this ("-undefined dyamic_lookup") and a lighter way ("-bundle_loader path/to/clang"). According to  the flag on Linux might be --allow-shlib-undefined or --unresolved-symbols=ignore-in-object-files; I don't know if there's an equivalent to -bundle_loader.
>>  
>> Jordan
>>  
>>  
>> On Sep 3, 2013, at 8:50 , Gábor Kozár <kozargabor at gmail.com> wrote:
>>  
>>> Thanks Laszlo, you make good points, I'll investigate.
>>>  
>>> -- 
>>> Gábor Kozár
>>> kozargabor at gmail.com
>>>  
>>>  
>>>  
>>> On Tue, Sep 3, 2013, at 16:52, Laszlo Nagy wrote:
>>>> Hi Gabor,
>>>>  
>>>> #1 you should not link any Clang
>>>> library against when you make your plugin
>>>>  
>>>> How do I not link against any Clang library when I'm writing a Clang plugin?
>>>> I need to use Clang's classes extensively.
>>>>  
>>>> Sound weird, but works just fine. Your plugin will be loaded by the
>>>> Clang binary, and it already loaded the needed symbols. That's why you
>>>> don't need to explicitly link against them... You can look at
>>>> https://github.com/rizsotto/Constantine for cmake example.
>>>>  
>>>> In the meanwhile, I realize that I have done it all with the assumption that
>>>> GCC 4.7.2 and Clang 3.3 generate compatible binaries. Could this be the
>>>> source of the issue? I'll try self-hosting Clang 3.3 and see what happens
>>>> then.
>>>>  
>>>> I do compile my plugin with GCC and Clang is able to load it without
>>>> problem.
>>>>  
>>>> My two cents are still on the llvm::cl classes. Although you are not
>>>> using them, but the libraries that you are link against might. (That's
>>>> why I was suggest not to do that.) And not to mention the fact, that
>>>> the messages are emitted by the CommandLine.cpp:144. See also:
>>>>  
>>>>   http://comments.gmane.org/gmane.comp.compilers.clang.devel/6870
>>>>   http://comments.gmane.org/gmane.comp.compilers.clang.scm/63478
>>>>  
>>>> Regards,
>>>> Laszlo
>>> 
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> 
>>  
>>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130904/42fb0b52/attachment.html>