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

Wed Sep 11 11:30:06 PDT 2013

So I got the following error when attempting to load the plugin that
was compiled without linking against any clang or LLVM libs:

error: unable to load plugin 'myPlugin.so': 'myPlugin.so: undefined
symbol:

      _ZTVN5clang12ast_matchers11MatchFinder13MatchCallbackE'

But then I realized that libASTMatchers is not loaded by Clang when
doing --analyze (since it is not used by the Static Analyzer), so I
have to link against it in the plugin. Doing so and using
--allow-shlib-undefined when compiling the plugin works on both the
32-bit and 64-bit machines.

Thank you all very much for your help!

--
Gábor Kozár -- ShdNx
kozargabor at gmail.com

On Thu, Sep 5, 2013, at 2:19, Jordan Rose wrote:

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 <[1]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
[2]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-fil
es; I don't know if there's an equivalent to -bundle_loader.

Jordan

On Sep 3, 2013, at 8:50 , Gábor Kozár <[3]kozargabor at gmail.com> wrote:

Thanks Laszlo, you make good points, I'll investigate.

--
Gábor Kozár
[4]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

[5]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:

  [6]http://comments.gmane.org/gmane.comp.compilers.clang.devel/6870

  [7]http://comments.gmane.org/gmane.comp.compilers.clang.scm/63478

Regards,

Laszlo

_______________________________________________

cfe-dev mailing list

[8]cfe-dev at cs.uiuc.edu

[9]http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

References

1. mailto:kozargabor at gmail.com
2. mailto:kozargabor at gmail.com
3. mailto:kozargabor at gmail.com
4. mailto:kozargabor at gmail.com
5. https://github.com/rizsotto/Constantine
6. http://comments.gmane.org/gmane.comp.compilers.clang.devel/6870
7. http://comments.gmane.org/gmane.comp.compilers.clang.scm/63478
8. mailto:cfe-dev at cs.uiuc.edu
9. 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/20130911/0868c829/attachment.html>