Date: Thu, 17 Jan 2019 16:02:22 +0100 From: Jan Beich <jbeich@FreeBSD.org> To: Niclas Zeising <zeising@freebsd.org> Cc: Mahmoud Al-Qudsi <mqudsi@neosmart.net>, freebsd-ports@freebsd.org Subject: Re: Separate build/runtime llvm60 dependencies Message-ID: <k1j3-z5s1-wny@FreeBSD.org> In-Reply-To: <909db0dd-afb1-8b7a-9b3d-0fe3295f911b@freebsd.org> (Niclas Zeising's message of "Thu, 17 Jan 2019 15:12:46 %2B0100") References: <CACcTrKcSMxYEiLdzsbeQ2DYOYWZ7KsPwry_hx0-CATD-tc5p5w@mail.gmail.com> <909db0dd-afb1-8b7a-9b3d-0fe3295f911b@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Niclas Zeising <zeising@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?k1j3-z5s1-wny>