Error loading shared library ld linux x86 64 so 2 no such file or directory

GitLab

• N nso-docker
• Project information
  • Project information
  • Activity
  • Labels
  • Members
• Repository
  • Repository
  • Files
  • Commits
  • Branches
  • Tags
  • Contributors
  • Graph
  • Compare
  • Locked Files
• Issues 50
  • Issues 50
  • List
  • Boards
  • Service Desk
  • Milestones
  • Iterations
  • Requirements
• Merge requests 5
  • Merge requests 5
• CI/CD
  • CI/CD
  • Pipelines
  • Jobs
  • Schedules
  • Test Cases
• Deployments
  • Deployments
  • Environments
  • Releases
• Monitor
  • Monitor
  • Incidents
• Packages & Registries
  • Packages & Registries
  • Package Registry
  • Container Registry
  • Infrastructure Registry
• Analytics
  • Analytics
  • CI/CD
  • Code review
  • Insights
  • Issue
  • Repository
  • Value stream
• Wiki
  • Wiki
• Snippets
  • Snippets
• Activity
• Graph
• Create a new issue
• Jobs
• Commits
• Issue Boards

Collapse sidebar Close sidebar

No such file or directory — lib64/ld-linux-x86-64.so.2

getting this error when attempting to run a base image nso container using the make file. tried this on 5.3.1 and 5.5.1, getting the same problem:

any ideas as to why this may be happening, i copied in the nso installer.bin file, used make to build the image, and then simply tried running it and this is happening.

I installed the coreutils via homebrew on MAC

Источник

Error loading shared library ld-linux-x86-64.so.2 #435

Comments

gokhansari commented Dec 3, 2018

I try to join two stream by using Kafka Streams. While using multiple broker with wurstmeister/kafka, Kafka Stream shutdown itself and does not throw any exception if you do not set UncaughtExceptionHandler handler. I got this one below after setting handler:

java.lang.UnsatisfiedLinkError: /tmp/librocksdbjni7105115125614966504.so: Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /tmp/librocksdbjni7105115125614966504.so)

I made a few research about this and I think It is related with the libc6-compat version of the wurstmeister/kafka base image .

Note: Did not face this problem with single broker.

The text was updated successfully, but these errors were encountered:

sscaling commented Dec 4, 2018

Can you provide some more information? This is the first report of this, which I would have expected to see before now.

What version of kafka-docker are you running? What OS are you running / version of docker ( docker inspect —format ‘<>’ )

