Date: Tue, 05 Oct 2021 06:03:13 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258820 Kubilay Kocak <koobs@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://github.com/InBetwee | |nNames/gentooLTO/issues/49 CC| |dim@FreeBSD.org, | |firstname.lastname@example.org Flags| |maintainer-feedback?(emaste | |@freebsd.org), | |maintainer-feedback?(dim@Fr | |eeBSD.org) --- Comment #8 from Kubilay Kocak <koobs@FreeBSD.org> --- (In reply to Daniel Engberg from comment #7) Separating packages is orthogonal to addressing the root problem, sweeping the issue/question to a -static subpackage/flavor build. The root issue appears to be elftoolchain strip not understanding LLVM IR from LTO builds in or for static libraries. It may turn out that strip tools 'shouldnt' need to support stripping LTO-d static libraries, but I haven't found evidence that this is the case. So far I've additionally tried: - llvm-strip / llvm-objcopy --strip-debug (14.0-CURRENT #2 main-n249859-248682a5891) error: '/var/tmp/tmpfs0/usr/ports/devel/libuv/work/stage/usr/local/lib/libuv.a(libuv_la-fs-poll.o)': The file was not recognized as a valid object file - binutils: strip*: Unable to recognise the format of file: file format not recognized (Note: this error is not fatal.) - Notable also, llvm-nm reports no errors on the same file. I've been hunting authoritative upstream (llvm) references for bug reports or commits that hint at this issue, or how one should handle it, but haven't quite identified anything precisely on target. Feedback from Ed (for elftoolchain), and Dim (for LLVM) would be great for leads here. The ideal outcome here is the ability to strip debug symbols from static libraries built with LTO(thin), and ideally with the toolchain FreeBSD expects to have in the long-term (llvm's). If that turns out to require some tweaks to upstream LLVM/Clang tools, then we may be able to separately port llvm-strip (with the fixes) until all supported LLVM/Clang releases in base contain the appropriately fixed versions. Alternatively, have elftoolchain's strip support it in the short term, and have that in ports, if its not there already. Failing that, and down the list of desired partial resolutions, we could use a STRIP_MASK style setup for the strip framework mechanism, that supports excluding static libraries. Gentoo did this in the past when GNU strip was mangling static libraries  and its probably useful for us for other reasons too.  https://github.com/InBetweenNames/gentooLTO/issues/49 -- You are receiving this mail because: You are on the CC list for the bug.