# Ccall for LTO libraries with LLVM backend

**URL:** <https://discourse.julialang.org/t/ccall-for-lto-libraries-with-llvm-backend/58186>\
**Category:** Internals & Design\
**Created:** [March 29, 2021, 7:10pm UTC](https://discourse.julialang.org/t/ccall-for-lto-libraries-with-llvm-backend/58186 "2021-03-29T19:10:30Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Artoria2e5](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/artoria2e5/32/23433_2.png) [@Artoria2e5](https://discourse.julialang.org/u/Artoria2e5)\
**Post date:** [March 29, 2021, 7:10pm UTC](https://discourse.julialang.org/t/ccall-for-lto-libraries-with-llvm-backend/58186/1 "2021-03-29T19:10:30Z")

</div>

A lot of LLVM languages like Rust support cross-language optimization at link time, allowing e.g. C code to be inlined and further optimized to LLVM’s wish. Since Julia also heavily uses LLVM (albeit in a more… just-in-time way), I wonder whether it’s worth looking at.

While the current `ccall` works in a very traditional `dlopen` paradiam with dynamic libraries, a LTO call would involve a search for the corresponding “static” library and fetching the bitcode from there.

Having peeked at how `ccall.cpp` looks, I have… no idea whether this might even be possible with all the runtime functions that might need to be injected. I also have no idea how the extra bitcode files will fit into the JIT flow – are they additional modules now?