On 10/31/26 16:50, Leonard Rucker wrote: > On Sat, 26 Sep 2026 20:39:46 -0700 > Leonard Rucker <[email protected]> wrote: > >> On Sat, 26 Sep 2026 09:24:40 +0200 >> Matthias Fechner <[email protected]> wrote: >> >>> Hi Len, >>> >>> Am 26.09.26 um 00:31 schrieb Leonard Rucker: >>>> I am working on a port of the joplin-server backend. I am >>>> learning the ports system as I go and I have going much support >>>> from the various people as well just reading the other ports, the >>>> Mk files, and the porter's handbook. Right now I am trying to >>>> figure out how to make an offline cache for packing that are >>>> trying to be installed when I do the actual build of the app. >>>> I've read around about making a offline cache and found what the >>>> cache looks like but have yet been able to make the cache >>>> tarball. Could someone point me in the right direction as to how >>>> to make this file? Also I seems like there is a lot of >>>> node_module bloat when the build is done. I don't think I need >>>> all the files in the final pkg file. My question is how do I >>>> whittle this down to a reason amount. >>> >>> if you tell use for what you want to make a cache it would be easier >>> to help you. >>> The directory node_modules does not give a clue about the node >>> package manager you use. >>> >>> I have several example available that I use. >>> yarn: net/gotify-server >>> npm: www/SpectrumKNX >>> pnpm: www/fmd-server (not verified) >>> >>> I also saw that a npm USE flag was added, maybe that helps too. >>> >>> Matthias >>> >>> >> >> Mi Matthias, >> >> Thanks so much net/gotify's Makefile had a build target for >> building an offline cache and that worked very well. Now I am on to my >> next build problem. >> >> Len >> > I found a fix to my problem. I needed to set OPTION PORT_LLVM when > building Rust. It appears that the version of LLVM that is bundled with > Rust is 23. I guess either you cannot have an older provider with a > newer reader when linking rust binaries, or something changed in Rust > or LLVM that was exposed with LLVM23 that isn't present with LLVM22 and > LLVM21. > >
Was LTO involved? LTO involves LLVM bit code files (.bc file) for which older version LLVM linkers do not generally handle for newer version LLVM bit code. Going the other way is allowed but has the issue that the newer semantics used may not fully match the older semantics, including undefined behavior details and optimization mismatches. This is a greater degree of issues than when .bc file usage is avoided. For this type of context, using older version LLVM linkers with newer version non-LTO clang/clang++ code can still have its own examples of running into something new that it does not handle (not as common). Building rust things that involve linking non-rust things best use the same LLVM toolchain. A difficulty here is that the range of LLVM versions' allowed for a given rust version's build can be fairly narrow: Rust 1.79 allowed only LLVM17 and LLVM18 . But 1.99 is fairly wide: LLVM18 .. LLVM23 . However, only LLVM23 building gets fixes for mis-compilations: no explicit backporting of fixes to LLVM18 .. LLVM22 based build contexts when the distinction matters. -- === Mark Millard marklmi at yahoo.com
