Comment 1 Mikael Urankar 2023-12-09 15:31:51 UTC

Is it still an issue?

I just reproduced this very same issue.  Tried to build rust with PORT_LLVM on, and experienced the same relocation errors as in the original report. So I think this issue is still a problem, and I can only build rust without PORT_LLVM.


My system:
FreeBSD xxxx.xxx 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n256726-7c25a53a2cb9 GENERIC amd64

Ports: git describe output:  13.1-eol-14216-g7e50d55c75b1

LLVM15 package info:
Name           : llvm15
Version        : 15.0.7_7
Installed on   : Sat Nov 25 23:10:49 2023 MST
Origin         : devel/llvm15
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : lang devel
Licenses       : REGEX and PD and MIT and LLVM2 and LLVM and BSD3CLAUSE
Maintainer     : brooks@FreeBSD.org
WWW            : https://llvm.org/
Comment        : LLVM and Clang
Options        :
        BE_AMDGPU      : on
        BE_FREEBSD     : off
        BE_NATIVE      : off
        BE_STANDARD    : on
        BE_WASM        : on
        CLANG          : on
        COMPILER_RT    : on
        DOCS           : on
        EXTRAS         : on
        FLANG          : on
        GOLD           : on
        LIT            : on
        LLD            : on
        LLDB           : on
        MLIR           : on
        OPENMP         : on
        PYCLANG        : on
        STATIC_LIBS    : on


Rust options are set to exclude WebAssembly (I think this used to be the default, and I never enabled it when WASM was set to be on by default).

Rust builds fine without PORT_LLVM, but gets the same errors as the original issue report with PORT_LLVM on.

I have nothing pertaining to LLVM or Rust in make.conf default versions variables.

(In reply to Mikael Urankar from comment #1)
> Is it still an issue?

My most recent attempt was with a 14.x system, when I attempted to build rust against the just-installed llvm16.

Why, was this supposed to be fixed by something?

Comment 4 Mikael Urankar 2023-12-10 16:12:34 UTC

Maybe with rust 1.74.1

> Maybe with rust 1.74.1

Nope. Just tried -- same error in the same part (ssh2 something). The full build log is about 17Mb, so I don't want to attach it.

Maybe, you try building it yourself?

I ran into this issue as well today when trying to update rust. Since the previous build of rust 1.73 on fresh 14.0 system succeeded, I tried removing libssh2 that had been installed as dependency for something else. After removing libssh2, rust with PORT_LLVM (version 17) builds again without the relocation errors.

(In reply to wenej27156 from comment #6)
On my system, libssh2 was pulled in by cargo-c and libgit2, and cargo-c turns out to be a build dependency for a number of ports on my system.  I'm reluctant to remove it just for rust's sake, since it'll just get reinstalled anyway the next time any of those other ports are updated.

But it's good to know where the problem is coming from.  There were other issues just recently with rust's build being borked by things like static libraries installed by assimp, among others (c.f. Bug 274723).

Those issues were "fixed" by making the other package not install those libraries, but that's just working around rust's build system trying to pull in libraries it can't use just because it finds them present on the system.  Here we seem to have the same problem.

Comment 8 Jan Beich 2023-12-11 12:31:38 UTC

lang/rust should probably switch to system libgit2/libssh for consistency with USES=cargo and to avoid ABI mismatch due to -I order[1]. Unfortunately, devel/libgit2 updates are often blocked by GitLab compatibility (e.g., bug 252098).

[1] -I/usr/local/include -I. (or similar) picks up system API over bundled.
    Caused by https://wiki.freebsd.org/WarnerLosh/UsrLocal#Include_paths
    Usually fixed by -isystem via USES=localbase.

Comment 9 Mikhail Teterin 2023-12-12 22:40:06 UTC

Created attachment 247014 [details]
LIB_DEPEND on git2 and ssh2

The attached patch side-steps the miscompilation problem by explicitly depending on libgit2.so and libssh2.so (in addition to libcurl.so).

The patch also prevents the bundled sources for the above (as well as for OpenSSL and llvm) from even being extracted from the tarball -- to prevent the possibility of compiling against the headers of one version of a library, then linking with another.

It'd be nice to similarly eliminate the bundled code for xz-5.2, but currently the tools like rust-installer insist on /static/ linkage, and I'm not sufficiently proficient with the cargo-syntax to patch that.

But this patch seems like a substantial improvement for the port already -- and may even allow to turn the PORT_LLVM option on /by default/.

Comment 10 Mikael Urankar 2023-12-13 12:44:20 UTC

(In reply to Mikhail Teterin from comment #9)
I'm opposed to this change, I've spent countless hours in the past debugging problems due to the use of an old libgit2 in ports and don't want to go through that again.

(In reply to Mikael Urankar from comment #10)
> I've spent countless hours

The amount of effort is seldom a good argument...

> problems due to the use of an old libgit2 in ports

You can add a minimal version-requirement to a LIB_DEPENDency, will that work?

The current "solution" -- using the bundled libgit2 and libssh2 -- violates the best-practices guidance^, and necessitates the "countless hours" of CPU-time as thousands of computers world-wide rebuild the LLVM bundled with rust -- in addition to LLVM from its own port (in addition to LLVM from src/).

And, as this very ticket demonstrates, "countless hours" of HUMAN time is spent figuring out, why enabling PORT_LLVM (which should always be enabled anyway^) breaks things.

^ https://docs.freebsd.org/en/books/porters-handbook/special/#bundled-libs