Date: Tue, 21 Jun 2022 03:34:43 +0000 From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 264783] graphics/mesa-dri pulls in the entire llvm package Message-ID: <bug-264783-7141-zAFXxZrVCK@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-264783-7141@https.bugs.freebsd.org/bugzilla/> References: <bug-264783-7141@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264783 --- Comment #4 from Charlie Li <vishwin@freebsd.org> --- (In reply to Bill Blake from comment #3) It's not that simple. Especially not without subpackage support in the ports framework, ie packaging separate portions of the staging section as separate packages. The work to get there is another story altogether and depends on everyone's collective cycles availability. I don't think many folks, myself included, are happy with the situation that LLVM consumes significant storage, but LLVM is a rather dense software. It = is further complicated by how there is no guarantee of API/ABI stability betwe= en major versions. For mesa specifically, the part that requires LLVM specifically is the swra= st driver, better known as LLVMpipe, a software graphics renderer. swrast is dynamically linked to libLLVM (example taken from my somewhat-off-the-beaten-path copy of mesa): % readelf -d /usr/local/lib/dri/swrast_dri.so Dynamic section at offset 0x19242f0 contains 37 entries: Tag Type Name/Value 0x0000000000000001 NEEDED Shared library: [libglapi.so.0] 0x0000000000000001 NEEDED Shared library: [libdrm.so.2] 0x0000000000000001 NEEDED Shared library: [libLLVM-14.so] 0x0000000000000001 NEEDED Shared library: [libexpat.so.1] 0x0000000000000001 NEEDED Shared library: [libz.so.6] 0x0000000000000001 NEEDED Shared library: [libm.so.5] 0x0000000000000001 NEEDED Shared library: [libdrm_radeon.so.= 1] 0x0000000000000001 NEEDED Shared library: [libelf.so.2] 0x0000000000000001 NEEDED Shared library: [libdrm_amdgpu.so.= 1] 0x0000000000000001 NEEDED Shared library: [libc++.so.1] 0x0000000000000001 NEEDED Shared library: [libcxxrt.so.1] 0x0000000000000001 NEEDED Shared library: [libgcc_s.so.1] 0x0000000000000001 NEEDED Shared library: [libthr.so.3] 0x0000000000000001 NEEDED Shared library: [libc.so.7] 0x000000000000000e SONAME Library soname: [libgallium_dri.so] 0x0000000000000007 RELA 0xa480 0x0000000000000008 RELASZ 500760 (bytes) 0x0000000000000009 RELAENT 24 (bytes) 0x000000006ffffff9 RELACOUNT 20420 0x0000000000000017 JMPREL 0x84898 0x0000000000000002 PLTRELSZ 16104 (bytes) 0x0000000000000003 PLTGOT 0x192a6d8 0x0000000000000014 PLTREL RELA 0x0000000000000006 SYMTAB 0x2d0 0x000000000000000b SYMENT 24 (bytes) 0x0000000000000005 STRTAB 0x6684 0x000000000000000a STRSZ 15868 (bytes) 0x000000006ffffef5 GNU_HASH 0x4f18 0x0000000000000004 HASH 0x4f84 0x0000000000000019 INIT_ARRAY 0x000000000000001b INIT_ARRAYSZ 112 (bytes) 0x000000000000000c INIT 0x6427f4 0x000000000000000d FINI 0x642804 0x000000006ffffff0 VERSYM 0x47b8 0x000000006ffffffe VERNEED 0x4d78 0x000000006fffffff VERNEEDNUM 8 0x0000000000000000 NULL 0x0 But libLLVM-${LLVM_SUFFIX}.so lives in ${PREFIX}/llvm${LLVM_SUFFIX}/lib, not ${PREFIX}/lib, so as to keep much of the LLVM distribution together in one = spot (because remember, LLVM is dense), which has us invoking ldconfig(8) to add= the LLVM hierarchy into the dynamic linker search path. It is a bad idea to have multiple copies of the same exact shared object floating around, especially with the same SONAME, as they have the chance to cause collisions. Additionally, this and many other programs in and outside the ports tree re= ly on other components of LLVM to build or run, often using llvm-config to feed the build system LLVM configuration information, interfacing with shared or static objects or a combination of both. So no, we cannot simply give the library a new name and copy it in. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-264783-7141-zAFXxZrVCK>