Error while loading shared libraries libatomic so 1

I am running Ubuntu 15.10 on a 12 year olf DELL laptop and use Firefox 61. With the latest update or if I install Firefox 64 it stops working with the error message
/home/smoehler/firefox/firefox: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

Can I fix this and if so, how?

I am running Ubuntu 15.10 on a 12 year olf DELL laptop and use Firefox 61. With the latest update or if I install Firefox 64 it stops working with the error message
/home/smoehler/firefox/firefox: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

Can I fix this and if so, how?

Выбранное решение

Все ответы (9)

Good question — I did not change consciously to 64-bit but this might be the default. Is there a way to avoid that change but still update firefox? My case seems to be the opposite of the link you mention — as far as I can tell I have a 32-bit operating system but firefox expects 64-bit.

Did you check in Ubuntu software management whether you have the libatomic package (library) installed?

Current Firefox releases are linked to this library.

SabineMoehler said

Good question — I did not change consciously to 64-bit but this might be the default. Is there a way to avoid that change but still update firefox? My case seems to be the opposite of the link you mention — as far as I can tell I have a 32-bit operating system but firefox expects 64-bit.

Are you using the Ubuntu supplied Firefox package or the Firefox tarbal from www.mozilla.org/firefox/all as 32-bit Linux is listed there.

If you use the build from Mozilla just create a Firefox folder in /Home/ and extract the archive in said folder. Then you can create a desktop and or panel shortcut to the firefox script.

Wow — I am feeling a bit (positively) overwhelmed by that much attention to my problem. Let me try to answer:

I do not have libatomic installed and I could not install it with
apt-get —fix-missing install libatomic1

WARNING: The following packages cannot be authenticated!

 libatomic1

Install these packages without verification? [y/N] y
Err http://us.archive.ubuntu.com/ubuntu/ wily/main libatomic1 i386 5.2.1-22ubuntu2

 404  Not Found [IP: 2001:67c:1562::19 80]

E: Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/main/g/gcc-5/libatomic1_5.2.1-22ubuntu2_i386.deb 404 Not Found [IP: 2001:67c:1562::19 80]

E: Internal Error, ordering was unable to handle the media swap


