exaloop / exaloop/codon

Why link with external shared libs?

Open
#743 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
16.8k
Forks
603
Avg merge
4d 23h
Merged PRs (30d)
6

Description

Why do you guys need to build shared version of openmp? This creates the need to copy it and its dependencies around while if you'd link with a static version of openmp none of this would be required - you'd only need to distribute shared versions of codonc and codonrt.

I discovered that it's possible to achieve it with the following cmake properties when building codon llvm:

```
BUILD_SHARED_LIBS=OFF
LLVM_BUILD_LLVM_DYLIB=OFF
LLVM_LINK_LLVM_DYLIB=OFF
LIBOMP_ENABLE_SHARED=OFF
LLVM_ENABLE_RUNTIMES=openmp
OPENMP_STANDALONE_BUILD=ON

# note: NO LLVM_ENABLE_PROJECTS !
```

`libomp.a` gets built and placed in the regular `/lib` location together with all other static libs `libLLVM*.a`

**One significant benefit of this approach is that **it does not build clang**. If one already has it installed in the system - why build it?? **

Then I just modified your codon/CMakeLists.txt to completely remove any mentioning of external shared lib - **libgfortran.so, libomp.so, libquadmath.so and libgcc_s.1.1.so** and everything builds just fine.

library `omp` needs to be specified as a link library, and it gets found automatically because LLVM lib dir is already on the linker's -L list

Here is what I get:
```
ldd build/Release/codon
linux-vdso.so.1 (0x00007ffe35af5000)
libcodonc.so => /sysroot/home/yfinkelstein/conan_support/recipes/codon/all/build/Release/libcodonc.so (0x00007c20acc00000)
libcodonrt.so => /sysroot/home/yfinkelstein/conan_support/recipes/codon/all/build/Release/libcodonrt.so (0x00007c20ac400000)
libcodon_jupyter.so => /sysroot/home/yfinkelstein/conan_support/recipes/codon/all/build/Release/libcodon_jupyter.so (0x00007c20b0b67000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007c20b0a73000)
libc++.so.1 => /lib/x86_64-linux-gnu/libc++.so.1 (0x00007c20ac2e7000)
libc++abi.so.1 => /lib/x86_64-linux-gnu/libc++abi.so.1 (0x00007c20b0a32000)
libunwind.so.1 => /lib/x86_64-linux-gnu/libunwind.so.1 (0x00007c20acbf2000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007c20acbc4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007c20ac000000)
/lib64/ld-linux-x86-64.so.2 (0x00007c20b0bb4000)
```

This was built with system clang 20.1.8 and -stdlibc++

Contributor guide

Open the contributing guide

Research direction

Start with codon/CMakeLists.txt and inspect how external shared libraries, OpenMP, and LLVM are currently linked. Reproduce the build using the listed CMake properties, then verify that codon builds without the proposed external shared-library dependencies and that the resulting linkage matches the issue’s example.

Written by the indexing model from the issue text.

Assessment

Tech stack
cmake, cpp
Domain
build-system, compilers
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.