# BinaryBuild: build with a specific version of LLVM and clang

**URL:** https://discourse.julialang.org/t/binarybuild-build-with-a-specific-version-of-llvm-and-clang/107456
**Category:** Package Management
**Tags:** question, binarybuilder
**Created:** [December 11, 2023, 4:13pm UTC](https://discourse.julialang.org/t/binarybuild-build-with-a-specific-version-of-llvm-and-clang/107456 "2023-12-11T16:13:52Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![grasph](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/grasph/32/25684_2.png) [@grasph](https://discourse.julialang.org/u/grasph)
#### Post date: [December 11, 2023, 4:13pm UTC](https://discourse.julialang.org/t/binarybuild-build-with-a-specific-version-of-llvm-and-clang/107456/1 "2023-12-11T16:13:52Z")

</div>

Hello,

I would like to make the [`wrapit`](https://github.com/grasph/wrapit) executable available through the `BinaryBuilder` facilities.

The code (C++) uses LLVM and clang. I can use the corresponding \_jll packages. Nevertheless, I want to fix the version to the one the `wrapit` binary was tested with.

Using the `_jll` dependencies, I am bound to the LLVM version used by the `julia` application of the user: it won’t accept to install another `libLLVM_jll` version than the one Julia uses internally.

It should not be a problem to have the `libLLVM` and `Clang` artifacts of the desired version installed and use the `libLLVM`, `libclang` and `libclang-cpp` libraries they provide. Ideally I would like to have symbolic links to them in the lib directory of the `wrapit` binary artifact so `wrapit` can be executed without the complication of setting `LD_LIBRARY_PATH`.

What is the proper way to achieve this? Should I make a custom `Wrapit_jll` package, that will include `libLLVM` and `libclang` artifacts in its `Artifact.toml` file, to substitute the one produced by `BinaryBuilder`?

Philippe.

---

<div class="post-metadata">

### Author: ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [December 11, 2023, 6:38pm UTC](https://discourse.julialang.org/t/binarybuild-build-with-a-specific-version-of-llvm-and-clang/107456/2 "2023-12-11T18:38:17Z")

</div>

> [@grasph](#):
>
> The code (C++) uses LLVM and clang. I can use the corresponding \_jll packages. Nevertheless, I want to fix the version to the one the `wrapit` binary was tested with.

There are multiple LLVMs involved, so you have to be very clear about what you want: do you need only a cross-compiler toolchain to compile C/C++ code (`clang`) for the target platform, or you need to link your code to a libllvm built for the target platform? In the former case, you can control the version of llvm used by passing `preferred_llvm_version="..."` to the function `build_tarballs`, in the latter case you can have a single recipe producing multiple versions of a single package, linking each time to a different version of llvm: this is what the [Enzyme recipe](https://github.com/JuliaPackaging/Yggdrasil/blob/bb8bd32f22467fc1eaaf8fcf28744ed0fe397e72/E/Enzyme/build_tarballs.jl) does, which currently produces builds compatible with libllvm 11-15.

---

<div class="post-metadata">

### Author: ![grasph](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/grasph/32/25684_2.png) [@grasph](https://discourse.julialang.org/u/grasph)
#### Post date: [December 11, 2023, 10:12pm UTC](https://discourse.julialang.org/t/binarybuild-build-with-a-specific-version-of-llvm-and-clang/107456/3 "2023-12-11T22:12:50Z")

</div>

Hello Mosè,

I am in the second situation. The code is using clang, itself using LLVM, to interpret c++ code. The versions of LLVM and clang are tight together.

I already had issues with differences between clang version and I don’t want to maintain and support different versions, neither to force to use a specific Julia version.

The idea would be to get the artifact containing the LLVM and clang libraries of the desired version installed independently of the version used by Julia itself. They should not interfere.

Philippe.

---

<div class="post-metadata">

### Author: ![grasph](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/grasph/32/25684_2.png) [@grasph](https://discourse.julialang.org/u/grasph)
#### Post date: [December 13, 2023, 9:16pm UTC](https://discourse.julialang.org/t/binarybuild-build-with-a-specific-version-of-llvm-and-clang/107456/4 "2023-12-13T21:16:42Z")

</div>

I’ve made a PR with the recipe. It is not perfect but it is working. Followup can be done in the PR discussion thread.

> <https://github.com/JuliaPackaging/Yggdrasil/pull/7798>
>
> Recipe to make WrapIt\_jll package providing the \[wrapit\](https://github.com/gras…ph/wrapit) binaries. WrapIt is an application written in C++ to generate automatically from the headers the code to make Julia binding using CxxWrap.
> 
> The \_jll package ships an executable that uses LLVM and clang libraries. As explained in \[this discourse thread\](), we don't want the version of the used libraries to depend on the julia version used to install the \_jll.
> 
> The version decorrelation is achieved by adding a dependency directly on the artifacts of Clang\_jll and libLLVM\_jll of the desired version (v. 16) instead of depending on the \_jll packages.
> 
> Two points could be improved in the recipe:
> 
> \* The libclang and libLLVM shared library are copied in our artifact, while a symbolic to the files provided by the Clang\_jll and libLLVM\_jll artifacts would have been preferred; 
> \* The produces \_jll misses the Artificats we depend on in its Artifact.toml file. We need to put them in the julia helper module that will use this \_jll.
>  
> I've not found how to include the symbolic links to the regular files in the generated tarball, neither how to customize the Artifacts.toml (probably not possible).
> 
> Recommendation to improve these two points is welcome or on the general approach to achieve the goal is welcome. 
> 
> The points are not blocking as in practice the recipe is working.
> 
> Philippe.

Regards,  
Philippe.
