Using Clang plugins with release version of clang on OS X

Hi,

I’m looking into writing my own Clang plugin which would do some analysis on ObjC code and write out results into an external file during the compilation step. I successfully followed the sample code given here http://clang.llvm.org/docs/ClangPlugins.html and got my plugin working with the trunk clang version which I built on my machine. However, I’m getting a dyld error when trying to load that plugin into default clang version which is shipped with OS X dev tools (Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn). The issue I’m seeing is described here: http://llvm.org/bugs/show_bug.cgi?id=13546

Are Clang plugins being limited to only manual clang builds, or am I missing something here? My goal is to distribute this plugin to other members of my team so they could use it as part of normal Xcode workflow.

Best regards,
Nikita Zhuk

Hi,

I’m looking into writing my own Clang plugin which would do some analysis on ObjC code and write out results into an external file during the compilation step. I successfully followed the sample code given here http://clang.llvm.org/docs/ClangPlugins.html and got my plugin working with the trunk clang version which I built on my machine. However, I’m getting a dyld error when trying to load that plugin into default clang version which is shipped with OS X dev tools (Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn). The issue I’m seeing is described here: http://llvm.org/bugs/show_bug.cgi?id=13546

Are Clang plugins being limited to only manual clang builds, or am I missing something here? My goal is to distribute this plugin to other members of my team so they could use it as part of normal Xcode workflow.

The resemblance of your issue to PR13546 is only incidental.

clang plugins will in fact only load and run properly in the exact same build configuration and source tree version (SVN revision+patches) of LLVM and clang. The compiler used to build either also needs to match, so that's unlikely to ever work.

A more effective approach may be to plug into the analyzer support in Xcode which I believe is binary pluggable, or to otherwise pipe diagnostics from your version of clang into the IDE where they can be rendered. In general loading into a foreign clang binary won't work.

Alp.

Thanks for this information, it would have saved me hours if I knew it earlier. Could this limitation be mentioned on the Clang Tooling page so that people know that plugins aren't suitable for use cases like mine?

I'll look into other options. Thanks again.

- Nikita Zhuk

Hello,

clang plugins will in fact only load and run properly in the exact same build configuration and source tree version (SVN revision+patches) of LLVM and clang. The compiler used to build either also needs to match, so that's unlikely to ever work.

Thanks for this information, it would have saved me hours if I knew it earlier. Could this limitation be mentioned on the Clang Tooling page so that people know that plugins aren't suitable for use cases like mine?

I'll look into other options. Thanks again.

One of those options might be to replace Xcode's clang. For me the following works (after making a backup
of the original files of course ;-):

Replace clang's executables/libraries (libclang must be replaced because recent clang versions changed
the serialization scheme for error messages, so with Xcode's libclang Xcode cannot read clang's output
anymore):

  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libclang.dylib

Not sure if this one needs to be replaced:

  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib

Optionally replace the libc++ headers:

  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1

Copy clang's header and runtime support libraries to:

  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/<version>

Please note that after doing this MacPorts will no longer work, as the version schemes of Xcode's clang and
LLVM's clang differ, so MacPorts fails to recognize it. I just temporarily switch back to Xcode's original
clang (executable is enough) to work around this.

HTH,
Jonathan

Hello,

clang plugins will in fact only load and run properly in the exact same build configuration and source tree version (SVN revision+patches) of LLVM and clang. The compiler used to build either also needs to match, so that's unlikely to ever work.

Thanks for this information, it would have saved me hours if I knew it earlier. Could this limitation be mentioned on the Clang Tooling page so that people know that plugins aren't suitable for use cases like mine?

I'll look into other options. Thanks again.

One of those options might be to replace Xcode's clang. For me the following works (after making a backup
of the original files of course ;-):

Thanks for the suggestion, but it isn’t really an option since this plugin wouldn’t be just for my own personal use, so I would have to force other developers to use custom clang with their Xcode just to get this plugin, which isn’t very practical. I suspect this is the case for most plugin writers who want to distribute their plugins to other developers.

- Nikita Zhuk

I don't know if this is any better, but how about using the custom version of Clang as a separate build step. This is to avoid replacing Clang shipped with Xcode.

Also, https://github.com/Jean-Daniel/clang-xcode might be able to
help. It lets you select the "Clang Nightly" compiler from the Xcode
drop-down list. I'm not sure if it can also hook into the "Analyze"
action in Xcode.

Cheers,
Jevin