Date: Wed, 17 Mar 2021 12:51:40 +0000 From: John F Carr <jfc@mit.edu> To: Mark Dixon <freebsd@markdixon.name>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: security/bitwarden_rs on aarch64 Message-ID: <A5C9D481-4DF9-4141-A53B-8D5B59468AE1@exchange.mit.edu> In-Reply-To: <10583814.HWECOB6VNT@markspc> References: <10583814.HWECOB6VNT@markspc>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 17, 2021, at 07:37 , Mark Dixon <freebsd@markdixon.name> wrote:
>=20
> Hi
>=20
> I've got my hands on a Helios64 board and I'm playing around with it runn=
ing=20
> FreeBSD 13 to see what it can run, and I've run into something I do not=20
> understand. I've been trying to compile security/bitwarden_rs to see if I=
can=20
> use it to host my password manager and I've hit an issue:
>=20
> The build, out of the box fails with:
>=20
> error: /usr/ports/security/bitwarden_rs/work/target/release/deps/
> libmigrations_macros-2f2155501ff102fe.so: Undefined symbol "__addtf3"
> --> /usr/ports/security/bitwarden_rs/work/bitwarden_rs-1.19.0/cargo-crat=
es/
> diesel_migrations-1.4.0/src/lib.rs:82:1
> |
> 82 | extern crate migrations_macros;
>=20
> I'm no rust developer, but that looks a lot like a linker error. A quick=
=20
> google suggest that symbol is from libgcc and relates to soft float emula=
tion=20
> which I guess we shouldn't need on aarch64 but I guess if that's what it =
wants=20
> I go with it. Sure enough that .so depends on libgcc:
>=20
> /usr/ports/security/bitwarden_rs/work/target/release/deps/
> libmigrations_macros-2f2155501ff102fe.so:
> libpq.so.5 =3D> /usr/local/lib/libpq.so.5 (0x406d0000)
> libmysqlclient.so.20 =3D> /usr/local/lib/mysql/libmysqlclient.so.20=20
> (0x41c00000)
> libthr.so.3 =3D> /lib/libthr.so.3 (0x40749000)
> libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x407a5000)
>=20
>=20
> /lib/libgcc_so.1 though - I didn't think FreeBSD ships GCC anymore, altho=
ugh=20
> I've been out of the FreeBSD loop for a while.=20
>=20
> Okay, let's look in /usr/src/lib/libgcc_s, seems like it's just some sort=
of=20
> gcc thunking library. Let's try adding __subtf3 to Symbols.map and see wh=
at=20
> happens. Surprisingly, after adding __subtf3, __multf3, __divtf3 and __ad=
dtf3;=20
> (and installing libgcc_s) the bitwarden_rs build now compiles just fine, =
and=20
> seems to run - although I haven't actually done much with it yet.
>=20
> I'm not sure what is going on here because I'm really at the limits of my=
=20
> knowledge. It seems unlikely, but not impossible, that these symbols are =
just=20
> missing from Symbols.map in the base system. How should I proceed to fix =
this=20
> 'properly'?=20
>=20
> Mark
>=20
__addtf3 is a software implementation of add for the "TF" type, 128 bit flo=
ating point, when not implemented in hardware.
The following program compiles for me on FreeBSD 13 on 64 bit ARM using cc =
without having gcc installed. You can look at the assembly or symbol table=
to see it is using __addtf3 (for +) and __netf2 (for !=3D).
long double add(long double x, long double y) { return x + y; }
int main(int argc, char *argv[]) { return add(1.0, 1.0) !=3D 2.0; }
Based on the library dependencies it looks like rust or bitwarden is being =
built with gcc and gcc is not configured as well as cc. Is it possible to =
use clang instead of gcc?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A5C9D481-4DF9-4141-A53B-8D5B59468AE1>