Date: Fri, 11 Feb 2022 17:37:17 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 251117] [NEW PORT] www/palemoon: Open-source web browser Message-ID: <bug-251117-7788-o3H7bPxLzi@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-251117-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-251117-7788@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=3D251117 --- Comment #72 from Olivier Certner <olivier.freebsd@free.fr> --- Hi Gleb, (In reply to Gleb Popov from comment #64) > BUNDLE_LIBS=3D1 seems to be an unused variable. It's a variable indicating that the ports produces shared libraries that mu= st not actually be shared with other ports. See the porters handbook or Mk/bsd.port.mk. (In reply to Gleb Popov from comment #65) > It is a quite unusual combination when GCC uses libc++, why do we want th= is? I > believe, this is what causes failures when building on CURRENT. On old tests I did, executables produced with clang++ would simply crash at launch. Moreover, upstream does not support clang++ for compilation. So GCC= is needed. On the other hand, linking to libc++ is required (using libstdc++ is fragile at best, because of dependency on 'harfbuzz' =3D> 'graphite2', link= ing to libc++; in practice, this combination crashes). So there is no way out, sho= rt term at least. >Another small problem with the port is that you need > >.include <bsd.port.post.mk> > > at the end of Makefile instead of > > .include <bsd.port.mk> I've changed that in the new patch, although the old stanza seems to work as well. Thanks. --=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-251117-7788-o3H7bPxLzi>