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

I tried switching to 12.0.3-canary.2 but if anything this seems to have made it worse:

> next build

Attention: Next.js now collects completely anonymous telemetry regarding usage.
This information is used to shape Next.js' roadmap and prioritize features.
You can learn more, including how to opt-out if you'd not like to participate in this anonymous program, by visiting the following URL:
https://nextjs.org/telemetry

info  - Checking validity of types...
info  - Creating an optimized production build...
Failed to compile.

./node_modules/next/dist/client/next.js
Error: Failed to deserialize argument at `2` as next_swc::TransformOptions
JSON: {"module":{"type":"commonjs"},"disableNextSsg":true,"isDevelopment":false,"pagesDir":"/usr/src/app/pages","isPageFile":false,"jsc":{"parser":{"syntax":"ecmascript","dynamicImport":true,"jsx":true},"transform":{"react":{"runtime":"automatic","pragma":"React.createElement","pragmaFrag":"React.Fragment","throwIfNamespace":true,"development":false,"useBuiltins":true,"refresh":false},"optimizer":{"simplify":false,"globals":{"typeofs":{"window":"object"}}},"regenerator":{"importPath":"/usr/src/app/node_modules/next/node_modules/regenerator-runtime/runtime.js"}},"target":"es5"},"filename":"/usr/src/app/node_modules/next/dist/client/next.js","sourceMaps":false,"inlineSourcesContent":false,"sourceFileName":"/usr/src/app/node_modules/next/dist/client/next.js"}

Caused by:
    unknown field `regenerator`, expected one of `react`, `constModules`, `optimizer`, `legacyDecorator`, `decoratorMetadata`, `hidden` at line 1 column 760
    at Object.transform (/usr/src/app/node_modules/next/dist/build/swc/index.js:55:21)
    at /usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:113:47
    at Span.traceAsyncFn (/usr/src/app/node_modules/next/dist/trace/trace.js:74:26)
    at Object.loaderTransform (/usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:113:20)
    at /usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:124:49
    at Span.traceAsyncFn (/usr/src/app/node_modules/next/dist/trace/trace.js:74:26)
    at Object.swcLoader (/usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:124:16)

./node_modules/next/dist/client/router.js
Error: Failed to deserialize argument at `2` as next_swc::TransformOptions
JSON: {"module":{"type":"commonjs"},"disableNextSsg":true,"isDevelopment":false,"pagesDir":"/usr/src/app/pages","isPageFile":false,"jsc":{"parser":{"syntax":"ecmascript","dynamicImport":true,"jsx":true},"transform":{"react":{"runtime":"automatic","pragma":"React.createElement","pragmaFrag":"React.Fragment","throwIfNamespace":true,"development":false,"useBuiltins":true,"refresh":false},"optimizer":{"simplify":false,"globals":{"typeofs":{"window":"object"}}},"regenerator":{"importPath":"/usr/src/app/node_modules/next/node_modules/regenerator-runtime/runtime.js"}},"target":"es5"},"filename":"/usr/src/app/node_modules/next/dist/client/router.js","sourceMaps":false,"inlineSourcesContent":false,"sourceFileName":"/usr/src/app/node_modules/next/dist/client/router.js"}

Caused by:
    unknown field `regenerator`, expected one of `react`, `constModules`, `optimizer`, `legacyDecorator`, `decoratorMetadata`, `hidden` at line 1 column 764
    at Object.transform (/usr/src/app/node_modules/next/dist/build/swc/index.js:55:21)
    at /usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:113:47
    at Span.traceAsyncFn (/usr/src/app/node_modules/next/dist/trace/trace.js:74:26)
    at Object.loaderTransform (/usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:113:20)
    at /usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:124:49
    at Span.traceAsyncFn (/usr/src/app/node_modules/next/dist/trace/trace.js:74:26)
    at Object.swcLoader (/usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:124:16)

