macports-base
macports-base copied to clipboard
macports
Set `configure.cxx_stdlib` on Linux
See: https://trac.macports.org/ticket/48957 See: https://github.com/macports/macports-ports/pull/14323#discussion_r835618657
This also means one less thing is required in @kencu's MacPorts Ubuntu guide:
cxx_stdlib libstdc++ # configure.cxx_stdlib is not yet working on Ubuntu, this fills in appropriate default
libstdc++ was chosen overlibc++ since it is more complete on Linux.
It was intentional to default to not using a -stdlib option at all on non-darwin platforms, because it's only on macOS that being able to use a stdlib other than the system default is important.
Ok, then I guess batch-replace that to add a ${os.platform} eq "darwin" to the conditional in all the ports as originally proposed in https://github.com/macports/macports-ports/pull/14323.
It was intentional to default to not using a -stdlib option at all on non-darwin platforms, because it's only on macOS that being able to use a stdlib other than the system default is important.
Shouldn't a default stdlib still be set on Linux? Since it's always going to be libstdc++, wouldn't it be easier to set that here?
Otherwise, I'm happy to try batch replacing all the statements. 👍
I'm not quite sure what Ryan is getting at, but if there are ports that don't handle an empty cxx_stdlib correctly, they should probably be fixed regardless.
What I'm getting at is what was mentioned in https://github.com/macports/macports-ports/pull/14323: that blocks like
if {[string match *clang* ${configure.cxx}]} {
configure.env-append CXXLIBS=-stdlib=${configure.cxx_stdlib}
}
(or at least blocks with that condition) appear in many ports, so if we're not going to fix base so that is guarantees that ${configure.cxx_stdlib} is set to the right value, then all those ports will need to be changed so those changes happen only on darwin, or perhaps as you suggest only if ${configure.cxx_stdlib} is nonempty.
But -- why not make sure that ${configure.cxx_stdlib} is set to the right value instead of adding workarounds to every usage of this in a Portfile?
On all platforms, clang has the ability to use either libstdc++ or libc++, and for all we know, someone might want to use libc++ somewhere other than Darwin (like FushiaOS, which I believe does default to libc++ https://fuchsia.dev/fuchsia-src/development/build/toolchain).
Just my $0.02.
Empty is a valid value. Portfiles need to be able to handle it either way.
On all platforms, clang has the ability to use either libstdc++ or libc++, and for all we know, someone might want to use libc++ somewhere other than Darwin (like FushiaOS, which I believe does default to libc++)
Using no -stdlib flag and going with the default still works fine in that case. If someone in the increasingly hypothetical and untenable position of wanting MacPorts to work on some non-Darwin platform and use a different C++ stdlib than that platform defaults to, they can set it in macports.conf.
instead of adding workarounds to every usage of this in a Portfile?
Are there many ports looking at this variable? If so, a better question would be why they need to do that. What ncurses does with it is already a workaround and not at all intended to be something that Portfiles routinely have to do.
Are there many ports looking at this variable?
Quite a few.
If so, a better question would be why they need to do that.
It's fairly common for Portfiles to say:
if {[string match *clang* ${configure.cxx}]} {
configure.ldflags-append -stdlib=${configure.cxx_stdlib}
}
This is needed in ports that have C++ code and use $(CXX) as the linker but do not use $(CXXFLAGS) when linking. The alternative would be to patch the Makefiles to use $(CXXFLAGS) when linking but that seems like more work.
Ports that do that must be using the C++ compiler to link, presumably. Does this simpler approach work?
configure.ldflags-append {*}${configure.cxxflags}
I've just patched 70 instances in https://github.com/macports/macports-ports/commit/bf574293e5d62f9007c7201acdda21fc50e318e2 by checking whether stdlib is empty (based on https://github.com/macports/macports-ports/commit/ee5188c0921e48a93c1f2ae10a206941fcc8f4fd).
Given that fixing the issue within the ports is the way forward, I've closed this PR. Thanks all for your help.