Sean Farley <sean.michael.far...@gmail.com> writes: > The only problem with using non-system compilers is with C++ because > clang++ is not ABI compatible with g++. You could use gcc just fine if > there was something to enforce the induced dependency graph.
Uh, isn't this libc++ vs libstdc++ rather than clang++ vs g++? Note that merely mixing -std=c++11 code with a single compiler can be a problem. C++ repeatedly chooses language features that make binary compatibility difficult. > Nope, nope, nope, nope. Using multiple package managers, including > the broken python ones is a suggestion that is dead on arrival. I sure > as shit don't want to remember the different commands to search for a > package with multiple managers (Python, Ruby, node, etc.). Plus, it > doesn't solve the issue with packages that depend on other packages not > in its system. I agree with Sean that mixing package managers is a mess. Maybe if I lived in a self-contained Python-only world, but I don't. I want to be able to reliably install (and upgrade, remove, query) a package that depends on any subset of packages. That could mean mixing Python, Haskell, R, and Emacs packages.
signature.asc
Description: PGP signature
