On Sat, 31 Oct 2026 18:39:05 -0700 Mark Millard <[email protected]> wrote:
> 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. > I don't think LTO was involved. I emabled it and did a build which didn't change anything I then enabled PORT_LLVM but did not disable LTO... I could provide logs too if it would help. >
