Исполняемый файл Linux выдает ошибку «Файл не найден», несмотря на то, что файл существует и находится в PATH
Чтобы установить glibc 2.14 параллельно, добавьте префикс configure:
tar zxvf glibc-2.14.tar.gz
cd glibc-2.14
mkdir build
cd build
../configure --prefix=/opt/glibc-2.14
make -j4
make install
После этого процесса вы сможете собрать 2.14, но вам потребуется скажите компилятору, где искать glibc.
Ниже приведены способы предоставления glibc вашей программе.
LD_LIBRARY_PATH = / opt / glibc-2.14 / lib
экспорт LD_LIBRARY_PATH.
Библиотека открывается во время вашего текущего сеанса входа в систему.
Вы можете навсегда связать вашу новую версию glibc таким образом, но, пожалуйста, прочтите ПРЕДУПРЕЖДЕНИЕ ниже:
ln -sf /opt/glibc-2.14/glibc-2.14.so /lib/libc.so.6.
Поскольку libc.so.6 - это просто символическая ссылка. Выполнение вышеуказанной команды приведет к тому, что ссылка будет указывать на новую библиотеку glibc. Однако этот шаг не рекомендуется, поскольку в Linux есть много программ, которые зависят от более старых версий и перестанут работать.
Это:
$ file /usr/bin/wine
/usr/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32,
BuildID[sha1]=eaf6de433d8196e746c95d352e0258fe2b65ae24, stripped
В сочетании с этим:
$ ldd /usr/bin/wine
/usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory
Настоятельно указывает на то, что в системе отсутствует интерпретатор /lib/ld-linux.so.2ELF. То есть в этой 64 -битной системе не установлены никакие 32 -битные библиотеки совместимости. Таким образом, ответ @ user1334609 по сути правильный.
Вы пытаетесь запустить 32-битное -приложение в 64-битной операционной системе, поэтому вам необходимо установить 32-битные -библиотеки совместимости (, в частности glibc ), прежде чем это заработает.
К вашему сведению, я столкнулся с той же проблемой в образе докера на базе alpine -. Исполняемый файл был 64 -битным ELF, а образ alpine был 64 -битным, и исполняемый файл работал в другом контейнере. Так что, предположительно, урезанные альпийские библиотеки были несовместимы с моим исполняемым файлом. узловая страница Docker node.js примечания:
The main caveat [to running in the Alpine-based container] is that it does use musl libc instead of glibc and friends, so certain software might run into issues depending on the depth of their libc requirements. However, most software doesn't have an issue with this, so this variant is usually a very safe choice. See this Hacker News comment thread for more discussion of the issues that might arise and some pro/con comparisons of using Alpine-based images.
Мое решение состояло в том, чтобы использовать другой (, например. Образ контейнера )на основе Debian Jessie -.