tag:blogger.com,1999:blog-2363643920942057324.post2363669552554753329..comments2023-08-09T23:00:54.857+10:00Comments on Graham Dumpleton: Installing a custom Python version into a Docker image.Graham Dumpletonhttp://www.blogger.com/profile/13609779138164842374noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-2363643920942057324.post-4872735237672980422017-02-08T22:13:51.819+11:002017-02-08T22:13:51.819+11:00On the issue of using virtualenv in a Python conta...On the issue of using virtualenv in a Python container, it is actually very important to still use one if using a system Python installation, or one from a package collection such as Red Hat Software Collections for RHEL/CentOS. I have blogged about those issues in http://blog.dscpl.com.au/2016/01/python-virtual-environments-and-docker.html<br /><br />As to always using $ORIGIN, I am just wary ofGraham Dumpletonhttps://www.blogger.com/profile/13609779138164842374noreply@blogger.comtag:blogger.com,1999:blog-2363643920942057324.post-2926270508509865272017-02-08T21:54:09.886+11:002017-02-08T21:54:09.886+11:00I was trying to say that unless there are compelli...I was trying to say that unless there are compelling reasons not to one should by _default_ use $ORIGIN. That this will not probably bring any value while inside Docker container is not that important. Think of it as a good habit similar as using rpath in the first place is also kind of good habit :) It's similar to the question of “why bother with a virtualenv if I’m already in a container”Piotr Dobrogosthttps://www.blogger.com/profile/09529158749729184143noreply@blogger.comtag:blogger.com,1999:blog-2363643920942057324.post-81840821478036102892017-02-08T21:10:52.716+11:002017-02-08T21:10:52.716+11:00@Piotr In the context of a Docker container at lea...@Piotr In the context of a Docker container at least, the need for having the Python installation be relocatable is probably unlikely to arise. :-)Graham Dumpletonhttps://www.blogger.com/profile/13609779138164842374noreply@blogger.comtag:blogger.com,1999:blog-2363643920942057324.post-42824323487787457672017-02-08T20:24:03.964+11:002017-02-08T20:24:03.964+11:00Actually one should probably use $ORIGIN for rpath...Actually one should probably use $ORIGIN for rpath by default so that the compiled Python could be moved to any location afterwards and keep working. The only problem is that this might lead to problems like this one – https://github.com/pypa/virtualenv/issues/1015Piotr Dobrogosthttps://www.blogger.com/profile/09529158749729184143noreply@blogger.comtag:blogger.com,1999:blog-2363643920942057324.post-52113683594555045372015-07-23T09:24:48.829+10:002015-07-23T09:24:48.829+10:00Something like this may well be the catalyst for m...Something like this may well be the catalyst for me using LD_RUN_PATH instead. From memory, when building Python with a shared library it uses an RPATH to the source directory itself using a relative path so it can find the shared library before it is installed. When you use LDFLAGS it may have been adding that for /usr/local/lib before that, so when trying to run the freshly built Python as partGraham Dumpletonhttps://www.blogger.com/profile/13609779138164842374noreply@blogger.comtag:blogger.com,1999:blog-2363643920942057324.post-4930192402484224142015-07-23T00:00:42.965+10:002015-07-23T00:00:42.965+10:00Accidentally when compiling Python 2.7.10 after
./...Accidentally when compiling Python 2.7.10 after<br />./configure --prefix /usr/local --enable-shared LDFLAGS="-Wl,-rpath,/usr/local/lib"<br />I saw that the _io module was not built (*** WARNING: renaming "_io" since importing it failed: build/lib.linux-x86_64-2.7/_io.so: undefined symbol: _PyErr_ReplaceException). Setting LD_RUN_PATH instead of passing LDFLAGS resulted in thePiotr Dobrogosthttps://www.blogger.com/profile/09529158749729184143noreply@blogger.comtag:blogger.com,1999:blog-2363643920942057324.post-80639476362388800652015-07-21T22:41:02.985+10:002015-07-21T22:41:02.985+10:00@Piotr You are quite correct. If I am building my ...@Piotr You are quite correct. If I am building my own on Linux and not bothering with the static linking part and relying only on dynamic libraries, I will always set the environment variable 'LD_RUN_PATH' at compile time with the library directory location. I use the 'LD_RUN_PATH' environment variable rather than use 'LDFLAGS' as I have bad experiences in the distant pastGraham Dumpletonhttps://www.blogger.com/profile/13609779138164842374noreply@blogger.comtag:blogger.com,1999:blog-2363643920942057324.post-34155433034258135802015-07-21T22:23:37.484+10:002015-07-21T22:23:37.484+10:00Very nice post especially as there's no much i...Very nice post especially as there's no much information available on this subject.<br /><br />It might be helpful to set RPATH by passing LDFLAGS="-Wl,-rpath," to configure script so that to prevent loading of wrong dynamic libs when invoking python without LD_LIBRARY_PATH set properly. Otherwise one might be surprised for instance to see system python being run after invoking Piotr Dobrogosthttps://www.blogger.com/profile/09529158749729184143noreply@blogger.comtag:blogger.com,1999:blog-2363643920942057324.post-85079066088022456182015-06-27T02:20:12.832+10:002015-06-27T02:20:12.832+10:00I saw the "--enable-unicode=ucs4" option...I saw the "--enable-unicode=ucs4" option on a docker image a few days ago and thought that seemed unnecessary. Now I know why. Thanks!Collin Andersonhttps://www.blogger.com/profile/06392640823157641725noreply@blogger.com