I'm building a Yocto minimal image on Opensuse Tumbleweed using bitbake core-image-minimal and I am getting the error
qemu-native/4.1.0-r0/qemu-4.1.0/linux-user/syscall.c:7657: undefined reference to 'stime'
| collect2: error: ld returned 1 exit status
Some googling turns up some known bugs referencing this, and it seems to be caused by glibc taking out stime from time.h in a newer version.
Source:
https://wiki.gentoo.org/wiki/Glibc_2.31_porting_notes/stime_removal
So my question is how do I fix this? I would like to avoid rolling back the c library if possible but if there are no other options I guess I don't have a choice.
What oe-core version are you using? Is it zeus? I think it's already fixed in just released dunfell.
See oe-core commit 2cca75155baec8358939e2aae822e256bed4cfe0
Related
So in the process of trying to find a way to offset my c program in the linking phase to 0x1000 for the standard kernel loading spot, I downloaded binutils from GNU (myself, not through Homebrew), which seems to have created a tricky error. When I invoke ld in Terminal, I get this error message(yes the blanks are what's displayed):
ld: unrecognised emulation mode:
Supported emulations:
Even after going through each directory in binutils and make uninstalling each, and removing and then redownloading Xcode CommandLineTools, the issue persists. I'm a bit lost- any ideas? Thank you!
Forgot to mention, I noticed ld wasn't included in the initial download of binutils, and downloaded it seperately through the ld directory of binutils. This was before I saw that GNU doesn't support Darwin for ld unless its installed as a cross-linker, yet it still ended up on my system somehow (I didn't install it as a corss-linker). I uninstalled ld along with all the other binutil functions.
I get the following error when running install-agraph for agraph-6.6.0
An unhandled error occurred during initialization:
Loading sys:aclissl.so failed with error:
/home/<username>/agraph-6.6.0/aclissl.so: undefined symbol: CRYPTO_set_locking_callback.
[physical pathname is /home/<username>/agraph-6.6.0/aclissl.so]
Cannot find much with google-fu on this error - at least nothing useful. Any leads would be helpful.
This problem has been fixed in the upcoming 7.0 release of AllegroGraph. Your workaround, using a system with OpenSSL 1.0.x is the correct one, for the currently released version of AllegroGraph.
While compiling cobalt for raspberry pi on ninja, im getting an error like this:
undefined reference to symbol 'eglCreateImageKHR'
here is the full trace:
[1/1] LINK cobalt
FAILED: cobalt
/home/mi07/work/raspitools/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++ #cobalt.rsp
/home/mi07/work/raspitools/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: obj/starboard/raspi/2/../shared/open_max/starboard_platform.decode_target_create.o: undefined reference to symbol 'eglCreateImageKHR'
/home/mi07/work/raspitools/sysroot/opt/vc/lib/libbrcmEGL.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
I googled it and found somewhat related article on this site.
As per this article the fault could be that of libssl1.0-dev not being there. I checked and found it was libssl-dev. Replaced it with libssl1.0-dev but still the error persists.
Can somebody tell me what is going wrong?
eglCreateImageKHR() is an EGL extension EGL_KHR_image. Since Cobalt compiled, it appears the headers declare the extension, but the linked EGL library didn't define it. It's surprising that only eglCreateImageKHR() is missing and not eglDestroyImageKHR as well.
At any rate, I recommend trying to update the EGL library, but I'm not familiar with the raspi install, so can't tell you the specifics.
Alternatively, it is safe to comment out the call to that function in decode_target_create.cc since SbImageIsDecodeSupported() always returns false for raspi (see image_is_decode_supported.cc), so decode targets should never be created / destroyed on the platform. (Decode target support is a work in progress for raspi.)
I resolved this by changing the os itself. The problem was that the cobalt was not compatible with raspi stretch but with raspi jessie. Because sysroot files are being copied from the OS it was creating that error. I don't know exactly where the difference is but changing to raspi jessie worked fine for me.
I'm working on a Swift app in Xcode 6. Everything was working okay until I decided to install cocoa pods and a pod. When I try to run it on the simulator, I get the following error:
ld: 91 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Before the error, there is a listing of all those duplicate symbols.
First few lines in error message:
Ld /<...>/Library/Developer/Xcode/DerivedData/<...>-gydnbbvfswpkkodlsuxdkpzkklzb/Build/Products/Debug-iphonesimulator/<...>.app/<...> normal x86_64
cd "/<...>/Documents/iOS Apps/<...>/<...>"
export IPHONEOS_DEPLOYMENT_TARGET=8.1
I even tried uninstalling the pod, but the error persists. I'm completely stuck – any help is much appreciated. Thanks!
Maybe you should update your CocoaPods to 0.36 or a later version, and add use_frameworks! to your Podfile. See this: CocoaPods 0.36 - Framework and Swift Support
Maybe :
You have put the same class implementation into two different files;
You actually have just one implementation of this class, however you are also linking in your project a framework or library containing a class whose name is exactly the same of yours.
I am migrating from 4.3 to xCode preview45
While linking my coreplot lib, i am getting this, which i am trying to resolve since last 5 days.
Please suggest me what should i do to overcome this issue. clang:
clang: error: -Z-reserved-lib-stdc++: 'linker' input unused when '-c' is present
Command /Volumes/Xcode 1/Xcode45-DP3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1
I tried changing C/C++ compiler,linker flag, etc, nothing worked so far.
Thanks
The easiest way to fix this is to pull the latest code with Mercurial. If you don't want to do that, you need to remove several compiler flags and make some other changes. See the necessary changes here and here.