Can't compile `lilypond-devel`
jonesc at hep.phy.cam.ac.uk
Mon Sep 2 13:44:26 UTC 2019
On 02/09/2019 2:33 pm, Mojca Miklavec wrote:
> On Mon, 2 Sep 2019 at 15:18, Ken Cunningham wrote:
>> It's correct base behavior. Base sees a port compiled against libstdc++ on a system configured to use libc++, and knows this is most often bad, and needs to be fixed. So it flags this as an error.
>> If the portfile author investigates and works out that it's OK for this port to do that (as it doesn't use with any other c++ libraries or provide any for other ports to use) then that "error" can be overridden by forcing the configure.cxx_stdlib in the portfile, and base will stop flagging it.
> I tend to disagree.
> Shouldn't base be able to distinguish between the system libstdc++ and
> the one from gcc shipped by MacPorts?
> Why would the base want to rebuild ports that were built with gcc?
mixing libc++ and libstdc++ is bad, regardless of where libstdc++ comes
from. I don't see any particular reason to distinguish between system or
macports provided ones.
> Also, assume that a port allows compilation with both MacPorts gcc, as
> well as one of the newer clangs. In that case it's impossible to
> hardcode the stdlib. It could also be that a particular port was built
> with gcc based on user (who knows what he's doing) request. Rebuilding
> those ports would be undesired.
In my opinion, in general we should consider *any* port that builds c++
sources using gcc out of the ordinary. Really, we should insist on using
clang unless absolutely necessary, such as where the port in question
only builds with gcc because of non-standard conforming behaviour. In
this case, as gcc is being forced its perfectly reasonable I would say
to indicate the same for configure.cxx_stdlib.
More information about the macports-users