Then I downloaded the 32-bit version of firefox-64 but that gives me the same error cocnerning libatomic. So the crucial point seems really to be that missing library, which apparently was not needed in older version of firefox-61, but which I cannot install (at least not as libatomic1, libatomic-ops-dev.

My apologies if my questions are on an extremely basic level and if I may be missing some point you made.

Выбранное решение

I think that Firefox 63 and later require libatomic.
Maybe try the support website of your distribution to see if they can help you with this.
Otherwise you would have to upgrade to newer Linux version or possibly stay with Firefox 60 ESR to use a Firefox version that is still supported with updates.

• https://www.mozilla.org/en-US/firefox/organizations/all/

Thank you for all the help and information. Now I have at least a clear idea of my options and can decide how to proceed.

I am running Ubuntu 15.10 on a 12 year olf DELL laptop and use Firefox 61. With the latest update or if I install Firefox 64 it stops working with the error message /home/smoehler/firefox/firefox: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

Can I fix this and if so, how?

Chosen solution

I think that Firefox 63 and later require libatomic. Maybe try the support website of your distribution to see if they can help you with this. Otherwise you would have to upgrade to newer Linux version or possibly stay with Firefox 60 ESR to use a Firefox version that is still supported with updates.

From 61 to 64 did you update to the 64bit version of Firefox?

Good question — I did not change consciously to 64-bit but this might be the default. Is there a way to avoid that change but still update firefox? My case seems to be the opposite of the link you mention — as far as I can tell I have a 32-bit operating system but firefox expects 64-bit.

Did you check in Ubuntu software management whether you have the libatomic package (library) installed?

Current Firefox releases are linked to this library.

Corel makes a very good point and I think you found the issue. Since the library is a missmatch on 32/64 library type, you need the 64 bit version of libaio (I am not an expert on how to do that with Ububutu 32) or you find the 32 bit version of Firefox for your operating system. I am not sure if that is available?

Did you use this to install all the Firefox packages? https://help.ubuntu.com/community/FirefoxNewVersion

Good question — I did not change consciously to 64-bit but this might be the default. Is there a way to avoid that change but still update firefox? My case seems to be the opposite of the link you mention — as far as I can tell I have a 32-bit operating system but firefox expects 64-bit.

Are you using the Ubuntu supplied Firefox package or the Firefox tarbal from www.mozilla.org/firefox/all as 32-bit Linux is listed there.

If you use the build from Mozilla just create a Firefox folder in /Home/ and extract the archive in said folder. Then you can create a desktop and or panel shortcut to the firefox script.

Good question — I did not change consciously to 64-bit but this might be the default. Is there a way to avoid that change but still update firefox? My case seems to be the opposite of the link you mention — as far as I can tell I have a 32-bit operating system but firefox expects 64-bit.

Wow — I am feeling a bit (positively) overwhelmed by that much attention to my problem. Let me try to answer:

I do not have libatomic installed and I could not install it with apt-get —fix-missing install libatomic1 WARNING: The following packages cannot be authenticated!

Install these packages without verification? [y/N] y Err http://us.archive.ubuntu.com/ubuntu/ wily/main libatomic1 i386 5.2.1-22ubuntu2

E: Internal Error, ordering was unable to handle the media swap Then I downloaded the 32-bit version of firefox-64 but that gives me the same error cocnerning libatomic. So the crucial point seems really to be that missing library, which apparently was not needed in older version of firefox-61, but which I cannot install (at least not as libatomic1, libatomic-ops-dev.

My apologies if my questions are on an extremely basic level and if I may be missing some point you made.

Источник

Многие пользователи Linux рано или поздно сталкиваются с ошибкой error while loading shared libraries. Как правило, при установке программ вручную. Сегодня поговорим об исправлении данной ошибки. Для примера возьмём старый ноутбук с Ubuntu 14.04 LTS, поддержка которой недавно закончилась, а значит что-то приходится доустанавливать вручную.

Ошибка error while loading shared libraries означает, что программа, которую пользователь пытается запустить, не смогла найти необходимую для своего запуска библиотеку. Такое часто случается, если программа устанавливалась не из репозиториев, а вручную. Например, на скриншоте ниже мы видим, что свежая версия Mozilla Firefox требует для своей работы библиотеку libatomic.so.1, но не может её обнаружить.

При этом, кстати, совершенно не обязательно, что данная библиотека отсутствует в системе. Поэтому сперва выполним поиск библиотеки (подробнее о locate в статье по этой ссылке):

Естественно, в Вашем случае библиотека может называться иначе. Смотрите, что упоминается в тексте ошибки.

Если команда ничего не выдаст, это значит, что библиотеки в системе нет (а вот если библиотека найдена, тогда об этом ниже).

Поищем библиотеку в репозиториях:

В результате мы получим перечень пакетов, которые в названии содержат libatomic:

В моем случае речь идёт о стареньком ноутбуке с 32-битной системой, поэтому мой выбор пал на libatomic1. Если Вы собираете программу из исходников, то будет полезным поставить не только библиотеку, но и заголовочные файлы с приставкой -dev. Сама установка проста:

В результате — актуальная версия Firefox в уже не поддерживаемой разработчиками Ubuntu (подробнее об установке новых версий Firefox в старых релизах Ubuntu в статье по ссылке).

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

Теперь о том, что делать, если библиотека есть в системе, но ошибка error while loading shared libraries всё равно появляется. Очень часто причиной этого является то, что загрузчик ОС не может найти библиотеку. По умолчанию поиск производится в каталогах: /usr/lib, /lib, /usr/lib64, /lib64. Не исключено, что библиотека просто лежит за пределами этих каталогов.

Вариантов тут несколько: переместить или скопировать библиотеку, ну или же указать загрузчику, где её искать. Последний способ более корректный, так как при нём Вы точно ничего не напортачите в системе.

Можно зайти в папку /etc/ld.so.conf.d/, открыть там любой конфигурационный файл и просто прописать местонахождение нужной библиотеки.

А можно сделать символьную (символическую) ссылку:

ln -s [путь_к_библиотеке/имя_библиотеки] /usr/lib/[имя_библиотеки]

Есть ещё одна причина ошибки while loading shared libraries даже когда нужна библиотека имеется в операционной системе. Библиотека может быть не той версии.

Версия библиотеки (или ещё её называют ревизией) пишется после расширения .so. В нашем примере нам требовалась библиотека libatomic.so.1, т.е. libatomic первой версии.

В разных дистрибутивах используются разные версии библиотек, а программы собираются под дистрибутив (и, как следствие, библиотеку конкретной версии). На практике же различия между версиями библиотек чаще всего минимальны. Поэтому для начала можно выдать библиотеку одной версии за библиотеку другой версии. В этом нам опять поможет символьная ссылка:

ln -s [путь_к_библиотеке/настоящее_имя_библиотеки] [путь_к_библиотеке/имя_библиотеки_с_нужной_версией]

Если этот способ не помог, то выход один — искать библиотеку нужной версии.

И последнее: после манипуляций с библиотеками желательно обновить кэш командой

Вот, пожалуй, и всё, что нужно знать про ошибку error while loading shared libraries.

Источник

I am running Ubuntu 15.10 on a 12 year olf DELL laptop and use Firefox 61. With the latest update or if I install Firefox 64 it stops working with the error message /home/smoehler/firefox/firefox: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

Can I fix this and if so, how?

Выбранное решение

I think that Firefox 63 and later require libatomic. Maybe try the support website of your distribution to see if they can help you with this. Otherwise you would have to upgrade to newer Linux version or possibly stay with Firefox 60 ESR to use a Firefox version that is still supported with updates.

Все ответы (9)

From 61 to 64 did you update to the 64bit version of Firefox?

Good question — I did not change consciously to 64-bit but this might be the default. Is there a way to avoid that change but still update firefox? My case seems to be the opposite of the link you mention — as far as I can tell I have a 32-bit operating system but firefox expects 64-bit.

Did you check in Ubuntu software management whether you have the libatomic package (library) installed?

Current Firefox releases are linked to this library.

Corel makes a very good point and I think you found the issue. Since the library is a missmatch on 32/64 library type, you need the 64 bit version of libaio (I am not an expert on how to do that with Ububutu 32) or you find the 32 bit version of Firefox for your operating system. I am not sure if that is available?

Did you use this to install all the Firefox packages? https://help.ubuntu.com/community/FirefoxNewVersion

Good question — I did not change consciously to 64-bit but this might be the default. Is there a way to avoid that change but still update firefox? My case seems to be the opposite of the link you mention — as far as I can tell I have a 32-bit operating system but firefox expects 64-bit.

Are you using the Ubuntu supplied Firefox package or the Firefox tarbal from www.mozilla.org/firefox/all as 32-bit Linux is listed there.

If you use the build from Mozilla just create a Firefox folder in /Home/ and extract the archive in said folder. Then you can create a desktop and or panel shortcut to the firefox script.

Good question — I did not change consciously to 64-bit but this might be the default. Is there a way to avoid that change but still update firefox? My case seems to be the opposite of the link you mention — as far as I can tell I have a 32-bit operating system but firefox expects 64-bit.

Wow — I am feeling a bit (positively) overwhelmed by that much attention to my problem. Let me try to answer:

I do not have libatomic installed and I could not install it with apt-get —fix-missing install libatomic1 WARNING: The following packages cannot be authenticated!

Install these packages without verification? [y/N] y Err http://us.archive.ubuntu.com/ubuntu/ wily/main libatomic1 i386 5.2.1-22ubuntu2

E: Internal Error, ordering was unable to handle the media swap Then I downloaded the 32-bit version of firefox-64 but that gives me the same error cocnerning libatomic. So the crucial point seems really to be that missing library, which apparently was not needed in older version of firefox-61, but which I cannot install (at least not as libatomic1, libatomic-ops-dev.

My apologies if my questions are on an extremely basic level and if I may be missing some point you made.

Источник

I don’t think this a bug with caxa (it depends on one’s point of view!), yet I think it is an issue that caxa users will come across. For one, I am still looking for a convenient solution (that didn’t require me to compile Node.js from source).

I have created a caxa-based executable for my app, for ARM v7. Then, when trying to run it in a Docker container for the ARM platform, I got the following error regarding a missing shared library:

I believe that the problem is that, when creating the caxa executable, I was using a standard Node.js installation that uses shared / dynamically linked libraries. Then caxa bundled in the base Node.js executable, but not the shared libraries. For the libatomic.so.1 library in particular, the error above can be avoided if the end users of my app install the library before running the caxa-based executable:

However, at least my use case for caxa is to simplify end users’ life by avoiding pre-requisites like installing Node.js (#20), «just download this executable and run it», and if I had to ask end users to install shared libraries before running the caxa executable, it would spoil the experience.

I assume that the solution is to use a fully statically compiled version of Node.js (including libatomic.so.1 ) when creating the caxa executable. Where to find that though? For all architectures supported by caxa: x64, ARM v6, ARM v7, ARM 64. I gather that the standard Node.js builds offered for download are dynamically linked: https://nodejs.org/en/download/

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

Hmmm, that’s an interesting predicament.

1. Where did you get the Node.js you’re using to run caxa?
2. Did you try the Docker images we’re using in our tests (or some other similar images)?
3. Do you think caxa could/should embed these dynamic libraries in the binary?

Thanks for looking into this issue @leafac 👍

I was able to reproduce the error with the arm32v7/node:16 image you’ve suggested. Here are the «steps to reproduce», generating a trivial caxa executable that prints «howdy»:

Produce a test-caxa executable for ARM:

Then execute test-caxa on debian:10 :

Note how executing ./test-caxa succeeds in the arm32v7/node:16 image because it already contains the shared libraries (a fully functional installation of Node.js), while it fails in the debian:10 image until/unless the libatomic1 library is installed.

Do you think caxa could/should embed these dynamic libraries in the binary?

If it worked, perhaps! We would not want to interfere with the shared libraries of the target / destination system (e.g. different versions of the shared library), which means that the shared libraries would have to be located in a different folder than the standard, and perhaps env vars used to tell the embedded Node.js executable to look for the libraries in the alternative location.

It sounds to me like it would be cleaner to embed a fully statically compiled Node.js binary in the caxa executable (assuming it would work and avoid the libatomic error), but we’d have to find that somewhere, or create it and then keep it somewhat up to date with Node.js releases upstream. This extra work would arguably be a dent on caxa’s advantage over pkg — no recompiling Node.js from source — although a non-patched recompiled Node.js would still be better than pkg ‘s patched Node.js. I also wonder how much the Node.js binary would increase in size when fully statically compiled.

@maxb2: Did you run into this issue with the Raspberry Pi builds of Dungeon Revealer? How did you fix it?

If we can’t find a pre-compiled statically linked Node.js for ARM, then I guess the solution would be to come up with one ourselves. I believe that’s outside the scope of caxa as caxa’s job is just to package the Node.js you brought to the party. But we could take on such a project. We could use Docker to emulate ARM, use GitHub Actions to run the tasks, and GitHub Releases to distribute. Pretty much the infrastructure we have to compile the stubs. The only part we’d have to figure out is the incantations necessary to statically compile Node.js. Also, the builds will take forever. But it sounds doable…

@maxb2: Did you run into this issue with the Raspberry Pi builds of Dungeon Revealer? How did you fix it?

I did occasionally run into this on the raspi at runtime. I just installed libatomic the same as @pdcastro. It really just depends on the distro and what the user has already installed.

It’s not ideal, but we are talking about Linux users. They probably are fine with installing an extra library. I’m guessing that libatomic is left out of «slim» images.

The only part we’d have to figure out is the incantations necessary to statically compile Node.js.

Also, the builds will take forever.

Actions have a time limit unfortunately. Emulating arm will also make it take even longer.

Job execution time — Each job in a workflow can run for up to 6 hours of execution time. If a job reaches this limit, the job is terminated and fails to complete.

I’m going to time how long it takes to statically compile node for armv7 on my desktop. I’ll check back in when it is done.

Thanks for the information!

On my laptop it took around 2 hours to compile Node.js. I suppose that we’d stay under the 6-hour time limit if we were to compile using ARM on GitHub Actions. Worst-case scenario I guess we could run it on one of our machines…

I just hope that it’s as simple as that Stack Overflow answer seems to indicate. With these things the devil is always in the details…

Are y’all interested in taking over this project? I probably won’t have the opportunity to work on this in the near future…

I tried both emulated and cross-compiling for a static arm build of node. I kept running into new issues. It turned into whack-a-mole. I also don’t have time to work on this in the near future.

Yeah, that’s how I thought it’d turn out.

I’ll keep the issue open for when someone steps up.

I kept running into new issues. It turned into whack-a-mole.

After whacking enough moles and waiting enough hours, 🙂 I can share some early, encouraging results.

With very similar Dockerfiles as the one from StackOverflow (linked in an earlier comment), I’ve got static builds of Node.js v12 (a version I wanted to use) and also «accidentally» the very latest Node.js v17.0.0-pre:

Dockerfile for Node.js v12

Note that the two Dockerfiles use different versions of Python and checkout different branches of Node.js. They were built with Docker v20.10.7, a command line similar to:

In both cases, an ARM node binary was produced that avoided the libatomic.so.1 error:

Above, the Node.js binary that produced the libatomic.so.1 error was the dynamically linked Node.js binary copied from the «official» arm32v7/node:12 image.

Note also the file sizes in the ls -l output above. The statically compiled Node.js v12 binary is just over

3MB larger than the dynamically linked one. I am OK with that. I have not compared the dynamic vs static size difference for other versions of Node.js yet.

I haven’t yet tested using the statically compiled Node.js versions with caxa , but the results above are encouraging. 🙂

make -j4 , instead of just make , specifies 4 compilation jobs in parallel, significantly reducing the overall compilation time if you have at least that many CPU cores. I’ve found a suggestion for make -j$(nproc) , where nproc returns the number of CPU cores in the machine. Note that it will also cause the machine’s cooling fan to run at maximum speed, and if it is anything like mine, passers-by may confuse it with a jet engine. ✈️

Using debian (or anything other than alpine ?) as the Dockerfile base image for compiling Node.js statically appears to be a bad idea, because debian uses glibc and the compilation will produce warning messages such as:

That sounds like users would not only have to install shared libraries, but also match the version used during Node.js compilation. If so, it would be much worse than a dynamically linked Node.js binary! Googling it, I found this other Node.js issue and comment:

nodejs/help#1863 (comment)
[. ] static linking to glibc doesn’t work in general, google around for reasons. You need to link to a libc like musl if you want to use —fully-static .

Well that’s good to know! alpine uses musl , so alpine sounds like the way to go.

@pdcastro, I adapted what you’ve done so far at maxb2/static-node-binaries. I’ve compiled v12, v14, and v16 on my local machine and created releases with the binaries. I’ve also pushed the final docker images to dockerhub

I doubt that we’ll be able to compile these on Github Actions due to the usage limits.

Github Hosted Runner

Hardware specification for Windows and Linux virtual machines:

• 2-core CPU
• 7 GB of RAM memory
• 14 GB of SSD disk space

Hardware specification for macOS virtual machines:

• 3-core CPU
• 14 GB of RAM memory
• 14 GB of SSD disk space

Usage Limits

Job execution time — Each job in a workflow can run for up to 6 hours of execution time. If a job reaches this limit, the job is terminated and fails to complete.

Workflow run time — Each workflow run is limited to 72 hours. If a workflow run reaches this limit, the workflow run is cancelled.

API requests — You can execute up to 1000 API requests in an hour across all actions within a repository. If exceeded, additional API calls will fail, which might cause jobs to fail.

Concurrent jobs — The number of concurrent jobs you can run in your account depends on your GitHub plan, as indicated in the following table. If exceeded, any additional jobs are queued.

It may be possible to set up a self-hosted runner to do the compilation, however it also has limitations:

Self-hosted Runner Limits

• Workflow run time — Each workflow run is limited to 72 hours. If a workflow run reaches this limit, the workflow run is cancelled.
• Job queue time — Each job for self-hosted runners can be queued for a maximum of 24 hours. If a self-hosted runner does not start executing the job within this limit, the job is terminated and fails to complete.
• API requests — You can execute up to 1000 API requests in an hour across all actions within a repository. If exceeded, additional API calls will fail, which might cause jobs to fail.
• Job matrix — A job matrix can generate a maximum of 256 jobs per workflow run. This limit also applies to self-hosted runners.
• Workflow run queue — No more than 100 workflow runs can be queued in a 10 second interval per repository. If a workflow run reaches this limit, the workflow run is terminated and fails to complete.

Someone would have to volunteer some hardware for that though.

I do have a crazy idea to get around the job time limit. We could use timeout to compile as much as possible in

5.8 hours and then pass the directory along to the next job and so on until it finishes. It would require a bit of juggling to make it work with docker as well.

We could use timeout to compile as much as possible in

5.8 hours and then pass the directory along to the next job and so on until it finishes.

That’s clever! Related to this idea:

If passing directories along between jobs was not doable, each job could publish a partially built Docker image to DockerHub (I assume it’s possible to automate this), say with suffixes -partial-1 , -partial-2 and so on, then a final job could use a multistage Dockerfile that pulls the partially built images together and runs a final make .

Possibly an alternative (not necessarily better!) to the timeout command, each job could compile a number of folders (say half or a quarter) from these:

But the timeout idea and passing directories along sounds simpler. 👍

each job could publish a partially built Docker image

I think I like this better. It would go something like:

I also need to figure out some stopping logic.

Possibly an alternative (not necessarily better!) to the timeout command, each job could compile a number of folders (say half or a quarter) from these:

We’d have to do that manually or specify the make targets. I’d rather not do that.

Granted, this is assuming that the make process can safely resume from a SIGTERM . It should be able to, but there’s no guarantee with these huge, complicated projects.

Y’all are doing some awesome work here. I love the hack to work around GitHub Actions time limits. You’re really pushing the envelope what the tool’s supposed to do.

A few questions:

Did you look into other CI services that may have more generous time limits for open-source?

May I advertise these static binaries on caxa’s README?

May I advertise these static binaries on caxa’s README?

Did you look into other CI services that may have more generous time limits for open-source?

Briefly. It’s surprisingly difficult to find the time limits for each service.

• Github Actions is 6 hours per job.
• Azure Pipelines is 6 hours per job.
• Travis CI is 50 minutes per job
• Gitlab is 3 hours per project on shared runners. Gitlab offers 50k CI minutes monthly for qualifying open source projects.
• CircleCI is 5 hours per job. CircleCI offers 400k credits monthly for qualifying open source projects.

Gitlab and CircleCI might work if there are no individual job timeouts (I can’t find it anywhere), but you have to apply for those programs. I may try them in the future when I have time to apply and learn a new CI system.

Breaking the compilation into chunks may be the only option without costing money. Might as well keep it on Github then.

I haven’t yet tested using the statically compiled Node.js versions with caxa , but the results above are encouraging. 🙂

Quoting myself, I often say, «if it’s not tested, it’s broken,» and so it is:
maxb2/static-node-binaries#6

(The statically compiled Node.js binaries for armv7, using the Dockerfiles proposed earlier in this issue, fail to execute caxa .)

A new chapter in this saga. @maxb2 managed to fix the openssl issue on ARMv7 (maxb2/static-node-binaries#6), 🎉 and I went on to test it further. Caxa’s code executes all right with the statically compiled Node.js, and my app (experimentally, the balena CLI) gets extracted all right. But when I run certain balena CLI commands, I get: 💥

This error happens on Intel / amd64 as well, not just on ARM. What happens, I gather, is that native node modules cannot be dynamically loaded when Node.js is compiled statically. Native node modules are files with the .node extension, compiled during npm install and saved under the node_modules folder. Searching the web, I see that this issue also affects pkg when the linuxstatic «platform» is selected: vercel/pkg-fetch#205

Talking of pkg , their asset release v3.2 (current latest) includes Node.js binaries for ARMv7, but only statically compiled and unable to load native node modules. And just a week ago they wrote this comment:

vercel/pkg-fetch#205 (comment)
Be aware that armv7 platform is supported on the best effort basis. There is only linuxstatic executable, and no further action would be taken.

ARMv7 is important for the balena CLI, so pkg ‘s attitude is not encouraging.

I assume, but I don’t know for sure, that it is not possible to enable the feature of dynamically loading native node modules when Node.js is compiled statically. In this case, the approach of using a statically compiled Node.js binary is fundamentally flawed for apps that make use of native node modules, like the balena CLI.

To me, it now sounds like going back to square one:

Do you think caxa could/should embed these dynamic libraries in the binary?

This approach could have complications: The libraries are definitely different between Debian and Alpine. And even if we discarded Alpine and considered only glibc-based distros like Debian and Ubuntu, I wonder if we would have to match the version of glibc (?), or some other library, installed in the system. It might possible, we’d have to investigate.

I’ve just had a related idea. Instead of bundling the libraries, caxa’s Go stub could offer to install them, e.g. automatically executing apt-get install -y libatomic1 with the user’s consent (configurable), if it detected that it was missing. If we made a list of shared libraries that are required to run Node.js (like libatomic1 ) in popular distros — regardless of the payload app — then it could be argued that the Go stub has a duty to install them if they are missing, as a bootstrapper for Node.js. And then caxa could also accept a configurable list of extra shared libraries that are needed by the payload app.

Also: If we found that libatomic1 is the only library that needs to be installed, then another solution might be to «fix» that open Node.js issue that Matthew linked, nodejs/node/issues/37219.

Thank y’all for the amazing investigative work. I’m learning so much from you!

It’s too bad that statically linked Node can’t load native modules…

But I’m sure we’ll come up with something that works!

I like the idea of using the dynamically linked Node and just installing the missing dependencies as a courtesy to the user. But I propose that we don’t do it in the stub. I believe the stubs should be as simple as possible. First because I’m trying to avoid writing Go 😛 But also we have multiple packaging strategies: the all-popular Go stub, the macOS application bundle (.app) (which probably wouldn’t be affected by this change we’re discussing here), and the brand-new Shell Stub. The simpler the stubs, the easier it’s to keep them all in sync.

Here’s what I propose instead: Running Node happens after the extraction, at which point we could run a shell script that prompts the user to install the missing libraries. The beauty of this solution is that it’s all in user-land from caxa’s perspective—you can get it working today. The downside is that it relies on whatever shell there is on the user’s machine, but for something as simple as what we need, probably the lowest common denominator, sh, will suffice. Think of it as an addendum to the Shell Stub.

Of course, once we get something working we can include such script in caxa as a courtesy to the packagers.

I agree that a post-extraction shell script is the right way to go. Would caxa maintain install scripts for the various OSes, or would that be on the packager? These libraries are inconsistently named sometimes.

I’m happy to host and distribute some scripts with caxa for the packager’s convenience, but ultimately it’s their responsibility to make sure the scripts work for them—the scripts become part of their application.

Nice ideas. 👍 Just adding / emphasising that there are still alternatives to be explored further:

• In ./configure —fully-static —enable-static , what exactly is «fully-static» doing? Could the configure script, or other code / script, be slightly amended to allow native node modules to be loaded?
• Is libatomic.so.1 the only library that needs to be installed and, if so, could it be avoided by «fixing» Node.js? As discussed in issue

Note also that, in a fresh environment like docker run -it debian:10 , one needs to run apt-get update before running apt-get install and, from past experience, apt-get update is a point of failure because of server-side / network errors, or when the base image is very old and the distro discontinues the repositories. And even in normal conditions, it can be a bit slow. For these reasons, I still see advantages in static Node.js binaries that were made to work with native node modules, if it was feasible.

Of course we can also have multiple solutions: the convenience shell script that detects missing shared libraries (*) and installs them, which could work «today», and static Node.js binaries if/when we find a solution to make them work with native node modules, or for apps that don’t use native node modules.

(*) Detecting whether shared libraries are missing before attempting apt-get update && apt-get install would improve performance and reliability in cases where the libraries are already installed, which might be the most common scenario for caxa users (?).

Of course, I believe that fixing this issue closer to the source would be ideal. Either by addressing nodejs/node#37219 or by finding the right combination of options for compilation.

Meanwhile, the workaround script we’ve been talking about doesn’t necessarily have to apt-get update && apt-get install . I don’t like that idea because what if you put your caxa application into an SD card and then plug it into a Raspberry Pi that is disconnected from the internet? I believe we could just pack our own libatomic in the caxa binary. The script would then copy it to the right location if necessary.

I believe we could just pack our own libatomic in the caxa binary. The script would then copy it to the right location if necessary.

How distro-specific is libatomic , its versions and installation folder? For example, on Debian 10, apt-get install libatomic1 installs these files and soft links:

So that’s a certain version of libatomic1 (1.2.0), installed on a certain folder ( /usr/lib/x86_64-linux-gnu/ ), as determined by apt-get install for a certain version of Debian. What if other distros, or other versions of Debian, required different versions of libatomic for compatibility with other packages, say gcc ? We could find out, and maybe we are lucky and we could find that «all relevant distros» currently place libatomic v1.2.0 on the same folder, but this knowledge would have to be coded in the helper script and refreshed from time to time. And if we are a bit less lucky and caxa copied some version of libatomic to some folder, and then the user subsequently installed an unrelated package that required a different version of libatomic , say apt-get install gcc , then would apt-get install additional libraries, and could there be a conflict? I suppose caxa could bundle a .deb file instead of the .so file, and then it could be installed with dpkg -i . Maybe this is what you had in mind all along! But then would caxa also package .rpm for Fedora, .pkg for Arch Linux and so on? Either the workaround script gets messy (complex), or it is simple but risks messing up with system libraries.

Not saying it couldn’t / shouldn’t be done, just pointing out some complications and things to consider.

what if you put your caxa application into an SD card and then plug it into a Raspberry Pi that is disconnected from the internet?

Then the user would have to manually run apt-get install libatomic1 beforehand (before running the caxa application) and at a location where the Pi has access to the internet. It would be part of the application’s installation instructions to the user. It is a problem, yes, but we have to choose which of the problems are the least bad ones. 🙂

apt-get update is a point of failure because of server-side / network errors, or when the base image is very old and the distro discontinues the repositories

Источник

There are several steps to get the very latest chromium-browser package running on Precise Pangolin, but I have succeeded and so should you!

1. Install from PPA:

This PPA is not recommended for general use but worked well on my Precise Pangolin system:

sudo add-apt-repository ppa:canonical-chromium-builds/stage
sudo apt-get update
sudo apt-get install chromium-browser

chromium-browser will not work out of the box as you have experienced until a few other issues are attended to…

2. Missing libatomic:

You will see an error when loading chromium-browser from the command line: a missing library libatomic.so.1. You can search for this missing file by using the great utility apt-file:

sudo apt-get install apt-file
apt-file update

(This creates a local index rather than a system one, use sudo apt-file update if you want a system index.)

You will be prompted to download file indices and you should accept this prompt and allow the download. Then search for the missing file:

andrew@ithaca:~$ apt-file search libatomic.so.1
gcc-mozilla: /usr/lib/gcc-mozilla/lib/libatomic.so.1
gcc-mozilla: /usr/lib/gcc-mozilla/lib/libatomic.so.1.0.0
gcc-mozilla: /usr/lib/gcc-mozilla/lib32/libatomic.so.1
gcc-mozilla: /usr/lib/gcc-mozilla/lib32/libatomic.so.1.0.0
andrew@ithaca:~$ 

You can see that it is part of the gcc-mozilla package which you can install as follows:

sudo apt-get install gcc-mozilla

Note that shared libraries are not sourced from the gcc-mozilla installation location as demonstrated here:

andrew@ithaca:~$ ldconfig -v 2>/dev/null | grep -v ^$'t'
/usr/local/lib:
/lib/x86_64-linux-gnu:
/usr/lib/x86_64-linux-gnu:
/usr/lib/x86_64-linux-gnu/mesa-egl:
/usr/lib/x86_64-linux-gnu/mesa:
/lib32:
/usr/lib32:
/lib:
/usr/lib:
andrew@ithaca:~$

So we add an extra path for chromium-browser with a slight variation of the technique demonstrated by @Renaud:

sudo touch /etc/ld.so.conf.d/chromium-browser.conf
echo "/usr/lib/gcc-mozilla/lib" | sudo tee -a /etc/ld.so.conf.d/chromium-browser.conf
sudo ldconfig

And you will now see the added search path:

andrew@ithaca:~$ ldconfig -v 2>/dev/null | grep -v ^$'t'
/usr/lib/gcc-mozilla/lib:   <------------- Here!
/usr/local/lib:
/lib/x86_64-linux-gnu:
/usr/lib/x86_64-linux-gnu:
/usr/lib/x86_64-linux-gnu/mesa-egl:
/usr/lib/x86_64-linux-gnu/mesa:
/lib32:
/usr/lib32:
/lib:
/usr/lib:
andrew@ithaca:~$ 

Note: If you try the aptitude build-dep chromium-browser method this step (adding the LD path) will still need to be followed…

But still more errors:

3. Missing libXss.so.1:

You will then get an error message:

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

Once again apt-file will locate the appropriate package:

andrew@ithaca:~$ apt-file search libXss.so.1
libxss1: /usr/lib/x86_64-linux-gnu/libXss.so.1
libxss1: /usr/lib/x86_64-linux-gnu/libXss.so.1.0.0
libxss1-dbg: /usr/lib/debug/usr/lib/x86_64-linux-gnu/libXss.so.1.0.0
andrew@ithaca:~$

And then install this library as follows:

sudo apt-get install libxss1

And that should do it as chromium-browser has no problem finding the library once installed!

4. Running the browser:

Running nicely here:

andrew@ithaca:~$ chromium-browser --version
Chromium 52.0.2743.116 Built on Ubuntu , running on Ubuntu 12.04
andrew@ithaca:~$ 

And the obligatory screenshot:

Click for full sized image….

And have fun

References:

• Debian Wiki: apt-file
• SO: How to print the ld(linker) search path

Многие пользователи Linux рано или поздно сталкиваются с ошибкой error while loading shared libraries. Как правило, при установке программ вручную. Сегодня поговорим об исправлении данной ошибки. Для примера возьмём старый ноутбук с Ubuntu 14.04 LTS, поддержка которой недавно закончилась, а значит что-то приходится доустанавливать вручную.

Ошибка error while loading shared libraries означает, что программа, которую пользователь пытается запустить, не смогла найти необходимую для своего запуска библиотеку. Такое часто случается, если программа устанавливалась не из репозиториев, а вручную. Например, на скриншоте ниже мы видим, что свежая версия Mozilla Firefox требует для своей работы библиотеку libatomic.so.1, но не может её обнаружить.

При этом, кстати, совершенно не обязательно, что данная библиотека отсутствует в системе. Поэтому сперва выполним поиск библиотеки (подробнее о locate в статье по этой ссылке):

locate *libatomic*

Естественно, в Вашем случае библиотека может называться иначе. Смотрите, что упоминается в тексте ошибки.

Если команда ничего не выдаст, это значит, что библиотеки в системе нет (а вот если библиотека найдена, тогда об этом ниже).

Поищем библиотеку в репозиториях:

sudo apt search libatomic

В результате мы получим перечень пакетов, которые в названии содержат libatomic:

В моем случае речь идёт о стареньком ноутбуке с 32-битной системой, поэтому мой выбор пал на libatomic1. Если Вы собираете программу из исходников, то будет полезным поставить не только библиотеку, но и заголовочные файлы с приставкой -dev. Сама установка проста:

sudo apt install libatomic1

В результате — актуальная версия Firefox в уже не поддерживаемой разработчиками Ubuntu (подробнее об установке новых версий Firefox в старых релизах Ubuntu в статье по ссылке).

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

Теперь о том, что делать, если библиотека есть в системе, но ошибка error while loading shared libraries всё равно появляется. Очень часто причиной этого является то, что загрузчик ОС не может найти библиотеку. По умолчанию поиск производится в каталогах: /usr/lib, /lib, /usr/lib64, /lib64. Не исключено, что библиотека просто лежит за пределами этих каталогов.

Вариантов тут несколько: переместить или скопировать библиотеку, ну или же указать загрузчику, где её искать. Последний способ более корректный, так как при нём Вы точно ничего не напортачите в системе.

Можно зайти в папку /etc/ld.so.conf.d/, открыть там любой конфигурационный файл и просто прописать местонахождение нужной библиотеки.

А можно сделать символьную (символическую) ссылку:

ln -s [путь_к_библиотеке/имя_библиотеки] /usr/lib/[имя_библиотеки]

Есть ещё одна причина ошибки while loading shared libraries даже когда нужна библиотека имеется в операционной системе. Библиотека может быть не той версии.

Версия библиотеки (или ещё её называют ревизией) пишется после расширения .so. В нашем примере нам требовалась библиотека libatomic.so.1, т.е. libatomic первой версии.

В разных дистрибутивах используются разные версии библиотек, а программы собираются под дистрибутив (и, как следствие, библиотеку конкретной версии). На практике же различия между версиями библиотек чаще всего минимальны. Поэтому для начала можно выдать библиотеку одной версии за библиотеку другой версии. В этом нам опять поможет символьная ссылка:

ln -s [путь_к_библиотеке/настоящее_имя_библиотеки] [путь_к_библиотеке/имя_библиотеки_с_нужной_версией]

Если этот способ не помог, то выход один — искать библиотеку нужной версии.

И последнее: после манипуляций с библиотеками желательно обновить кэш командой

sudo ldconfig

Вот, пожалуй, и всё, что нужно знать про ошибку error while loading shared libraries.