Date: Thu, 31 Mar 2022 18:28:59 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 262920] bhyve: "/boot/userboot.so: Undefined symbol "getsecs" Message-ID: <bug-262920-27103-df9hGQYkef@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-262920-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-262920-27103@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262920 Kyle Evans <kevans@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |imp@FreeBSD.org, | |jhb@FreeBSD.org, | |toolchain@FreeBSD.org --- Comment #7 from Kyle Evans <kevans@freebsd.org> --- CC toolchain@, maybe. I suspect the networking bits of libsa were all optim= ized out of userboot before (it can't do network bits), and a toolchain change might've stopped that. I suspect we should just add a bogus getsecs() to userboot that panic()s. I considered a weak getsecs() in libsa, but I think that would hide it from presenting as a compile-time issue in all of the parts of libsa that aren't linked as shared objects. It's not really worth the bhyveload change for something that isn't going to be used to implement it properly. CC imp@ and jhb@ for a second opinion. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-262920-27103-df9hGQYkef>