Date: Thu, 14 Nov 2024 20:27:11 -0800 From: Mark Millard <marklmi@yahoo.com> To: Tatsuki Makino <tatsuki_makino@hotmail.com> Cc: FreeBSD Mailing List <freebsd-ports@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, "mikael@freebsd.org" <mikael@FreeBSD.org>, Charlie Li <vishwin@freebsd.org> Subject: Re: lang/rust/Makefile for 1.82.0 has wrong llvm:min= value [I got that incorrect]; more Message-ID: <55F75811-D9BA-47DB-81BC-682FAB2679C8@yahoo.com> In-Reply-To: <SI2PR01MB50366EE21D0A5571D9FDBE58FA242@SI2PR01MB5036.apcprd01.prod.exchangelabs.com> References: <6D0FF1C8-CA51-44B0-A1D8-0B4F670F647C.ref@yahoo.com> <6D0FF1C8-CA51-44B0-A1D8-0B4F670F647C@yahoo.com> <6f3f4b47-05a2-453a-8d1c-258d17fc1a1c@freebsd.org> <52DCD460-D1BE-4F74-A567-347C8D9F31CE@yahoo.com> <89CFA496-9433-4417-A996-EC7D89A9B3A6@yahoo.com> <SI2PR01MB50366EE21D0A5571D9FDBE58FA242@SI2PR01MB5036.apcprd01.prod.exchangelabs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 14, 2024, at 19:30, Tatsuki Makino <tatsuki_makino@hotmail.com> = wrote: > Since option PORT_LLVM is not turned on in the official version, it = seems that there is no problem with using of the bundle llvm. > However, if we want to use llvm instead of a bundle on an architecture = where the compiler causes problems, that version is no longer supported = and we need to rewrite the version number there. >=20 > =E2=80=A6 Is that what you mean? :) When I got into this area it was because someone on discord was getting errors like: ld.lld: error: = ../../../x86_64-unknown-freebsd/release/libgkrust.a(ews_xpcom-da5573b2cf91= b84e.ews_xpcom.c68a27d7391ba4aa-cgu.0.rcgu.o): Unknown attribute kind = (91) (Producer: 'LLVM19.1.1-rust-1.82.0-stable' Reader: 'LLVM 17.0.6') = clang++: error: linker command failed with exit code 1 (use -v to see = invocation) For the example, in essence, LLVM 17's "Reader" was reporting finding = LLVM 19 content, which, to LLVM 17, had an example of "Unknown attribute kind = (91)". (LLVM 19's "Reader" likely would not have classified it that way.) So rust's internal LLVM 19 toolchain was generating output that LLVM = 17's toolchain could not handle but was being told to process. This tends to suggest that using older linkers (or such) to link rust = output that internally used a newer LLVM toolchain sometimes fails to be = compatible. That leaves 3 basic options (stated for the specfics of the example in question): ) Have everything involved use a LLVM 19 toolchain matching lang/rust 's internal LLVM 19 toolchain, here LLVM 19.1.1 . ) Have lang/rust use the devel/llvm* toolchain that matches the context, here LLVM 17.0.6 . ) Use some other LLVM toolchain vintage for everything involved, say a=20= devel/llvm18 toolchain. (Those are options that avoid doing some sort of detailed compatibility analysis across differing toolchain versions in order to pick some possibly mixed set of versions.) =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55F75811-D9BA-47DB-81BC-682FAB2679C8>