Ld.lld Not Found
Colby DuLin
The problem was happening when running cmake. Though, in this case cmake was not the problem the error was silent and the -lpthreads related error/warning was the only thing being written to the cmake error log file, although that was not causing any issue. I've done a minimal version of the cmakelists.txt and started testing it line by line until I found which package was causing it to stop: finally I found it was a version mismatch...
What you are looking at is the CMakeCache.txt, the CMakeOutput.log or the CMakeError.log. How comes? When some of the macros or tests in the configure phase fails, CMake "helpfully" dumps these files to the output. Unfortunately, these files can be thousands of lines long, and typically contain lots of "*** Error: xyz" entries, for various configure checks. The one for "-lpthreads" just accidentally happened to be the last one in the log...
Solution: go through the log from the top, identify the section with the configure checks, find the last configure check prior to the point, where CMake identifies failure and dumps its logs. You might also try so search for the text "Configuring incomplete, errors occurred!"
Typically you'll either find a very precise actual error message there, or at least you find the name / path of the macro or function called last, and this allows you to pinpoint down what actually went wrong.
In my case, this immediately pinpointed a library (or rather, its development package) that was missing. Installed it, added it to debian/control's Build-Depends: section, recompiled, everything worked.
I found out what was causing my issue. I initially did it with cmake2, but the project needed cmake3. I changed it to cmake3, but it didn't do a clean build, so some leftover garbage was messing everything up. When I cleaned everything and used cmake3 it worked.
I also meet this issue. Exactly the same situation: have pthread lib under /lib/x86..., but the find_package() always gives a "can not find lpthread error".And after some check and consulation to my friend, we find that in my case, I build the cmake from source code and let the cmake link search path be wrong. So we deinstall the self-buid version and reinstall the cmake in a "correct" way by adding the apt source and using apt get install. That solves my issue. Hope this could help guys in the same situation.
This question has many answers; it seems that many obscure issues can cause this bug. The other answers didn't work for me, and though my Output/Error logs were fairly clean, I couldn't find any additional error messages or failures there. So I'll add what I did in case it helps anyone who is in my situation.
In short, my problem was fixed when I deleted the entire build directory and rebuilt from scratch. Deleting only the CMakeCache wasn't enough. If you have this issue, try doing that and see if it works
I found from googling that libc includes these functions and according to the fact that the error messaage suggests me to use >>> did you mean: sem_open I assume that the libc was found in my termux environment, or not? Any help or hints are very appreciated as I wasted a couple of hours already to try to fix that.
XDA Developers was founded by developers, for developers. It is now a valuable resource for people who want to make the most of their mobile devices, from customizing the look and feel to adding new functionality.
I already ran the Automatic installation script and have clang-18 and ld.lld-18 installed (I even created symbolic-links for clang and ld.lld respectively), but I still receive the same error as above.
If you have ever done software development that involves Apple products, FreeBSD, WebAssembly, or Rust, you have used the wildly popular compiler toolchain known as LLVM. However, LLVM and the open source C-language compiler built on top of it (Clang) do not get a lot of attention in the embedded world.
When I try even a simple program, which had main() and used std::ostringstream to stringify some numbers, and was compiled for a ARM Cortex M CPU (with e.g. 256 kB of Flash), the Flash area was overflown.
Glad to hear you enjoyed the article! The error you hit above suggests you may not be targeting the right architecture. What CFLAGs are you using? (For example, if you are compiling for a cortex M4, you want to make sure you have something like -mthumb -mcpu=cortex-m4).
Another great post at Interrupt, thank you @chrisc! This is the first time I am reading about ownership_returns and ownership_takes and it looks like some powerful tool beyond malloc-like functions (especially in combination with ownership_holds).
Compiling freertos_kernel/portable/MemMang/heap_1.c
Linking library
ld.lld: error: unable to find library -lgcc
clang-10: error: ld.lld command failed with exit code 1 (use -v to see invocation)
make: *** [Makefile:148: /home/rajah/workspace/interrupt/example/freertos-example-``llvm/build/nrf52.elf] Error 1
When I just run make instead of scan-build make, an elf output is generated. However, even with this error, I can still run scan-view as all the errors have been captured as part of the compile process. I am very impressed with how the errors are presented. I will continue with rest of the blog post as scan-build is working now. Any idea why scan-build its not able to find the gcc library?
There are no issues whatsoever when we build our project the same way on a local Windows 10 machine.
That being said, can you please tell us what may be causing this error and how can we debug / fix it?
We have found out the root cause of this issue - for some reason Unity sysroots cache (AppData\Local\unity3d\cache\sysroots\linux-x86) got broken - there was no /usr/lib64 folder. Removal of the cache folder has fixed the build process.
How should I go about fixing this? A quick search for the first error gave me this reddit post: Reddit - Dive into anything which says that i can manually link some library, but I'm not exactly sure what to link.
Great, so the compilation worked. Getting an embedded firmware to link is really dependent on what exactly are you trying to get as a result -- what is the hardware you're targeting? Are you trying to use some vendor's SDK, toolchain, prebuilt libraries, and/or startup code?
Given how complex linking is for embedded software, I recommend splitting up the compilation and linking and controlling both separately, i.e. calling swiftc with -c to only produce an object file, and then calling whatever linker you want to use with whatever else you need to link in.
I'm trying to use Infineon's CY8CPROTO-062-4343W microcontroller. Its build process is a little bit complicated, needing an app named ModusToolbox with loads of custom Make scripts. An example project is here
My plan mainly follows that second example you provided. I want to build my swift code to an object file and the header file, then include the object file inside the directory where the Make scripts will automatically compile it (with Infineon's custom GCC) along with the other boilerplate C code.
ModusToolbox uses a custom build of gcc-arm to build the executable. Compiling a C file, it outputs files of type ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped. It seems quite similar to the one that swiftc outputs (bar the "SYSV" instead of "GNU/Linux"), but when I compile my test.o file I get a slew of confusing error messages
When I tested outputting an object file outside of embedded swift, I needed to pass the -emit-library flag so that the output doesn't contain a main function. However, including that flag in my build command causes those linking errors again
Your suggestions for -Xcc -fshort-enums and -parse-as-library worked! They fix the enum and linking errors. I also dug around the ModusToolbox build commands and found a slew of flags that they also include.
I added the flags you suggested, and fed Infineon's flags to the compiler through -Xcc, excluding the -I include flags, since I'm testing this command out in a seperate directory and I want to figure out how to build the file before working out the vendor's SDK.
To build the object file to an executable using Infineon's GCC (this is a final step within their make process, after building all the source files to objects, it combines and links it into a single executable), I use this command (with the same flags):
Searching around for what the errors mean, they seem to surface results from C++ about a missing standard library. Infineon's GCC is used for C, but i did get a "missing standard library" message when using the -static-stdlib flag:
EDIT: I just realised that I don't need to compile it myself, i have the .o file in the right format so I can just use Infineon's Make command to build it. It does successfully build, just not on the device. I'll play around with it and send a reply when I'm done
Thanks for the question! We're working on adding C++ binaries into the LLVM toolchain for Linux and it should become available via the artefact on GitLab that you mentioned in a few weeks time. At first, it is going to be experimental, so any feedback would be greatly appreciated. I'll add a comment here once you can download it from GitLab.
A quick update. We have recently updated one of the scripts that are used to build the toolchain: tools/build-morello.sh. New version have three experimental steps: libunwind, libcxxabi, and libcxx. They allow to build C++ libraries from LLVM for purecap target and link them to purecap Musl. I must warn that they are very experimental at this point only build static versions of these three libraries, but you are welcome to try and see if it works for you. We hope to improve this at some point.
It is totally fine to use the prebuilt LLVM binaries for the v1.6 release, in fact, this should save you some time and allow to skip first few steps from the guide. These binaries are generated according to the guide anyway.
Re. the warnings, I had assumed these were related to the fact exception handling is not working... seems you already know about those warnings, so I guess exception handling is a bug. I investigated this issue further, so here are some more details...
c80f0f1006