./node_modules/next/dist/pages/_error.js
Error: Failed to deserialize argument at `2` as next_swc::TransformOptions
JSON: {"module":{"type":"commonjs"},"disableNextSsg":true,"isDevelopment":false,"pagesDir":"/usr/src/app/pages","isPageFile":false,"jsc":{"parser":{"syntax":"ecmascript","dynamicImport":true,"jsx":true},"transform":{"react":{"runtime":"automatic","pragma":"React.createElement","pragmaFrag":"React.Fragment","throwIfNamespace":true,"development":false,"useBuiltins":true,"refresh":false},"optimizer":{"simplify":false,"globals":{"typeofs":{"window":"object"}}},"regenerator":{"importPath":"/usr/src/app/node_modules/next/node_modules/regenerator-runtime/runtime.js"}},"target":"es5"},"filename":"/usr/src/app/node_modules/next/dist/pages/_error.js","sourceMaps":false,"inlineSourcesContent":false,"sourceFileName":"/usr/src/app/node_modules/next/dist/pages/_error.js"}

Caused by:
    unknown field `regenerator`, expected one of `react`, `constModules`, `optimizer`, `legacyDecorator`, `decoratorMetadata`, `hidden` at line 1 column 762
    at Object.transform (/usr/src/app/node_modules/next/dist/build/swc/index.js:55:21)
    at /usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:113:47
    at Span.traceAsyncFn (/usr/src/app/node_modules/next/dist/trace/trace.js:74:26)
    at Object.loaderTransform (/usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:113:20)
    at /usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:124:49
    at Span.traceAsyncFn (/usr/src/app/node_modules/next/dist/trace/trace.js:74:26)
    at Object.swcLoader (/usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:124:16)

./pages/_app.js
Error: Failed to deserialize argument at `2` as next_swc::TransformOptions
JSON: {"disableNextSsg":false,"isDevelopment":false,"pagesDir":"/usr/src/app/pages","isPageFile":true,"jsc":{"parser":{"syntax":"ecmascript","dynamicImport":true,"jsx":true},"transform":{"react":{"runtime":"automatic","pragma":"React.createElement","pragmaFrag":"React.Fragment","throwIfNamespace":true,"development":false,"useBuiltins":true,"refresh":false},"optimizer":{"simplify":false,"globals":{"typeofs":{"window":"object"}}},"regenerator":{"importPath":"/usr/src/app/node_modules/next/node_modules/regenerator-runtime/runtime.js"}},"target":"es5"},"filename":"/usr/src/app/pages/_app.js","sourceMaps":false,"inlineSourcesContent":false,"sourceFileName":"/usr/src/app/pages/_app.js"}

Caused by:
    unknown field `regenerator`, expected one of `react`, `constModules`, `optimizer`, `legacyDecorator`, `decoratorMetadata`, `hidden` at line 1 column 683
    at Object.transform (/usr/src/app/node_modules/next/dist/build/swc/index.js:55:21)
    at /usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:113:47
    at Span.traceAsyncFn (/usr/src/app/node_modules/next/dist/trace/trace.js:74:26)
    at Object.loaderTransform (/usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:113:20)
    at /usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:124:49
    at Span.traceAsyncFn (/usr/src/app/node_modules/next/dist/trace/trace.js:74:26)
    at Object.swcLoader (/usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:124:16)

./pages/index.js
Error: Failed to deserialize argument at `2` as next_swc::TransformOptions
JSON: {"disableNextSsg":false,"isDevelopment":false,"pagesDir":"/usr/src/app/pages","isPageFile":true,"jsc":{"parser":{"syntax":"ecmascript","dynamicImport":true,"jsx":true},"transform":{"react":{"runtime":"automatic","pragma":"React.createElement","pragmaFrag":"React.Fragment","throwIfNamespace":true,"development":false,"useBuiltins":true,"refresh":false},"optimizer":{"simplify":false,"globals":{"typeofs":{"window":"object"}}},"regenerator":{"importPath":"/usr/src/app/node_modules/next/node_modules/regenerator-runtime/runtime.js"}},"target":"es5"},"filename":"/usr/src/app/pages/index.js","sourceMaps":false,"inlineSourcesContent":false,"sourceFileName":"/usr/src/app/pages/index.js"}

Caused by:
    unknown field `regenerator`, expected one of `react`, `constModules`, `optimizer`, `legacyDecorator`, `decoratorMetadata`, `hidden` at line 1 column 685
    at Object.transform (/usr/src/app/node_modules/next/dist/build/swc/index.js:55:21)
    at /usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:113:47
    at Span.traceAsyncFn (/usr/src/app/node_modules/next/dist/trace/trace.js:74:26)
    at Object.loaderTransform (/usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:113:20)
    at /usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:124:49
    at Span.traceAsyncFn (/usr/src/app/node_modules/next/dist/trace/trace.js:74:26)
    at Object.swcLoader (/usr/src/app/node_modules/next/dist/build/webpack/loaders/next-swc-loader.js:124:16)


> Build failed because of webpack errors
The command '/bin/sh -c npm run build' returned a non-zero code: 1

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

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:

Источник

Import error trying to run gRPC on alpine #6126

Hi, I am trying to run a gRPC server inside of a docker container and I am receiving the error:

My docker file is:

I am installing gRPC from PYPI and would not expect any other dependencies?

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

@bbassingthwaite-va Have you tried installing libc6-compat

Adding a comment as found this error via Google and the solution worked for me. Had the same error, slightly different trace — but ultimately resolved by installing the libc6-compat package.

My tracelog for reference:

Closing; the question here seems to be satisfactorily answered.

I feel this has not in fact been satisfactorily answered. This should not be necessary if gRPC would have an official alpine build. The error on the npm module was also very confusing.

I’ll admit I scratched my head when I first encountered this but I don’t put the onus on the gRPC team to create builds for every exotic libc implementation people can conjure up.

Alpine is very forthcoming with the use of musl libc. I think the onus is on us to understand what that means to the code we are trying to run.

In this case it means we need to install a compatibility shim libc6-compat .

Alpine has an excellent tool for getting to the bottom of these issues https://pkgs.alpinelinux.org/contents
(its actually how I initially resolved this issue myself)

For example you can find what, if any, packages may offer the missing ld-linux-x86-64.so.2 file we can use it like so https://pkgs.alpinelinux.org/contents?file=ld-linux-x86-64.so.2&path=&name=&branch=&repo=&arch=

Is the libc6-compat workaround still necessary?

I pip installed grpc, and was able to import grpc without running into the issue described above.

To make sure we didn’t transitively pull in libc6-compat into our alpine docker image, I did
bash-4.3# apk info | grep libc6 and it came back empty.

I agree in general that supporting other libc implementations is not necessarily a good idea, but in this case Alpine is quickly becoming the de facto Docker images base OS.

While I do agree that the fix is easy, understanding why it doesn’t work can be painful as demonstrated by the quantity of issues related to Alpine in this repo (and any other large project that doesn’t support musl).

Also note that I have no idea of the effort required to implement this directly in gRPC. I simply think it should at least be in the roadmap.

@kpayson64 It is possible the entire glibc gets installed? Otherwise maybe an Alpine build does exist and is simply not being used by the npm module?

@rochdev
Can you confirm that you are still seeing this issue with the latest version of gRPC?

Alpine support was added this April, so probably wasn’t there before gRPC 1.4.

Indeed it seems that the @google-cloud/common-grpc npm module depends on ^1.3.1

I will open a PR there. Sorry for reviving this old thread!

Источник

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:

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.

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.

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.

Источник

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

В этой же статье мы рассмотрим что значит ошибка 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, а также как ее решить. В большинстве случаев проблема решается довольно просто и вы получите работоспособную программу. Надеюсь, эта информация была полезной для вас.

Источник

OpenGuru Weblog

Me and My Experiments..

Pages

Sunday, April 12, 2009

How To: Fix shared library load problem in GNU/Linux

I compiled and installed Google testing framework in Linux as per the instructions. But, still I wasn’t able to run the sample applications compiled by me.

Whenever I run them, I used to get following error:
error while loading shared libraries: libgtest.so.0: cannot open shared object file: No such file or directory

But I had installed Google test framework properly. The install script had properly placed the libgtest.so.0 into /usr/local/lib.

To check which all shared libraries failed to load, I issued following command:
ldd a.out

/google_test/samples$ ldd a.out
libgtest.so.0 => not found
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00002b2897d75000)
libm.so.6 => /lib/libm.so.6 (0x00002b2898080000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002b2898301000)
libc.so.6 => /lib/libc.so.6 (0x00002b2898510000)
/lib64/ld-linux-x86-64.so.2 (0x00002b2897b57000)

Which showed that only libraries placed in /usr/local/lib have failed to load. This gave me a hint that /usr/local/lib is not in the LD_LIBRARY_PATH search path.

