Re: lang/rust/Makefile for 1.82.0 has wrong llvm:min= value [I got that incorrect]; more

[Charlie is correct about LLVM 17 being allowed by 1.82.0 of rust.
I had that wrong.]

On Nov 14, 2024, at 14:26, Mark Millard <marklmi@yahoo.com> wrote:
> 
> On Nov 14, 2024, at 13:21, Charlie Li <vishwin@freebsd.org> wrote:
> 
>> Mark Millard wrote:
>>> https://github.com/rust-lang/rust/pull/130487 reports . . .
>>> QUOTE
>>> Update the minimum external LLVM to 18 #130487
>>> With this change, we'll have stable support for LLVM 18 and 19.
>>> For reference, the previous increase to LLVM 17 was #122649.
>>> END QUOTE
>>> Note: the internal LLVM is 19 for 1.82.0 .
> 
>> This commit is not in the 1.82 releases so the USES=llvm values remain correct. It will be bumped for 1.83 as tagged in the pull request.> It leads me to wonder if lang/rust should be using an external

I see what you were refering to now. I misinterpreted your wording the first time.
In more detail:

# grep -r "bad LLVM version: {version}, need >=" /wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/
/wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/src/bootstrap/src/core/build_steps/llvm.rs:    panic!("\n\nbad LLVM version: {version}, need >=17.0\n\n")

More fully for the LLVM version check:

fn check_llvm_version(builder: &Builder<'_>, llvm_config: &Path) {
    if builder.config.dry_run() {
        return;
    }

    let version = command(llvm_config).arg("--version").run_capture_stdout(builder).stdout();
    let mut parts = version.split('.').take(2).filter_map(|s| s.parse::<u32>().ok());
    if let (Some(major), Some(_minor)) = (parts.next(), parts.next()) {
        if major >= 17 {
            return;
        }
    }
    panic!("\n\nbad LLVM version: {version}, need >=17.0\n\n")
}

Sorry for the noise.

> From using pkg to update to the recent official lang/rust distribution:
> 
> # rustc -vV
> rustc 1.82.0 (f6e511eec 2024-10-15) (built from a source tarball)
> binary: rustc
> commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
> commit-date: 2024-10-15
> host: x86_64-unknown-freebsd
> release: 1.82.0
> LLVM version: 19.1.1
> 
> So the internal LLVM for lang/rust is LLVM 19.1.1 based as of that
> update.
> 
> It is not my build, but is the official FreeBSD one for main [so:
> 15 as stands].
> 
> For reference:
> 
> # pkg info rust
> rust-1.82.0_1
> Name           : rust
> Version        : 1.82.0_1
> Installed on   : Thu Nov 14 22:09:53 2024 UTC
> Origin         : lang/rust
> Architecture   : FreeBSD:15:amd64
> Prefix         : /usr/local
> Categories     : lang
> Licenses       : MIT or APACHE20
> Maintainer     : rust@FreeBSD.org
> WWW            : https://www.rust-lang.org/
> Comment        : Language with a focus on memory safety and concurrency
> Options        :
> DOCS           : on
> GDB            : off
> LTO            : off
> PORT_LLVM      : off
> SOURCES        : on
> WASM           : on
> Shared Libs required:
> libcurl.so.4
> Shared Libs provided:
> libstd-d4ce5f4319a0892a.so
> librustc_driver-3dd68610bfbc3827.so
> Annotations    :
> FreeBSD_version: 1500026
> build_timestamp: 2024-11-12T01:08:37+0000
> built_by       : poudriere-git-3.4.2
> cpe            : cpe:2.3:a:rust-lang:rust:1.82.0:::::freebsd15:x64:1
> port_checkout_unclean: no
> port_git_hash  : b039f2e46b1
> ports_top_checkout_unclean: no
> ports_top_git_hash: ea7acb65556
> repo_type      : binary
> repository     : FreeBSD
> Flat size      : 1.14GiB
> . . .
> 
> The only way the internal LLVM for lang/rust ends up being based on
> LLVM 18 for 1.82.0 is via use of PORT_LLVM , which the official
> FreeBSD package builders do not do (at this time).
> 
> So lang/rust 1.82.0 builds can potentially have newer, LLVM 19
> specific material if there is such.
> 
>>> devel/llvm* by default, set to match a default ports tree
>>> LLVM to be used for major ports that involve lang/rust use.
>> No. Not something upstream encourages by default even if support exists, especially because the default upstream builds use the bundled LLVM which is what most consumers qualify with.
> 
> The FreeBSD may at times have to update such that the default
> LLVM is forced to well match the lang/rust default LLVM. That
> might mean not updating lang/rust . (I'm not claiming there
> are always conflicts to deal with when LLVM's mismatch, just
> that there could be such at times.)



===
Mark Millard
marklmi at yahoo.com