Error unable to find library

«ld.lld: error: unable to find library» on CentOS7 #23

Hello.
I tried to work hello-ktx sample according to README in this project. But it doesn’t work and output this error.

Task :samples:controlgallery:linkReleaseExecutableLinux FAILED
/home/komkomh/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/ld.lld: error: unable to find library -lgtk-3
/home/komkomh/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/ld.lld: error: unable to find library -lgdk-3
/home/komkomh/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/ld.lld: error: unable to find library -latk-1.0
/home/komkomh/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/ld.lld: error: unable to find library -lgio-2.0
/home/komkomh/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/ld.lld: error: unable to find library -lpangocairo-1.0
/home/komkomh/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/ld.lld: error: unable to find library -lgdk_pixbuf-2.0
/home/komkomh/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/ld.lld: error: unable to find library -lcairo-gobject
/home/komkomh/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/ld.lld: error: unable to find library -lpango-1.0
/home/komkomh/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/ld.lld: error: unable to find library -lcairo
/home/komkomh/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/ld.lld: error: unable to find library -lgobject-2.0
/home/komkomh/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/ld.lld: error: unable to find library -lglib-2.0
e: /home/komkomh/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/ld.lld invocation reported errors
FAILURE: Build failed with an exception.

My os version is
CentOS Linux release 7.6.1810 (Core)

Please give me a hint. Thanks

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

Источник

wasm-ld: error: unable to find library -lc #9807

Hello, I’m unsure where to begin debugging this — any pointers much appreciated.
This has followed advice from #9798 (comment) and now runs into this new error.
The source code is here if needed: https://github.com/craigmayhew/golem-tasks/tree/master/gwasm/compression

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

So the problem is that you are specifying -lc on the command line. You should instead let emscripten at the C library. In this case because you are building USE_PTHREAD=1 emscripten is building and linking libc-mt.a rather then libc.a .

So even if it could find libc here you would end up linking two copies of libc, which would be bad.

Maybe it’s rust passing in the -c ? cc @tlively as this sounds familiar.

This might be a rust limitation, or at the very least me misunderstanding how to compile a dependent crate. Recommend closing issue.

I would like to figure out why Rust is passing -lc in the first place and fix that. Or alternatively, @sbc100 would it be reasonable for Emscripten to accept -lc and possibly ignore it?

In this case I think the correct thing to do is stop passing -lc . Unless you are also passing -nostdlib or something add -lc should not be needed.

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

Closing this issue as there doesn’t appear to be any actionable takeaways.

@craigmayhew did u manage to get around this issue?

@trsh I don’t believe I did. I’ve just checked my projects commits and don’t see any «fix» or documentation updates after I created this github issue. Unfortunately I haven’t worked on the project where I found the issue for about 3 years so it’s also not fresh in my mind! If/when I find more time I will try to compile it again and see if the issue is still present.

Источник

Other Cross Compiling Rust from Windows To FreeBSD

throwaway896745

I’m trying to cross compile Rust from Windows to FreeBSD.

I am running into this

when I add
[target.x86_64-unknown-freebsd]
linker = «rust-lld»

to my config (searching online led me to believe rust-lld is a cross compiler I could use for this) led to

= note: rust-lld: error: unable to find library -lexecinfo

rust-lld: error: unable to find library -lpthread

rust-lld: error: unable to find library -lgcc_s

rust-lld: error: unable to find library -lc

rust-lld: error: unable to find library -lm

rust-lld: error: unable to find library -lrt

rust-lld: error: unable to find library -lpthread

rust-lld: error: unable to find library -lrt

rust-lld: error: unable to find library -lutil

rust-lld: error: unable to find library -lexecinfo

rust-lld: error: unable to find library -lkvm

rust-lld: error: unable to find library -lutil

rust-lld: error: unable to find library -lprocstat

rust-lld: error: unable to find library -lrt

It looks like I’m missing FreeBSD versions of system libraries, and don’t know how to proceed.

SirDice

Administrator

throwaway896745

unitrunker

throwaway896745

rustup target list
.
x86_64-apple-darwin
x86_64-apple-ios
x86_64-fortanix-unknown-sgx
x86_64-fuchsia
x86_64-linux-android
x86_64-pc-solaris
x86_64-pc-windows-gnu
x86_64-pc-windows-msvc (installed)
x86_64-sun-solaris
x86_64-unknown-freebsd (installed)
.

rustup target add freebsd
error: toolchain ‘nightly-x86_64-pc-windows-msvc’ does not contain component ‘rust-std’ for target ‘freebsd’
note: not all platforms have the standard library pre-compiled: https://doc.rust-lang.org/nightly/rustc/platform-support.html
help: consider using `cargo build -Z build-std` instead

Running cargo build -Z build-std (with or without —release) results in the same
.
rust-lld: error: unable to find library -lexecinfo
rust-lld: error: unable to find library -lpthread
.
errors.

Источник

wasm-ld: error: unable to find library -lc++ #1

I am trying to build the project in a Ubuntu 18.04 Docker container. Following the README, the compilation fails with this error. Any ideas? Thanks!

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

Hi Andrew/ Thomas,

Sorry to butt in but I happened to talk briefly with Thomas about this and thought I’d share my experience building the toolchain for my own work. Obviously YMMV and feel free to ignore me if this isn’t useful!

From what I can see, the waterfall script checks out the latest version of everything, hence won’t always guarantee a working toolchain (you can see the status here: https://wasm-stat.us/console, broken at time of writing). I found adding a step to check out the last good revision of all the tools helps (see here for the LKGRs), i.e.:

This is a bit fiddly, so would be worth scripting somehow. Until you know you’re building good revisions I found it hard to debug things.

For my own work I created a Docker image with everything pre-built. The repo and info can be found here: https://github.com/Shillaker/wasm-toolchain. The image is public so you should just be able to run something like:

This then gives easy access to a fully built wasm-ready toolchain. The downside to this approach is that it doesn’t include any of the Wavix modifications as it’s built for my own work on a project called «faasm» (https://github.com/lsds/Faasm) so is a bit useless, however, I thought some of the ideas/ code might be useful.

As I say, sorry to interject and ignore me if none of this is useful.

I’m traveling, so I can’t test this hypothesis, but it looks like what it happening is that cmake is trying to test that clang can compile a trivial program. However, it hasn’t yet compiled libcxx or libcxxabi, and it doesn’t pass -nostdlib when compiling the trivial program, so it fails.

I think this might be because I removed something that was setting CMAKE_CXX_COMPILER_WORKS=1 in the Wavix cmake toolchain file, and it kept working for me because an old version of the library was already installed.

Try adding -DCMAKE_CXX_COMPILER_WORKS=1 to the compiler-rt, libcxxabi, and libcxx cmake configuration commands in build.py and see if that fixes the problem.

From what I can see, the waterfall script checks out the latest version of everything, hence won’t always guarantee a working toolchain

This isn’t a problem with the Wavix fork of the waterfall scripts, since they just build the snapshots of the upstream repos that have been pulled into subtrees of the Wavix repo. I have occasionally seen upstream breakage when pulling the master branch of the upstream repos, though. Once the LLVM WebAssembly support is more mature, I’ll probably switch to pulling from the release branches of those repos.

I’ve created what should be a working Dockerfile including the CMAKE_CXX_COMPILER_WORKS tweak and a fix for a very small case-sensitivity issue in build.py.

Can be seen in this PR: #2 @thomasknauth that should work.

If the Dockerfile is useful it could be good to push the built image to Dockerhub (e.g. under wavix/toolchain ) so that people can pull it directly and avoid the build process.

I pushed an image to Docker with the built toolchain here: https://hub.docker.com/r/wavm/wavix/

I’d like to figure how to automate keeping it up to date before directing new users to it, though. I don’t think Travis allows jobs to run long enough to build the image.

(this issue should be fixed by 758caee)

Источник

NDK 23 beta: Build fails with unable to find library -lgcc #22

I’m trying to build a new project, however when running the command cargo ndk -t aarch64-linux-android -o ./jniLibs build —release , but I end up with an error;

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

Does it work if you use ndk 22.x or lower?

Yes, it seems that way the .so file is created

So, NDK 23 removes libgcc entirely. Rust relies on this for providing missing builtins on Android.

This seems to still only work with nightly. To use aarch64 builds as an example, this will work:

The problem seems to be the Rust CI builds for Android still use an older NDK or something similar that causes it to require libgcc. If you build your own std, no problem.

@tux3 this is a separate issue, please create one and report this there 😄

If somebody wishes to do so.

I’d like to mention that the workaround named above (building with std) does not work in my situation. I am using NDK R24 if that requires mentioning
I still get ld: error: unable to find library -lgcc using this command invocation:

If anyone would like to test this very specific scenario, the project is over here and shouldn’t require extensive setup configurations.

• I have not tested with other NDK versions
• I have not tested other rust projects

Am I missing something? Feel free to call me out on it

Update:
Tested NDK R23c and still does not work

I’d like to mention that the workaround named above (building with std) does not work in my situation. I am using NDK R24 if that requires mentioning I still get ld: error: unable to find library -lgcc using this command invocation:

If anyone would like to test this very specific scenario, the project is over here and shouldn’t require extensive setup configurations.

• I have not tested with other NDK versions
• I have not tested other rust projects

Am I missing something? Feel free to call me out on it

Update: Tested NDK R23c and still does not work

create 4 text files named libgcc.a in the same folders with this contents
it works on ndk 24.0.8215888

Источник

Модераторы: vadim64, terminus

Linking C shared library libfreerdp-client.so
/usr/bin/ld: cannot find -lgstreamer-0.10
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Stop.
make[2]: stopped in /root/freerdp
*** Error code 1

Stop.
make[1]: stopped in /root/freerdp
*** Error code 1

Stop.
make: stopped in /root/freerdp

# find / -name "libgstreamer-0.10.a"
/usr/local/lib/libgstreamer-0.10.a

ln /usr/local/lib/libgstreamer-0.10.a /usr/lib

encoder/cabac.c:(.text+0x4b0c): undefined reference to `x264_cabac_encode_bypass_asm'
libx264.a(cabac.o): In function `x264_cabac_ref_p':
encoder/cabac.c:(.text+0x4b99): undefined reference to `x264_cabac_encode_decision_asm'
encoder/cabac.c:(.text+0x4bb6): undefined reference to `x264_cabac_encode_decision_asm'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake: *** [x264] Error 1
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/multimedia/x264
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/multimedia/x264
*** Error code 1

Stop.
make: stopped in /usr/ports/multimedia/x264

encoder/cabac.c:(.text+0x4bb6): undefined reference to `x264_cabac_encode_decision_asm'
cc: error: linker command failed with exit code 1 (use -v to see invocation)

ln -s /usr/local/lib/libgstreamer-0.10.a/libgstapp-0.10.la /usr/local/lib/libgstreamer-0.10.a