You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not quite sure if this is the right place to track these things, but I've been trying to cross build the native host tools for Solaris (both x86 and SPARC).
x86_64
Environment
Cross: x86_64-apple-darwin → x86_64-pc-solaris
Sysroot: see below
Compiler: gcc 11.2.0
binutils: GNU binutils 2.40 + ar LLVM 16 (todo: test with GNU ar)
rust 1.70.0
Local changes to rust: #114078
Known issues
The rust build process sets -nodefaultlibs for reasons that aren't entirely clear to me. To get the build working successfully I had to wrap gcc and g++ with a small script to ensure that CFLAGS/CXXFLAGS always included --sysroot=${SYSROOT} -L${SYSROOT}/lib/amd64 -L${SYSROOT}/lib -Wl,-rpath-link,${SYSROOT}/lib/amd64
Linking to OpenSSL does not work. Headers seem to be from ≥ 1.1.0, linker finds libraries for 1.0.2. The build is stopped at cargo. Linker errors are all missing symbols (e.g. OPENSSL_init_ssl, BIO_meth_new). Solved by building sysroot from Solaris packages. Note: Ensure that the build picks up the pkg-config info at ${SYSROOT}/usr/openssl/3/lib/64/pkgconfig/libssl.pcor set OPENSSL_LIB_DIR="${SYSROOT}/usr/openssl/3/lib/64" and OPENSSL_INCLUDE_DIR="${SYSROOT}/usr/openssl/3/include"
The installer complains of various uninitialized variables and panics as the script is run with set -u. Related:
LLVM does not like the Solaris headers[1]. There appears to be a workaround in LLVM but it's not being triggered (at least during a cross compile). Manually undefining the registers in the Solaris headers fixed the build for me, but this seems like it should work out of the box. Solved by building sysroot from Solaris packages.
ar and ranlib need to be modern-ish. When using an older ar the static LLVM support libraries are empty and the build fails with a load of undefined references to LLVM symbols. For the x86_64 build I used an LLVM ar from macports via CMAKE_AR and resolved the issue. For the sparc build I used ar and ranlib from GNU binutils 2.40. Setting ar and ranlib in config.toml should fix @3eka's issue with undefined symbols. This is set per-target e.g. target.x86_64-pc-solaris.ar or target.sparcv9-sun-solaris.ar and must be an absolute path.
rust-analyzer does not compile due to nix incorrectly assuming flock exists in Solaris (apparently it hasn't since at least 5.x) [1, 2]. Related:
Manually installing the rust-std-nightly and rustc-nightly tarballs got me an install that successfully compiled a "Hello, world" program with the Oracle provided gcc as the linker.
SPARCv9
Environment
Cross: x86_64-apple-darwin → sparcv9-sun-solaris
Sysroot: see below
Compiler: gcc 11.2.0
binutils: GNU binutils 2.40
rust 1.70.0
Local changes to rust: #114078
Known issues
ar and ranlib need to be modern-ish. See above.
Due to using gcc as the cross compiler(?) I had to explicitly set LLVM_TOOL_LLVM_LIBTOOL_DARWIN_BUILD to OFF in src/bootstrap/llvm.rs because Apple's libtool(1) doesn't seem to know what to do with ELF/SPARC objects. This should probably be part of a larger discussion on whether cross compiling from an Apple → non-Apple target is a worthwhile goal.
llvm-wrapper/PassWrapper.cpp calls llvm::sys::getHostCPUName which on Solaris/SPARC calls into libkstat. libLLVMTargetParser which contains getHostCPUName does not appear to link against libkstat Somewhere along the way we should be linking against libkstat. Related:
Solaris packages contain files for both x86 and SPARC architectures. The following packages should be sufficient to create a usable sysroot for cross compiling:
( please feel free to add whatever labels you think it should have via rustbot label: +label, if you want to potentially bring it to the more attention, I removed needs-triage because it looks like you're just tracking a work in progress, which I don't mind either way. )
@workingjubilee thanks! For the stuff that won't get fixed (e.g. needing to specify ar and ranlib by hand, is there a good place to land some documentation?
I'm not quite sure if this is the right place to track these things, but I've been trying to cross build the native host tools for Solaris (both x86 and SPARC).
x86_64
Environment
Cross:
x86_64-apple-darwin
→x86_64-pc-solaris
Sysroot: see below
Compiler: gcc 11.2.0
binutils: GNU binutils 2.40 + ar LLVM 16 (todo: test with GNU ar)
rust 1.70.0
Local changes to rust: #114078
Known issues
-nodefaultlibs
for reasons that aren't entirely clear to me. To get the build working successfully I had to wrapgcc
andg++
with a small script to ensure thatCFLAGS
/CXXFLAGS
always included--sysroot=${SYSROOT} -L${SYSROOT}/lib/amd64 -L${SYSROOT}/lib -Wl,-rpath-link,${SYSROOT}/lib/amd64
Linking to OpenSSL does not work. Headers seem to be from ≥ 1.1.0, linker finds libraries for 1.0.2. The build is stopped at cargo. Linker errors are all missing symbols (e.g.Solved by building sysroot from Solaris packages. Note: Ensure that the build picks up theOPENSSL_init_ssl
,BIO_meth_new
).pkg-config
info at${SYSROOT}/usr/openssl/3/lib/64/pkgconfig/libssl.pc
or setOPENSSL_LIB_DIR="${SYSROOT}/usr/openssl/3/lib/64"
andOPENSSL_INCLUDE_DIR="${SYSROOT}/usr/openssl/3/include"
set -u
. Related:LLVM does not like the Solaris headers[1]. There appears to be a workaround in LLVM but it's not being triggered (at least during a cross compile). Manually undefining the registers in the Solaris headers fixed the build for me, but this seems like it should work out of the box.Solved by building sysroot from Solaris packages.ar
andranlib
need to be modern-ish. When using an olderar
the static LLVM support libraries are empty and the build fails with a load of undefined references to LLVM symbols. For the x86_64 build I used an LLVMar
from macports viaCMAKE_AR
and resolved the issue. For the sparc build I usedar
andranlib
from GNU binutils 2.40. Settingar
andranlib
inconfig.toml
should fix @3eka's issue with undefined symbols. This is set per-target e.g.target.x86_64-pc-solaris.ar
ortarget.sparcv9-sun-solaris.ar
and must be an absolute path.rust-analyzer
does not compile due tonix
incorrectly assumingflock
exists in Solaris (apparently it hasn't since at least 5.x) [1, 2]. Related:Status
With this in place I can build these artifacts from 1.70.0:
Manually installing the
rust-std-nightly
andrustc-nightly
tarballs got me an install that successfully compiled a "Hello, world" program with the Oracle provided gcc as the linker.SPARCv9
Environment
Cross:
x86_64-apple-darwin
→sparcv9-sun-solaris
Sysroot: see below
Compiler: gcc 11.2.0
binutils: GNU binutils 2.40
rust 1.70.0
Local changes to rust: #114078
Known issues
ar
andranlib
need to be modern-ish. See above.gcc
as the cross compiler(?) I had to explicitly setLLVM_TOOL_LLVM_LIBTOOL_DARWIN_BUILD
toOFF
insrc/bootstrap/llvm.rs
because Apple'slibtool(1)
doesn't seem to know what to do with ELF/SPARC objects. This should probably be part of a larger discussion on whether cross compiling from an Apple → non-Apple target is a worthwhile goal.llvm-wrapper/PassWrapper.cpp
callsllvm::sys::getHostCPUName
which on Solaris/SPARC calls intolibkstat
.libLLVMTargetParser
which containsgetHostCPUName
does not appear to link againstlibkstat
Somewhere along the way we should be linking againstlibkstat
. Related:Status
I can build these artifacts from 1.70.0:
Sysroot
Package information from Oracle is available here:
http://pkg.oracle.com/solaris/release/en/catalog.shtml
Solaris packages contain files for both x86 and SPARC architectures. The following packages should be sufficient to create a usable sysroot for cross compiling:
The text was updated successfully, but these errors were encountered: