Failed to load library linux

Failed to load library in Linux Mint 18.2 — HL 1.6 #160

Comments

josuigoa commented Jun 18, 2018

Hi!
I’ve downloaded the latest HL release for Linux (I’m using Mint 18.2 64bit) and my Haxe version is 4.0.0-preview.4. When I execute ./hl main.hl it tells me src/module.c(268) : FATAL ERROR : Failed to load library fmt.hdll . I’ve also tried building from source but it can’t get it working.

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

andyli commented Jun 18, 2018

Put the hdll files in /usr/lib , or use LD_LIBRARY_PATH .

josuigoa commented Jun 19, 2018

I’ve put them in /usr/lib and I’m getting this

I’ve tried putting in /usr/local/lib I get the fmt.hdll not found

ncannasse commented Jun 20, 2018

Seems like it goes further with /usr/lib, so there must be another missing dependency in ssl.hdll , try to run ldd /usr/lib/ssl.hdll to check what might be missing.

andyli commented Jun 21, 2018

Yeah, I can see that ssl.hdll was linked with mbedtls dynamically:

@ncannasse Why not just publish only win binaries like you did for hl 1.4? Mac and Linux binaries need some extra care to make sure these things are done right.

ncannasse commented Jun 22, 2018

@andyli we could link mbedtls statically — if possible with the linux package. I thought having binaries would help some people

andyli commented Jun 26, 2018

Yeah, so either check carefully everything (except libc) is statically linked, or just don’t provide binaries.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Failed to load native library ‘libnative-platform.so’ for Linux amd64. #29

Comments

ctmay4 commented Oct 6, 2017

I am running on a Linux hosted OpenShift container and trying to execute builds using Gitlab CI Runner. I get the following error when using the Gradle Docker images:

If I use the gradle:4.2.0-jdk8 I get the error. If I use image: java:8 I do not get the error. I tried adding the stacktrace and info options but it fails right away before supplying any help.

I saw there a similar issue that was closed but he said it had to do with OS X so this seems different.

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

ron-reaser commented Oct 7, 2017

I also have this issue. I believe it was fixed in Gradle 4.2.1, and the current Gradle image for Docker only goes up to 4.2.0, so once the image is updated it should be resolved.

keeganwitt commented Oct 8, 2017

I’ve opened a PR with Docker library to update to 4.2.1. Let me know once it’s merged if it doesn’t resolve your problem.

ron-reaser commented Oct 10, 2017

I have tested gradle:alpine, gradle:4.2.1-jdk-alpine, and gradle:4.2.1-jdk and the failure to load the native library is not resolved.

keeganwitt commented Oct 11, 2017

What user are you running in the container? And do you have the Gradle home volume mounted?

ron-reaser commented Oct 11, 2017

The image is being run by the latest version of GitLab Runner (CI). I believe it’s run as an unprivileged user. It does have access to the Gradle home volume, as far as I know. For reference, if I use frekele/gradle from Docker instead of library/gradle, the problem does not occur.

keeganwitt commented Oct 12, 2017

So the only times I’ve seen this is the past is if your volume isn’t writable by the uid the container runs under (1000). I’d suggest trying running the container with -u root .

ron-reaser commented Oct 12, 2017

For my situation, running as root is not a safe fix, but I believe the volume is writable anyway . Here’s all the relevant information I’ve read: 1, 2.

keeganwitt commented Oct 12, 2017

FYI, if I’m right about the volume permission being the issue, frekele/gradle wouldn’t be affected as it runs as root. Is this a Java project or native project?

ron-reaser commented Oct 13, 2017 •

Using the Docker executor in GitLab Runner to run Gradle to compile a Java project. The only thing I change is whether I use frekele/gradle or library/gradle, so I think that means the privilege scenario (root or not) would be the same for both, at least from outside the container (not counting anything that happens in the Dockerfile). I’m not really experienced enough with Docker or Dockerfiles to be able to help much, but I know that everything from outside the container (in terms of how it is executed) is handled identically regardless of the image by GitLab Runner’s process. I think the only variable could be what happens inside the container. If you mean that’s where the privilege issue occurs, I’m afraid that’s beyond me, but I’ll do what I can to help identify it, if you bear with me.

keeganwitt commented Oct 13, 2017

Yep, that’s what I mean; the user that it’s running as inside the container. So if you change the command to be docker run -u root . it’ll run as root inside the container instead of the default user I created in this container (so people can avoid using root when they can).

ron-reaser commented Oct 13, 2017

So does that mean you’re confirming the frekele/gradle does run as root inside the container, but library/gradle does not, and that’s the cause of the problem? If so, I’ll try that fix.

keeganwitt commented Oct 13, 2017 •

More specifically, the UID/GID of the user in the container needs write access on that volume.

You can check that against your volume by comparing things like this on the host

