Date: Sun, 18 Feb 2024 03:24:58 +0000 From: bugzilla-noreply@freebsd.org To: gecko@FreeBSD.org Subject: [Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2) Message-ID: <bug-277021-21738-RY8WktWsmi@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-277021-21738@https.bugs.freebsd.org/bugzilla/> References: <bug-277021-21738@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=3D277021 --- Comment #69 from Tomoaki AOKI <junchoon@dec.sakura.ne.jp> --- (In reply to Tatsuki Makino from comment #68) I cannot understand why CPUTYPE causes ceil() and floor() is used or not. Just a possibility, for slow and old CPUTYPEs, firefox has alternative, may= be scale and int'ify then calculate as integer, and fp'fy with scaling again. = If it's correct, this problem can be happen, but really?! Moreover, such a implementation should require guarded inclusion of math.h using CPUTYPE and/or arch. If none, and if math.h is included regardless directly or indirectly, blindly adding -lm option for the module should be fine. Reading /usr/include/math.h, most of mathematic functions are defined= as usual prototype only, including sin(), atan(), ceil() and floor(). As, IIUC, C doesn't have specs to seek for function bodies which are not in #include chain, inline them, and render to instruction which can do it directly. So if there's only prototypes of needed function in the header fi= le included, corresponding library must be linked. --=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-277021-21738-RY8WktWsmi>