Separate build/runtime llvm60 dependencies
Jan Beich
jbeich at FreeBSD.org
Thu Jan 17 15:02:26 UTC 2019
Niclas Zeising <zeising at freebsd.org> writes:
> On 1/17/19 12:17 AM, Mahmoud Al-Qudsi wrote:
>
>> Hello list,
>>
>> Another complaint about `llvm60` here - I was hoping that the situation would be
>> ameliorated before the release of FreeBSD 12, but alas that is not the case.
>>
>> From what I understand, `mesa-dri` doesn't build out-of-the-box with `llvm70`.
>> Cool. But that makes `llvm60` a build dependency for `mesa-dri` - the binary
>> package should not require installing 813 MiB's worth of compilers,
>> documentation, etc. just to run something built with that toolchain.
>>
>> Surely the runtime components of `llvm60` sufficient to use libraries built with
>> that toolchain can be split off into their own package? Even better, perhaps
>> `mesa-dri` can be statically compiled? (I know it has C++ components, but I'm
>> not sure if they ever cross the API barrier -- I haven't looked into it though,
>> so it's just wild speculation on my part.)
>>
>> (I do see that there exists a patch for getting `mesa-dri` to build with
>> `llvm70` hopefully making this conversation somewhat moot, but I still strongly
>> object to the principle of adding such massive dependencies for common
>> packages.)
>>
>
>
> This has been discussed several times in the past. Mesa uses
> libraries and components of llvm that are not in base, hence the
> dependency on the ports version of llvm. This also untangles some of
> the issues with llvm library usage, since we only have to support one
> version of llvm usage in mesa, regardless of FreeBSD version.
>
> Since mesa uses llvm libraries (not just toolchain to build) this can
> not be made in to a build time only dependency.
Did anyone actually try to switch mesa-* ports to --disable-llvm-shared-libs?
In the past libLLVM.so caused crashes when another application/library/plugin
loaded a different version of it due to GLOBAL bindings.
$ readelf -a /usr/local/llvm*/lib/libLLVM.so | fgrep LLVMContextCreate
6561: 0000000000771660 37 FUNC GLOBAL DEFAULT 11 LLVMContextCreate
36811: 0000000000771660 37 FUNC GLOBAL DEFAULT 11 LLVMContextCreate
5310: 00000000007556b0 37 FUNC GLOBAL DEFAULT 11 LLVMContextCreate
38133: 00000000007556b0 37 FUNC GLOBAL DEFAULT 11 LLVMContextCreate
6964: 00000000016be100 37 FUNC GLOBAL DEFAULT 15 LLVMContextCreate@@LLVM_5.0
47409: 00000000016be100 37 FUNC GLOBAL DEFAULT 15 LLVMContextCreate
23143: 0000000001a0ab00 37 FUNC GLOBAL DEFAULT 15 LLVMContextCreate@@LLVM_6.0
46948: 0000000001a0ab00 37 FUNC GLOBAL DEFAULT 15 LLVMContextCreate
7565: 0000000001b72810 37 FUNC GLOBAL DEFAULT 15 LLVMContextCreate@@LLVM_7
52448: 0000000001b72810 37 FUNC GLOBAL DEFAULT 15 LLVMContextCreate
Let's imitate what may happen at runtime.
$ cat >a.c
#include <llvm-c/Core.h>
int main()
{
LLVMContextCreate();
return 0;
}
$ cc a.c $(llvm-config70 --libs --ldflags --cppflags)
$ ldd a.out | fgrep llvm
libLLVM-7.so => /usr/local/llvm70/lib/libLLVM-7.so (0x800400000)
$ ./a.out
$ LD_PRELOAD=/usr/local/llvm39/lib/libLLVM.so ./a.out
Assertion failed: (count_if(RegisteredOptionCategories, [cat](const OptionCategory *Category) { return cat->getName() == Category->getName(); }) == 0 && "Duplicate option categories"), function registerCategory, file /usr/ports/devel/llvm39/work/llvm-3.9.1.src/lib/Support/CommandLine.cpp, line 278.
More information about the freebsd-ports
mailing list