On Wed, Jun 6, 2012 at 6:25 PM, Jordan Rose <[email protected]> wrote:
> > On Jun 5, 2012, at 23:24 , Manuel Klimek <[email protected]> wrote: > > On Tue, Jun 5, 2012 at 4:56 PM, Erik Verbruggen <[email protected]> wrote: > >> >> On Jun 4, 2012, at 15:32, Manuel Klimek wrote: >> >> On Fri, Jun 1, 2012 at 1:10 PM, Erik Verbruggen <[email protected]> wrote: >> >>> >>> On May 24, 2012, at 19:07, Manuel Klimek wrote: >>> >>> > Author: klimek >>> > Date: Thu May 24 12:07:18 2012 >>> > New Revision: 157396 >>> > >>> > URL: http://llvm.org/viewvc/llvm-project?rev=157396&view=rev >>> > Log: >>> > Adds a tutorial for how to write clang plugins. >>> >>> Sorry for the late reply, but it would be really nice if you could add a >>> paragraph which mentions the libraries used for linking (for all those >>> people who want (have?) to use esoteric build systems)... >>> >> >> Hm, since this is a dynamic library, doesn't it basically not require >> linking anything in at compile time, but the right symbols to be available >> in the clang executable at runtime? Or did you have something else in mind? >> >> >> I link with: >> >> clang++ -headerpad_max_install_names -arch x86_64 -o qt-checker main.o >> -L/data/clang-llvm/llvm-3.1-install/lib -lpthread -lm -lLLVMCore >> -lLLVMSupport -lclangTooling -lclangAST -lclangFrontend >> -lclangSerialization -lclangSema -lclangAnalysis -lclangBasic -lclangEdit >> -lclangLex -lclangParse -Wl,-undefined,dynamic_lookup -L../checkers >> -lcheckers >> >> I get: >> >> dyld: lazy symbol binding failed: Symbol not found: >> __ZN5clang6driver6DriverC1EN4llvm9StringRefES3_S3_bRNS_17DiagnosticsEngineE >> Referenced from: /data/git/qtcheckers/app/qt-checker >> Expected in: dynamic lookup >> >> Etc. For clang plug-ins it works, but apparently not for tooling >> executables... >> > > Ah, but then ClangPlugins.html seems the wrong place. Also, since clang is > pretty nicely modularized here, the process seems to be: look into the > Makefiles or CMakeLists.txt for the libraries you use, build the transitive > closure, and link that in? Not sure there's a better way to document this, > as those dependencies change... > > Cheers, > /Manuel > > > FWIW CMake seems to do the transitive closure part for you, but gmake > won't. And I'd also be in favor of adding the current requirements for > linking against Tooling, at least, to LibTooling.html, with a caveat saying > that it might not be up-to-date. This would also be useful for people who > want to build clang-based tools outside of the clang source tree. > All right: r158088. Cheers, /Manuel
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
