> > > Zhuo Peng <[email protected]> wrote: > > fundamental libraries [5]. Newer GCC versions could be backported to work > > with older libraries [6].
That would be great and it would require a design agreement between major compilers (Gcc, Intel, LLVM and Portland etc). > then you need to use the same toolchain > (or an ABI-compatible toolchain, but I'm afraid there's no clear > specification of ABI compatibility in g++ / libstdc++ land). > A structural deficiency (and flaw) of unix where the sdk is the live system. RH did some work in that providing packages but they guaranteed compatibility across a limited number of versions and only for RH. You know, I wish the scientific communities would stop producing wheels > and instead encourage users to switch to conda. The wheel paradigm is > conceptually antiquated and is really a nuisance to package developers > and maintainers. I cannot agree more and it is not only restricted to the scientific community (I would consider myself working in a hybrid env). Maybe we should embrace it. We could agree on a common "package" format (bin/lib/include/data) between pip and conda to begin with (pretty much like rpm based on cpio instead zip). While there might disagreements on the tooling around (the build and the dependency resolver), at least we can pin on single format and the installer (with bare minimal logic in it). Seminal projects in this space are IMHO: https://build.opensuse.org/ (or the CD/CI system before it became "fashionable") Basically it allows to create a package for each "binary" platform instead a package that rules them all, automatically (embrace it if you cannot beat it) https://github.com/QuantStack/mamba (it's a step in the right direction to split the install part from the dependency resolution) (https://medium.com/@wolfv/making-conda-fast-again-4da4debfb3b7) Please let me know if that something interesting PS> rpm settled on a main package (bin+libs), -develop (for headers+static libraries), -debug to include symbols for debugging