ron-reaser commented Oct 15, 2017

That makes sense. I can’t confirm or deny a fix, because in my particular scenario I can’t test any of the known fixes, but I appreciate the information.

keeganwitt commented Oct 16, 2017

I’m not familiar with Concourse, but you could temporarily add a Bash step to your job if you wanted, right?

At the very least you should be able to change the container user, right? Concourse is an important use case I think, so I just wanted to be sure that this image wasn’t unusable on that platform.

ron-reaser commented Oct 16, 2017 •

I don’t know what Concourse is. Another CI service? The OP and myself have an issue with GitLab Runner as it interacts with the Docker Gradle image. It’s unusable on that platform (while maintaining a reasonable level of security), but that’s probably a niche concern, and the fix would be for me to make a Dockerfile which pulls from your image and just replaces the user directive, or for me to find a way to create the Gradle folder with the correct ownership inside the container.

The primary frustration, I think, is that the error message regarding the native library is so obtuse.

keeganwitt commented Oct 16, 2017

Oops, I was thinking of another issue.

Hmm, the options for the Docker Executor in Gitlab are pretty limited (for example, you also can’t map ports). The only ways around that from what I’ve read is Docker in Docker (which has some privilege escalation risks) or use the Shell Executor with the Docker commands in a script.

Alternatively, you could add your own image to run (and upload to your own repo on Dockerhub) like this

If this is a problem in several places, I guess I’ll bring back root, but I’m generally inclined to avoid it if I can.

keeganwitt commented Oct 16, 2017

I just uploaded images with the root Dockerfile change, if you’d like to give that a try: https://hub.docker.com/r/keeganwitt/docker-gradle-root/.

ron-reaser commented Oct 16, 2017 •

Yes, the Dockerfile you listed is the solution I was thinking would work, so the confirmation is helpful (I haven’t tried it). It’s probably the solution I’ll eventually adopt, because I need other stuff installed inside the image anyway, and then I’ll have to put it in the GitLab container registry, which is a whole ‘nother thing.

Thank you a lot for your help. I’ve done a lot of searching on this issue, and this is the first time anybody on the internet has bothered to explain what the actual problem is. So hopefully this issue and your posted solutions will help others with the same problem in posterity.

bradjones1 commented Oct 21, 2017

It may also be sufficient to set the GRADLE_USER_HOME environment variable to a directory writable by the user.

ron-reaser commented Oct 24, 2017

Unfortunately, I already do that, and it creates the directory as the root user. I’m not sure why. So then when I go to access it, I still have the problem.

bradjones1 commented Oct 24, 2017 •

@ron-reaser You could always specify the run-as user inside the container with

ron-reaser commented Oct 24, 2017

My use case does not allow that (see previous comments).

keeganwitt commented Oct 24, 2017

The problem (at least in his case) is the volume containing project he’s building not being writable, not the Gradle home.

razvan-flavius-panda commented Feb 6, 2018

I am getting the same error on Gradle 4.5 on NixOS

keeganwitt commented Feb 7, 2018

@razvan-panda You’re a GitLab user as well? Has GitLab commented at all on this issue?

razvan-flavius-panda commented Feb 7, 2018

@keeganwitt I am not a GitLab user. But nothing I could find helped me fix the issue, especially since it built successfully from the terminal and it only fails during the nix-build.

keeganwitt commented Feb 7, 2018

This looks like you’re running Gradle itself, not the Docker Gradle image. Have I misunderstood?

razvan-flavius-panda commented Feb 7, 2018

@keeganwitt I am having this issue when running Gradle via Nix and not using the Docker Gradle image.
But mentioning that the issue happens with Gradle 4.5 also might be useful for this ticket.

Labi0 commented Apr 15, 2018

I got this issue with gradle 4.2.1 and RHEL 7.4; Using some info provided here, I discovered that the user executing did not have write permission to create the gradle-user-home in the parent-directory. Creating the gradle-user-home directory with the desired permission resolved the issue.

ebuildy commented Nov 22, 2018

Same issue because I changed the user to match GitlabCI gitlab user, I managed to fix it, here the Docker command I run:

Beau-1983 commented Dec 22, 2018

when I use a normal user (not root user) to run gradle -v in my ubuntu system ,it outprint «Failed to load native library ‘libnative-platform.so’ for Linux amd64.»,but root user can work.

here is the logs:

beau@BeauPC:/opt$ sudo su —
[sudo] beau 的密码：
root@BeauPC:

Gradle 5.1-rc-2

Build time: 2018-12-17 22:42:01 UTC
Revision: 4f93941ff2f23ed981b9416a66af36ab0a8ef4de

Kotlin DSL: 1.1.0
Kotlin: 1.3.11
Groovy: 2.5.4
Ant: Apache Ant(TM) version 1.9.13 compiled on July 10 2018
JVM: 1.8.0_181 (Oracle Corporation 25.181-b13)
OS: Linux 4.15.0-43-generic amd64

