From owner-freebsd-ports@freebsd.org Thu Jan 17 15:02:26 2019 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87AAE1499966 for ; Thu, 17 Jan 2019 15:02:26 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 288D06B6E9; Thu, 17 Jan 2019 15:02:26 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id EE28F15B8A; Thu, 17 Jan 2019 15:02:25 +0000 (UTC) From: Jan Beich To: Niclas Zeising Cc: Mahmoud Al-Qudsi , freebsd-ports@freebsd.org Subject: Re: Separate build/runtime llvm60 dependencies References: <909db0dd-afb1-8b7a-9b3d-0fe3295f911b@freebsd.org> Date: Thu, 17 Jan 2019 16:02:22 +0100 In-Reply-To: <909db0dd-afb1-8b7a-9b3d-0fe3295f911b@freebsd.org> (Niclas Zeising's message of "Thu, 17 Jan 2019 15:12:46 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 288D06B6E9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.92 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.99)[-0.993,0]; NEURAL_HAM_SHORT(-0.93)[-0.928,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-0.998,0] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 15:02:26 -0000 Niclas Zeising 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 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.