> > From the requirements side (Martin will correct me if I'm getting these > wrong): > - it seems like from the TF point of view, our users are on pip, so we > need to deliver there > - LLVM is going to require C++14 ~in March as far as I can tell > - from trying to find info about manylinux2010 / 14, it seems like these > have stalled? (but I'm happy to be proven wrong here :) >
Can we start a shared Google Doc to collect all the requirements and constraints? > > >> >> Uwe >> >> Am Di., 5. Feb. 2019 um 12:19 Uhr schrieb Dmitri Gribenko < >> dmit...@google.com>: >> >>> On Mon, Feb 4, 2019 at 12:29 PM Manuel Klimek <kli...@google.com> wrote: >>> >>>> +Dmitri Gribenko <dmit...@google.com> >>>> >>> >>> Thanks for looping me in, Manuel. >>> >>> So I wanted to go back to the requirements and enumerate possible >>> solutions. >>> >>> From soumith's email: >>> 1. CUDA support >>> 2. C++11 support >>> >>> Neither newest CUDA, nor C++11 work on manylinux1 (CentOS 5.11). >>> >>> The original email does not go into detail why CUDA does not work, but I >>> can imagine it is because of the old userspace libraries (libc, libstdc++, >>> libpthread etc). C++11 does not work because of an old libstdc++ and old >>> GCC. >>> >>> *So what can we do about old userspace libraries?* >>> >>> *Option "Userspace-1": Pip package uses libraries installed on the >>> system where the pip package runs.* (AKA the current manylinux >>> approach.) >>> >>> Advantages: >>> - Smaller download size. >>> >>> Disadvantages: >>> - Pip packages have to be built against an old version of userspace >>> libraries to be maximally-compatible. >>> - No nice upgrade path. When we need a specific new feature for >>> something (e.g., today it is modern CUDA and C++11), we have to bump the >>> requirements for the host system. We will always be extremely cautious >>> about not bumping the requirements too much, and therefore we will be >>> always stuck with oldest possible libraries that can do the job. >>> >>> *Option "Userspace-2": When the pip package runs, ignore the system >>> userspace libraries. Use libraries from somewhere else.* >>> >>> Advantages: >>> - We control which versions of userspace libraries we use. We can use >>> libraries that are newer than system ones. >>> - Complete isolation from the userspace of the system where the pip >>> package runs. The only remaining point of contact with the user's system >>> is the kernel. >>> >>> Disadvantages: >>> - We need to figure out where to get these libraries from. >>> - Bigger download size for users. >>> >>> So where do we get the userspace libraries from? >>> >>> *Option "Userspace-2a": Pip community owns all userspace libraries that >>> binaries in a pip package can use.* >>> All userspace components defined by manylinux are packaged into a pip >>> package. TensorFlow/PyTorch/... pip packages declare what version of the >>> userspace pip package they depend on. >>> >>> Advantages: >>> - Pip community owns all userspace components. >>> >>> Disadvantages: >>> - Pip community owns way more stuff than before. >>> >>> *Option "Userpace-2b": Pip takes all userspace libraries from an >>> existing packager.* >>> Same as "Userspace-2a", but instead of owning the build process for the >>> userspace libraries, we take them from an existing packager, for example, >>> Debian, CentOS, Anaconda, Nix package manager, whatever we decide on. >>> >>> Advantages: >>> - Pip community controls userspace components. >>> >>> Disadvantages: >>> - Pip community owns more stuff than before. >>> >>> *What can we do about old toolchain?* >>> >>> *Option "Toolchain-1": Use a toolchain from a certain old distribution, >>> so that the output is maximally-compatible.* >>> This option is compatible with any choice of userspace, as long as the >>> libraries don't require a new compiler or language features. >>> >>> Disadvantages: >>> - Ancient toolchain that does not support modern C++. >>> >>> *Option "Toolchain-2": Make a modern toolchain that produces >>> maximally-compatible output.* >>> This option is difficult to implement, since a modern toolchain using a >>> modern C++ version will require a using a contemporary C++ standard library >>> (libc++ or libstdc++). >>> >>> *Option "Toolchain-3": Make a modern toolchain that requires a modern >>> C++ library.* >>> AKA what Manuel is proposing. Package modern libc++ as a wheel, make a >>> Docker container with the corresponding Clang for building binary packages >>> like Tensorflow. >>> >>> Thoughts? >>> >>> Dmitri >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "SIG Build" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to build+unsubscr...@tensorflow.org. >> Visit this group at >> https://groups.google.com/a/tensorflow.org/group/build/. >> >