# exit
注销
beau@BeauPC:/opt$ gradle -v

FAILURE: Build failed with an exception.

What went wrong:
Failed to load native library ‘libnative-platform.so’ for Linux amd64.

Try:
Run with —stacktrace option to get the stack trace. Run with —info or —debug option to get more log output. Run with —scan to get full insights.

Is anyone who can help me to resolve this problem ? please send me email to 462620105@qq.com,ths!

kphannan commented Dec 31, 2018

After some experimentation and internet spelunking I found that the problem is permissions on the directory where libnative-platform.so is extracted to from the appropriate jar file(s) that comprise gradle. This directory needs to be writable by the user running gradle. An easy way to fix the issue is to either set GRADLE_USER_HOME to some directory writable by the user running gradle; or specify the directory on the command line gradle -g $(pwd)

keeganwitt commented Feb 1, 2019

Closing stale issue. Comment if you feel it should be re-opened.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Unable to load shared library ‘libSkiaSharp’ or one of its dependencies — azure app service on Linux #1341

Comments

tbasallo commented Jun 18, 2020

Description

Just like the bug that was closed #1312 . Except this one is not using any other external libs, it’s just the Skia code.

A page that accesses Skia on Azure Linux fails. The same page on Windows desktop or Azure runs fine.

Exception

Raw

• Version with issue: Both 1.6 and 2.8 preview (NUGET)
• IDE: VS2019
• Core 3.1, Azure Linux App Service

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

mattleibow commented Jun 18, 2020

Most likely you don’t have the FontConfig dependency for Linux. This needs to be installed via the platform tooling (apk or apt-get).

There is also the SkiaSharp.NativeAssets.Linux.NoDependencies that you can use instead of SkiaSharp.NativeAssets.Linux to avoid this, but you lose out on some advanced font features.

This usually does it for me:

tbasallo commented Jun 18, 2020

Since this is Azure Linux App Service users cannot install anything.

I’ll try the NoDependencies since this purely image based, no fonts, which I’m assuming is text functions. I’ll report back.

mattleibow commented Jun 18, 2020

The other option is just to use Docker services.

mattleibow commented Jun 29, 2020

Did you manage to resolve this?

JMan7777 commented Jul 17, 2020

I’m running a Linux Web App in Azure (docker container based on the Alpine 3.11 image from MS)

Even I use the SkiaSharp.NativeAssets.Linux.NoDependencies package (version 2.80.1) I still get the exception:

I use the following base image:
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-alpine3.11 AS base
and add the icu-libs package:
RUN apk add —no-cache icu-libs

Are there any other packages required?

mattleibow commented Jul 19, 2020

@JMan7777 I had a look at this and I found the issue. Thanks for reporting.

The bug:
For some reason the Alpine build of no dependencies is still building with fontconfig. I have checks in CI for this, but it missed this? Not sure at this time. I will investigate and get a fix out ASAP.

The workaround:
Install fontconfig (not icu): RUN apk add —no-cache fontconfig

However, if you can install fontconfig on your systems, then it might be better to just use the plain SkiaSharp.NativeAssets.Linux package as that has better font features.

Apologies for this. I’ll have a look at the build tests to determine why this got through and ensure it does not happen again.

mattleibow commented Jul 19, 2020 •

FYI, the way you can debug missing dependencies is to either do:

readelf -d libSkiaSharp.so

mattleibow commented Jul 19, 2020

I got a fix going out with 2.80.2. Thanks for reporting.

JMan7777 commented Jul 19, 2020

Do we still need the icu-libs package for the NoDependencies version?

mattleibow commented Jul 19, 2020

No. We don’t need the icu at all. We are using harfbuzz, but that is in a separate NuGet as an option. Not required.

IsoraTatsu commented Jul 20, 2020

Exception
System.TypeInitializationException: The type initializer for ‘SkiaSharp.SKImageInfo’ threw an exception.\n —> System.DllNotFoundException: Unable to load shared library ‘libSkiaSharp’ or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: liblibSkiaSharp: cannot open shared object file: No such file or directory\n at SkiaSharp.SkiaApi.sk_colortype_get_default_8888()\n at SkiaSharp.SKImageInfo..cctor()\n — End of inner exception stack trace —\n at SkiaSharp.SKImageInfo..ctor(Int32 width, Int32 height)\n at SkiaSharp.QrCode.Image.QrCode..ctor(String content, Vector2Slim qrSize)\n at SkiaSharp.QrCode.Image.QrCode..ctor(String content, Vector2Slim qrSize, SKEncodedImageFormat outputFormat)\n at .

.net core 2.1, aws linux
Version with issue: 2.80.1

Источник