I think perhaps I am not being clear in what I am proposing. Currently, if cxx_stdlib is equal to libstdc++ then the cxx11PortGroup returns an error and the port does not build. I am simply proposing that instead of returning an error, the port build instead. In other words, the change is meant to respect whatever value cxx_stdlib is.
I am not proposing any changes to anyone’s configuration. I am not proposing any changes to the buildbots. If cxx_stdlib is equal to libc++, the end user would see no changes, not even revbumps. If cxx_stdlib is equal to libstdc++, the only change would be that ports that didn’t build before would suddenly start (hopefully). Please forgive me if I am not understanding the concerns, but this change is meant to affect *only* ports that are currently not building at all for users who have elected to have cxx_stdlib be equal to libstdc++. -Marcus > On Jan 17, 2017, at 8:07 PM, Ken Cunningham <ken.cunningham.web...@gmail.com> > wrote: > > Well, the entire c++ library on the buildbot would have to be rebuilt > against libgcc's libstdc++ for this to work -- all of octave's deps > and deps of deps would need to be built the same as octave, of course, > and so everything else too. The whole machine has to be configured the > same way (which is why intel appears to have funded the libgcc > extensions when some linux distros went with defaulting to libgcc5+, > making clang/llvm non-functional on those distros until they fixed > it). > > In the end, you would seem to wind up in a similar situation as we're > in now with libc++ on these older machines. > > I guess I'm struggling with the benefit of doing this over either > fixing the metadata problem in archives and hosting libc++ files on > the buildbots, or just defaulting to libc++ on these older machines if > we're ready for that.
