Re: Can't compile `lilypond-devel`
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. Chris
Re: Can't compile `lilypond-devel`
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? 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. Mojca
Re: Can't compile `lilypond-devel`
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. K
