☰

이 중 아무것도 할 필요가 없습니다

tag-icon • tag-icon debian curl openssl libraries
이 중 아무것도 할 필요가 없습니다

그래서 나는 debian 9 x64(아마도 잘못된 것일 수 있음)에서 컬을 만들었고 curl -V명령 후에 새 버전을 사용하는 것을 볼 수 있습니다.

OpenSSL/1.1.0f

그 후, 완전히 동일한 라이브러리를 다른 debian 9 인스턴스에 복사하고, 컬 -VI를 실행하여 이전 버전을 사용하고 있음을 확인했습니다.

OpenSSL/1.0.2l

-이유는 무엇입니까?

- 이것은 내가 컬을 잘못 구축했고 실제 openssl 버전이 표시되는 버전이 아니라는 뜻인가요?

- openssl은 정적으로 구축되지 않았으므로 컬 바이너리에 남아 있습니까?

답변1

첫 번째...

이 중 아무것도 할 필요가 없습니다

귀하가 링크한 버그는 Curl에서 수정되었습니다.버전 7.51.0.

  • openssl: 1.0.1 또는 1.0.2를 사용하여 스레드별 메모리 누수 수정

Debian Stretch를 지정하셨습니다.현재 7.52.1을 사용하고 있습니다.. 이전 버전의 OpenSSL이 설치되어 있는지는 중요하지 않습니다. 여전히 최신 Curl이 설치되어 있기 때문입니다.

따라서 시스템이 최신 상태로 유지되는 한(통과 apt) 이미 수정된 것입니다.

동적 또는 정적

이제 원래 질문으로 돌아갑니다.

openssl이 정적으로 빌드되지 않아 컬 바이너리에 남아 있습니까?

습관. 런타임 시 특정 변수를 설정하지 않는 한 ./configure, 결과 실행 파일은 동적으로 연결되며 libcurl.so그 중 하나가 동시에 빌드되어야 합니다.

라이브러리 파일을 두 번째 서버에 복사하지 않는 한로더가 찾을 수 있는 경로에 배치합니다.을 선택하면 설치된 것(아래 /usr/lib/x86_64-linux-gnu/)을 사용하게 됩니다. 당신 readelf -d이 뛰어든다면저것파일을 보면 어떤 버전의 OpenSSL이 연결되어 있는지 확인할 수 있습니다.

 0x0000000000000001 (NEEDED)             Shared library: [libssl.so.1.0.2]

만약 너라면가지다두 번째 서버에서 최신 버전을 사용해 보면 libcurl.so.4다음과 같은 오류가 표시됩니다.

error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

요약하자면, 귀하의 Curl 사본은 설치된 OpenSSL 버전을 사용하고 올바르게 보고하고 있습니다. 메모리 누수의 영향을 받는 유일한 방법은 수정 전에 Curl 버전(즉, 7.51.0 이전 버전)을 수동으로 빌드한 경우입니다.

관련 정보