We use glibc (libc6-compat is musl). This issue would indicate they are not compatible packages (sgerrand/alpine-pkg-glibc#51)

This seems somewhat related: https://issues.apache.org/jira/browse/KAFKA-4988 (albeit the solution is to use anapsix-java — which is essentially what our base image is: alpine + glibc. They do use oracle JDK rather than openJDK though)

Have you got a small reproducible example application / set of steps, that can be used to debug this further?

Also, have you tried with musl, rather than glibc?

talhaocakci commented Dec 4, 2018

I have the same problem.

kafka-docker version: 2.12_2.1.0
Os version: Ubuntu 16.04.3 LTS (Xenial Xerus)x86_64 x86_64 x86_64 GNU/Linux

sscaling commented Dec 4, 2018

It would be great if someone could provide a minimal example, configuration and steps to reproduce so this can be investigated further.

sscaling commented Dec 5, 2018

As a starting point, here is a simple join of two streams (just concatenate their value into one stream)

I have a docker-compose, such as:

I created the two kafka input topics (letters + numbers) with —partitions 10 —replication-factor 1 so that data is distributed between the two brokers:

I populated input data using kafkacat:

The output stream is generated successfully

This works fine for me. How different is your application? can you get your issue down to the minimum set of steps to reproduce it?

Источник

Ошибка error while loading shared libraries

Новые и опытные пользователи Linux могут сталкиваться с ошибкой error loading shared libraries во время запуска программ, также с ней могут сталкиваться программисты и все желающие компилировать программное обеспечение в своей системе. Эта ошибка в дословном переводе означает что возникла проблема во время загрузки общей библиотеки. О том что такое библиотеки и зачем они нужны вы можете узнать из статьи библиотеки Linux.

В этой же статье мы рассмотрим что значит ошибка error while loading shared libraries более подробно, а главное, как ее решить.

Что означает error while loading shared libraries?

Даже если вы не компилируете свои программы, то вы можете увидеть ошибку error while loading shared libraries: имя_библиотеки: cannot open shared object file: No such file or directory достаточно часто во время установки новых программ не через пакетный менеджер или программ, предназначенных для другого дистрибутива. Как я уже говорил, она возникает потому, что система не может найти библиотеку.

А вот почему ее нельзя найти и загрузить, это уже интересно. Этому может быть несколько причин:

• Библиотека не установлена в системе;
• Библиотека установлена, но неизвестно куда;
• Библиотека установлена правильно, но имеет не ту версию.

При решении проблемы мы будем руководствоваться именно этими причинами и пытаться их решить.

Как исправить ошибку?

1. Библиотека не установлена

Первый вариант, тут все понятно, библиотеки просто нет в системе, поэтому мы и получаем такую ошибку. Верный способ ее решения — просто найти пакет библиотеки с помощью пакетного менеджера и установить ее. Обычно, пакеты с библиотеками называются так же, как и сами библиотеки с префиксом lib.

Например, если нам не хватает библиотеки libfuse2.so, то мы можем найти ее в Ubuntu такой командой:

sudo apt search libfuse2

Затем осталось только установить ее:

sudo apt install libfuse2

Если перед вами стоит задача собрать программу из исходников, то вам понадобится не только установить саму библиотеку, но и заголовочные файлы для нее:

sudo apt install libfuse-dev

И так для любой библиотеки. Но это не всегда помогает.

2. Библиотека находится не в том каталоге

Бывает что библиотека установлена, мы установили ее или она поставлялась вместе с программой, но ошибка как была, так и есть. Причиной этому может быть то, что загрузчик Linux не может найти библиотеку.

Поиск библиотек выполняется по всех папках, которые указаны в конфигурационных файлах /etc/ld.conf.d/. По умолчанию, это такие каталоги, как /usr/lib, /lib, /usr/lib64, /lib64. Если библиотека установлена в другой каталог, то, возможно, это и есть причина проблемы.

Вы можете посмотреть какие библиотеки сейчас доступны загрузчику с помощью команды:

Найти, где находится ваша библиотека можно с помощью команды locate. Например, нас интересует библиотека librtfreader.so:

Теперь мы знаем, что она находится по адресу /opt/kingsoft/wps-office/office6/. А значит, для работы программы необходимо сделать чтобы загрузчик библиотек ее видел. Для этого можно добавить путь в один из файлов /etc/ld.so.conf.d/ или же в переменную LD_LIBRARY_PATH:

Опять же, так вы можете поставить с любой библиотекой, которая взывает ошибку. Еще один более простой метод — это просто создать символическую ссылку на нужную библиотеку в правильной папке:

ln -s /opt/kingsoft/wps-office/office6/librtfreader.so /usr/lib/librtfreader.so

3. Неверная версия библиотеки

Эта причина ошибки довольно часто встречается при использовании программ не для вашего дистрибутива. Каждая библиотека имеет дополнительную версию, так называемую ревизию, которая записывается после расширения .so. Например, libav.so.1. Так вот, номер версии меняется всякий раз, когда в библиотеку вносятся какие-либо исправления.

Часто возникает ситуация, когда в одном дистрибутиве программа собирается с зависимостью от библиотеки, например, libc.so.1, а в другом есть только libc.so.2. Отличия в большинстве случаев здесь небольшие и программа могла бы работать на второй версии библиотеки. Поэтому мы можем просто создать символическую ссылку на нее.

Например, библиотеки libusb-1.0.so.1 нет. Но зато есть libusb-1.0.so.0.1, и мы можем ее использовать:

Для этого просто создаем символическую ссылку на библиотеку:

sudo ln -s /usr/lib/libusb-1.0.so.0.1 /usr/lib/libusb-1.0.so.1

В большинстве случаев программа не заметит подмены и будет работать, как и ожидалось. Также для решения этой проблемы можно попытаться найти нужную версию библиотеки в интернете для своей архитектуры и поместить ее в папку /usr/lib/ или /usr/lib64/. Но после этого желательно обновить кэш:

Выводы

В этой статье мы рассмотрели почему возникает ошибка Error while loading shared libraries, а также как ее решить. В большинстве случаев проблема решается довольно просто и вы получите работоспособную программу. Надеюсь, эта информация была полезной для вас.

Источник

Error loading shared libraries on alpine because of prebuilt(?) #1140

Comments

iCrawl commented Apr 13, 2018 •

I recently decided to upgrade from the master build I was running off this repo which was around 2.0.0-alpha.9 to the latest 2.0.0-alpha.12 just to get greeted with some nice errors on my alpine docker container.

I am aware that I can stay at alpha.9 but it would be in my best interest to keep my software updated, esp when I see commits like [. ] fixed memory leak [. ]

Issue or Feature

Any version above 2.0.0-alpha.9 throws

in Alpine Linux after installing and executing the code.

First thing I tried was adding —build-from-source to yarn install but that obviously didn’t work out as I expected it to.
I assume what’s happening here is that it tries to always use a prebuilt version regardless and that it correlates to this issue afterwards? node-gfx/node-canvas-prebuilt#31

Steps to Reproduce

Just run any Alpine Dockerfile (for reproduce cases node:8-alpine I guess) with those packages.

It will work fine on 2.0.0-alpha.9 but not anything above that (since node-pre-gyp got added) basically.
Is there anyway to go back to the old behavior that alpha.9 used? Since that works perfectly fine.

Your Environment

• Version of node-canvas (e.g. 1.4.0): 2.0.0-alpha.10 — 2.0.0-alpha.12
• Environment (e.g. node 4.2.0 on Mac OS X 10.8): node 8.x.x on Alpine Linux

The text was updated successfully, but these errors were encountered:

chearon commented Apr 13, 2018

I assume what’s happening here is that it tries to always use a prebuilt version regardless and that it correlates to this issue afterwards? node-gfx/node-canvas-prebuilt#31

That’s correct, Alpine doesn’t use glibc , it uses musl , an alternate implementation of libc. I don’t think it will be super hard to add that to the build matrix.

The real issue here is that canvas should be falling back to build, so I need to add a libc option to the binary’s URL path. I’ll do that after I add the musl builds soon.

iCrawl commented Apr 13, 2018

Bless. I appreciate the effort being made.

As a general side-note, and reason why I posted this here and not over at the prebuilt-repo, shouldn’t —build-from-source completely ignore even «trying» to use a prebuilt? Or do I misunderstand how this is intended to be used.

chearon commented Apr 13, 2018

It should not try to use prebuilt with that argument, no. Did you install it like this?

It worked for me. In NPM that argument doesn’t work if it goes before the package name.

Источник

alpine-node docker image and google-cloud equals error loading ld-linux-x86-64.so.2 #8528

Comments

stephenplusplus commented Oct 26, 2016

From @Rich-amoebaWare on October 26, 2016 22:39

• OS:
  Linux 4.4.20-moby (a docker image from mhart/alpine-node:6.9.1
• Node.js version:
  6.9.1 (and back to at least 6.7.0)
• npm version:
  3.10.8
• google-cloud-node version:
  0.43.0

I started using the google-cloud sdk a few weeks ago and was using the mhart/alpine-node image for its «slenderness». When I introduced google-cloud into my code I went to build my docker file using alpine-node to discover the following error:

module.js:597
return process.dlopen(module, path._makeLong(filename));
^

Error: Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /usr/src/node_modules/google-cloud/node_modules/grpc/src/node/extension_binary/grpc_node.node)
at Error (native)
at Object.Module._extensions..node (module.js:597:18)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object. (/usr/src/node_modules/google-cloud/node_modules/grpc/src/node/src/grpc_extension.js:38:15)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)

npm ERR! Linux 4.4.20-moby
npm ERR! argv «/usr/bin/node» «/usr/bin/npm» «run» «test-env»
npm ERR! node v6.9.1
npm ERR! npm v3.10.8
npm ERR! code ELIFECYCLE
npm ERR! enabled@0.4.0 test-env: export NODE_ENV=test&&node index.js
npm ERR! Exit status 1

I switched to using the normal node docker image based on debian and of course I don’t get the error and everything works well.

However, I would like to switch back to alpine-node to get rid of all the weight.

How can I fix this error?

The text was updated successfully, but these errors were encountered:

Источник