Date: Mon, 22 Feb 2021 11:30:13 +0100 From: Olivier Certner <olivier.freebsd@free.fr> To: Kurt Jaeger <pi@freebsd.org>, Gerald Pfeifer <gerald@pfeifer.com> Cc: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r565330 - in head: . www www/palemoon www/palemoon/files Message-ID: <6023468.TRTBLuF5rb@ravel> In-Reply-To: <7595c273-707c-85f-4241-4ed264a257b9@pfeifer.com> References: <202102151919.11FJJMGp064158@repo.freebsd.org> <7595c273-707c-85f-4241-4ed264a257b9@pfeifer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Gerald, Actually, I've already switched to using "9:build" locally, which allowed me to remove the lines after '.include <bsd.port.mk>' (those that remove gcc* from RUN_DEPENDS). This is a progress, but not that big for this specific port at this point. I think it would be great if the ports infrastructure allowed to specify building with GCC, but using libc++'s headers and linking against it, and also removing '-rpath', which is not necessary for a build-only dependency (I wonder if it is still necessary at all for runtime dependencies; might be for architectures that have not switched to clang; -rpath should be eliminated at most costs, but this is another discussion). That would be a much bigger progress, and it can probably fix a bunch of other situations as well (in the past years, I stumbled against a problem with a C++ port that was built with GCC (and thus linked to libstdc++) for which I wanted to build an extension that had to be linked to another C++ library, already built... with clang/libc++; and it didn't work, as expected). This also will open the way for the possibility of (gradually) having all ports containing C++ code and that are built with GCC be linked against libc++ by default (and linking against libstdc++ become the explicit exception) in order to avoid problems with mixing libc++ and libstdc++ problems, both in- and out-tree. As for Pale Moon, I have already done the work, so I would not be the one to really benefit much in the short term. However, I would happily test changes in the infrastructure, and get rid of my Makefile manipulations once there are in place, because I'm positive this is the right way going forward. I even considered building a patch (of bsd.gcc.mk) and submitting it, but I'm having more pressing issues at the moment. If you're interested, I can reconsider it in a few days (but don't wait for me; obviously, you can build upon what I did in Pale Moon's Makefile if you have the will and time). Regards, Olivier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6023468.TRTBLuF5rb>