저는 3일 연속 악몽을 꿨어요. 내가 그랬던 것처럼많은나는 Python의 소스 코드를 여러 번(이번에는 2.7.13) 다운로드하고 인터넷에 접속할 수 없는 환경에서 컴파일했습니다(따라서 소프트웨어의 최신 버전을 얻을 수 있는 다른 방법은 없었습니다). 저는 Oracle Linux 7.3(RHEL과 유사한 환경)을 사용하고 있습니다. 기본적으로 Python 2.7.5와 함께 제공되지만 일부 테스트를 수행하고 pip OOTB를 얻으려면 최신 버전이 필요합니다.
나는 일반적인 일을 했다:
# ./configure --enable-shared --with-ensurepip
# make
# make install
요청과 같은 pip를 사용하여 일부 추가 패키지를 설치하려고 시도하기 전까지는 모든 것이 잘 실행되었습니다.
[root@oel7 python_pkgs]# pip install requests-2.11.1/
Traceback (most recent call last):
File "/usr/local/bin/pip", line 7, in <module>
from pip import main
ImportError: No module named pip
흠...그럼 실제로 Python이 어디에 설치되어 있는지 확인해 봤습니다./usr/local/
[root@oel7 ~]# /usr/local/bin/python2.7 --version
Python 2.7.5
그래서 소스 디렉토리에 실제로 무엇이 생성되었는지 확인하기 위해 생성된 바이너리를 설치하지 않고 모든 것을 다시 컴파일해 보았습니다.
[root@oel7 Python-2.7.13]# make distclean
[root@oel7 Python-2.7.13]# ./configure --enable-shared --with-ensurepip
[root@oel7 Python-2.7.13]# ...
[root@oel7 Python-2.7.13]# make
[root@oel7 Python-2.7.13]# ...
[root@oel7 Python-2.7.13]# ./python --version
Python 2.7.5
나는 지금 무엇을 해야할지 모르겠습니다. 생성된 바이너리에 해당 버전이 시스템에 기본적으로 설치된 버전으로 표시되는 이유는 무엇입니까? 나는 또한 성공하지 못한 채 다른 접두사를 사용해 보았습니다.
답변1
난...뭐...어쨌든 이런 일은 Centos 7에서도 발생합니다. Centos 7은 다소 RHEL이고 다소 Oracle Linux입니다. ldd
생성된 바이너리를 실행하면 주목할 가치가 있습니다.
-bash-4.2$ ldd ./python
linux-vdso.so.1 => (0x00007ffdb238e000)
libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007fc691bfe000)
...
어떤 이유로 2.7.13 빌드는 이미 /lib64/libpython2.7*
시스템 전체 라이브러리(버전 2.7.5)를 사용하고 있습니다. --enabled-shared
2.7.13이라는 올바른 버전이 없습니다 .
-bash-4.2$ make distclean
...
-bash-4.2$ ./configure --disable-shared --with-ensurepip && make
...
-bash-4.2$ ldd ./python
linux-vdso.so.1 => (0x00007ffffab95000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f59a15a2000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f59a139e000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f59a119a000)
libm.so.6 => /lib64/libm.so.6 (0x00007f59a0e98000)
libc.so.6 => /lib64/libc.so.6 (0x00007f59a0ad7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f59a17d0000)
-bash-4.2$ ./python --version
Python 2.7.13
-bash-4.2$
이는 README
Python 2.7.13 문서에서 완전히 문서화되지 않았지만, LD_*
Python 빌드 프로세스에서 이 결함을 해결하기 위해 트릭(또는 아래의 ELF 조작 응용 프로그램)을 사용할 수 있습니다. 반품! 가능하다면 기본 버전으로 빌드하지 마십시오. /usr/local
이렇게 하면 빌드 중인 버전이 존재할 수 있는 모든 버전에 혼합됩니다 /usr/local
. 프로그램이 실제로 필요하지만 실제 빌드를 분리하려는 경우 stow
GNU 또는 유사한 절차를 사용할 수 있습니다./usr/local/bin/python
/usr/local/python-2.7.13
-bash-4.2$ make distclean
...
-bash-4.2$ ./configure --enable-shared --with-ensurepip --prefix=/usr/local/python-2.7.13
-bash-4.2$ make && sudo make install
...
글쎄, 이 LD_RUN_PATH
방법에는 두 개의 빌드가 필요합니다. 이제 두 번째 빌드가 필요합니다(첫 번째 빌드는 2.7.13 libpython2.7
라이브러리를 설치하고 다음 빌드는 이를 선택하여 사용합니다)...
-bash-4.2$ make distclean
...
-bash-4.2$ ./configure --enable-shared --with-ensurepip --prefix=/usr/local/python-2.7.13
...
-bash-4.2$ LD_RUN_PATH=/usr/local/python-2.7.13/lib make
...
-bash-4.2$ ldd ./python
linux-vdso.so.1 => (0x00007ffca7bcd000)
libpython2.7.so.1.0 => /usr/local/python-2.7.13/lib/libpython2.7.so.1.0 (0x00007fc6534fb000)
...
-bash-4.2$ sudo make install
...
-bash-4.2$ /usr/local/python-2.7.13/bin/python --version
Python 2.7.13
-bash-4.2$
ELF 수정 도구를 사용하세요. 그 중 하나는 다음과 같습니다.https://github.com/NixOS/patchef이 리포지토리의 파일에서 설치한 후 README
단일 Python 빌드 및 설치를 수행할 수 있습니다.
-bash-4.2$ sudo rm -rf /usr/local/python-2.7.13
-bash-4.2$ ./configure --enable-shared --with-ensurepip --prefix=/usr/local/python-2.7.13
-bash-4.2$ make
-bash-4.2$ patchelf --set-rpath /usr/local/python-2.7.13/lib python
-bash-4.2$ sudo make install
-bash-4.2$ ldd /usr/local/python-2.7.13/bin/python
linux-vdso.so.1 => (0x00007ffeb57ac000)
libpython2.7.so.1.0 => /usr/local/python-2.7.13/lib/libpython2.7.so.1.0 (0x00007fcea6b75000)
...
-bash-4.2$ /usr/local/python-2.7.13/bin/python --version
Python 2.7.13
-bash-4.2$