To confirm this I entered following command which lists all the libraries that ld can load.
ldconfig -p

This confirmed that /usr/local/lib is indeed missing from ld library search path!

So to include /usr/local/lib into the ld library search path I typed following into the terminal.
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/

after this I again ran ldd command
ldd a.out

this time the ld was able to properly find the library gtest.so.0 placed in /usr/local/lib

/google_test/samples$ ldd a.out
libgtest.so.0 => /usr/local/lib/libgtest.so.0 (0x00002ae54f520000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00002ae54f772000)
libm.so.6 => /lib/libm.so.6 (0x00002ae54fa7d000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002ae54fcfe000)
libc.so.6 => /lib/libc.so.6 (0x00002ae54ff0d000)
/lib64/ld-linux-x86-64.so.2 (0x00002ae54f302000)

Now I can run samples without any problems.

Temporary Solution: Temporary solution is to add /usr/local/lib into the environmental variable named LD_LIBRARY_PATH

You can do this by typing
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/

Источник

I want to run a Starbound server on my Raspberry Pi running rasbian.
The server is built to run on an x86 architecture, so my goal is to emulate an x86 architecture to run the server.

Edit: box86 does not run 64-bit x86 binary

To do so, I tried using box86.
It allowed to run a x86 program (steamcmd the program that allowed me to download the server).
But running the server resulted in

bash: ./program: cannot execute binary file: Exec format error

It’s strange because box86 should emulate x86 program when encountered.

I tried using qemu to emulate the server.

sudo apt install qemu-user qemu-system qemu
sudo qemu-x86_64 starbound_server

Resulting in

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

It seems like some dynamic library are missing.
I thought that those libraries would be shipped with qemu, so I tried to use the -L argument to specify a different ld- file.
But it seems like the program only look at the /lib64 folder.
My last try was to create this folder using lib files from an x86 system.
But this results in

ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.

To fix this problem, people suggest to change /etc/ld.so.preload to remove the reference to libarmmem, but this file does not exist on the rasbian system.

I’d like to know if there is a better way to emulate the x86 program?
If there is none, where to find the appropriate libraries to fill the /lib64 folder?

Here are some infos I got with readelf.

machine: Advanced Micro Devices X86-64
type: EXEC
class: ELF64

Shared libraries

[libpthread.so.0]
[libdl.so.2]
librt.so.1]
[libm.so.6]
[libc.so.6]
[ld-linux-x86-64.so.2]

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

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

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:

Источник

executing binary file: file not found

I know there are similar questions out there, but I haven’t found a solution nor this exact case. The binary was built on Arch Linux using its GCC 4.7. The package works fine on the build system. The commands below were executed on:

Linux vbox-ubuntu 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

The file in question is located here. It’s a Linux 64-bit to Windows 64-bit cross-compiler. Untarring it to

/mingw64 directory which contains everything needed.

/mingw64/x86_64-w64-mingw32/bin/as this is what I get:

/mingw64/x86_64-w64-mingw32/bin/as gives me:

/mingw64/x86_64-w64-mingw32/bin/as gives me:

I am truly at a loss. Any help is much appreciated.

The tested other OSes are Fedora 17 (glibc 2.15) and Ubuntu 12.04 (eglibc 2.15). Both zlib and glibc version requirements are met.

|less» and grep for GLIBC, you’ll see that it’s using memcpy from 2.14. I don’t know why the version would vary so much between different library calls.

2 Answers 2

So yeah, it looks like these binaries are looking for a GLIBC_2.14 symbol, which you are presumably missing on your system. As svenx pointed out, it looks like it’s searching for the memcpy@@GLIBC_2.14 symbol. Some more information on why memcpy was given a new version is described in this bug report.

While ldd knew to find it in /lib64 instead, I suppose the kernel doesn’t know that when it tries to run the binary and can’t find the file’s requested interpreter. You could try just running it through the interpreter manually:

Источник

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)

Note: Did not face this problem with single broker.

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

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

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

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?

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

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

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 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?

Источник

«No such file or directory» error when executing a binary

I was installing a binary Linux application on Ubuntu 9.10 x86_64. The app shipped with an old version of gzip (1.2.4), that was compiled for a much older kernel:

I wasn’t able to execute this program. If I tried, this happened:

ldd was similarly unhappy with this binary:

I’m curious: What’s the most likely source of this problem? A corrupted file? Or a binary incompatibility due to being built for a much older ?

8 Answers 8

I was missing the /lib/ld-linux.so.2 file, which is needed to run 32-bit apps. The Ubuntu package that has this file is libc6-i386.

Old question, but hopefully this’ll help someone else.

In my case I was using a toolchain on Ubuntu 12.04 that was built on Ubuntu 10.04 (requires GCC 4.1 to build). As most of the libraries have moved to multiarch dirs, it couldn’t find ld.so. So, make a symlink for it.

Check required path:

If you’re on 32bit, it’ll be i386-linux-gnu and not x86_64-linux-gnu.

You get this error when you try to run a 32-bit build on your 64-bit Linux.

Also contrast what file had to say on the binary you tried (ie: 32-bit) with what you get for your /bin/gzip :

which is what I get on Ubuntu 9.10 for amd64 aka x86_64.

Edit: Your expanded post shows that as the readelf output also reflects a 32-bit build.

I think you’re x86-64 install does not have the i386 runtime linker. The ENOENT is probably due to the OS looking for something like /lib/ld.so.1 or similar. This is typically part of the 32-bit glibc runtime, and while I’m not directly familiar with Ubuntu, I would assume they have some sort of 32-bit compatibility package to install. Fortunately gzip only depends on the C library, so that’s probably all you’ll need to install.

I also had problems because my program interpreter was /lib/ld-linux.so.2 however it was on an embedded device, so I solved the problem by asking gcc to use ls-uClibc instead as follows:

Well another possible cause of this can be simple line break at end of each line and shebang line If you have been coding in windows IDE its possible that windows has added its own line break at the end of each line and when you try to run it on linux the line break cause problems

Not the answer you’re looking for? Browse other questions tagged linux or ask your own question.

Linked

Hot Network Questions

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

site design / logo © 2022 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2022.10.25.40561

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

CentOS 64 bit bad ELF interpreter

I have just installed CentOS 6 64bit version, I’m trying to install a 32-bit application on a 64-bit machine and got this error:

/lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

I’m new to linux. How do I resolve this?

9 Answers 9

You’re on a 64-bit system, and don’t have 32-bit library support installed.

To install (baseline) support for 32-bit executables

(if you don’t use sudo in your setup read note below)

Most desktop Linux systems in the Fedora/Red Hat family:

Possibly some desktop Debian/Ubuntu systems?:

Fedora or newer Red Hat, CentOS:

Even older RHEL, CentOS:

should grab you the (first, main) library you need.

Once you have that, you’ll probably need support libs

Anyone needing to install glibc.i686 or glibc.i386 will probably run into other library dependencies, as well. To identify a package providing an arbitrary library, you can use

if you’re not sure it’s in /usr/bin you can also fall back on

The output will look like this:

Check for missing libraries (e.g. libSM.so.6 in the above output), and for each one you need to find the package that provides it.

Commands to find the package per distribution family

Fedora/Red Hat Enterprise/CentOS:

or, on older RHEL/CentOS:

or, on Debian/Ubuntu:

first, install and download the database for apt-file

(Debian/Ubuntu organise multi-architecture libraries differently.)

Installing packages for missing libraries

The above should give you a package name, e.g.:

Some libraries will have an “epoch” designator before their name; this can be omitted (the curious can read the notes below).

Notes

Warning

Incidentially, the issue you are facing either implies that your RPM (resp. DPkg/DSelect) database is corrupted, or that the application you’re trying to run wasn’t installed through the package manager. If you’re new to Linux, you probably want to avoid using software from sources other than your package manager, whenever possible.

If you don’t use «sudo» in your set-up

About the epoch designator in library names

The “epoch” designator before the name is an artifact of the way that the underlying RPM libraries handle version numbers; e.g.

Updated to clarify and cover the various package manager options more fully (March, 2016)

Источник

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

В этой же статье мы рассмотрим что значит ошибка 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. Если библиотека установлена в другой каталог, то, возможно, это и есть причина проблемы.

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

ldconfig -p

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

 locate librtfreader

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

export LD_LIBRARY_PATH=/opt/kingsoft/wps-office/office6/

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

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/. Но после этого желательно обновить кэш:

sudo ldconfig

Выводы

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