You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
finding the right combination of compilation flags for locating headers and linking against the right libclang is tricky and not user-friendly as (mainly) there is no pkg-config support for neither LLVM nor CLang.
there is a llvm-config program that mimics what pkg-config can do, but only for LLVM libraries, not libclang.
On top of that, llvm-config may not have been installed, or with a slightly different name, depending on the Linux distribution or OS.
to ease the burden on our brave users, we should probably have either a go run ./config-cgo.go program or a go generate step to perform the following drudgery:
find llvm-config and extract/infer the correct CFLAGS and LDFLAGS (handling the possible naming variations of libclang.so[.MAJOR[.MINOR]]
if no llvm-config could be found, try to look into canonical locations for the given libclang version, depending on the Linux distribution (or OS.)
then generate a cgoflags_gen.go file with the correct // #cgo directives embedded and hard-coded.
The text was updated successfully, but these errors were encountered:
A general question, do we need repositories that are go-getable? I mean at the moment we say that users should use CGO_LDFLAGS="-Lllvm-config --libdir" go get -u github.com/go-clang/v3.7/... That is go-getable if libclang exists. I am asking because "go generate" (or any other code generation) means that the user has to do additional steps.
finding the right combination of compilation flags for locating headers and linking against the right libclang is tricky and not user-friendly as (mainly) there is no
pkg-config
support for neither LLVM nor CLang.there is a
llvm-config
program that mimics whatpkg-config
can do, but only forLLVM
libraries, notlibclang
.On top of that,
llvm-config
may not have been installed, or with a slightly different name, depending on the Linux distribution or OS.to ease the burden on our brave users, we should probably have either a
go run ./config-cgo.go
program or ago generate
step to perform the following drudgery:llvm-config
and extract/infer the correctCFLAGS
andLDFLAGS
(handling the possible naming variations oflibclang.so[.MAJOR[.MINOR]]
llvm-config
could be found, try to look into canonical locations for the givenlibclang
version, depending on the Linux distribution (or OS.)cgoflags_gen.go
file with the correct// #cgo
directives embedded and hard-coded.The text was updated successfully, but these errors were encountered: