Один и тот же двоичный скручиваемый показывает другую версию OpenSSL на 2 разных серверах
В [[ ... ]] правая часть == может быть шаблоном:
for file in /home/directory/* ; do
if [[ $file != *-mask.nii.gz ]] ; then
filename=${file##*/}
mask=${filename%.nii.gz}-mask.nii.gz
echo "$filename" "$mask"
fi
done
Во-первых...
Ничего из этого делать не нужно
Ошибка, на которую вы ссылаетесь, была исправлена в Curl версии 7.51.0 .
- openssl: fix per-thread memory leak using 1.0.1 or 1.0.2
Вы указали Debian Stretch, который в настоящее время использует 7.52.1 . Неважно, что на нем установлена более старая версия OpenSSL --, у вас все еще есть обновленный Curl.
Таким образом, до тех пор, пока эта система поддерживается -до -даты (через apt), в ней уже есть исправление.
Динамический или статический
Теперь о вашем первоначальном вопросе:
Isn't the openssl statically built, and therefore remains inside curl binary?
Нет. Если вы не установили какие-то определенные переменные при запуске ./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 ).