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
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.
while I was following this tutorial
https://developer.mbed.org/cookbook/eclipse-for-building-and-debugging
I run on a error building the project on Eclipse (I followed all the steps untill the first build project at which point I received the following error):
../../external/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11UXX/TOOLCHAIN_GCC_ARM/TARGET_LPC11U24_401/LPC11U24.ld:50 cannot move location counter backwards (from 00000238 to 00000200) collect2: error: ld returned 1 exit status make: *** [LPC11U24/FileTest.elf] Error 1
Since ld is involved I think the problem is related to the linker but I have no clue what to do and where to look at. I'm working in Debian 32 bit and Eclipse LUNA.
I found the problem, I selected the wrong toolchain: linux gcc instead of cross gcc.
Here is the situation:
Ubuntu 13.04, Matlab 2012a and Intel C++ Composer XE 2013 for Linux.
I downloaded a matlab code archive and followed the instructions in it to compile the .cpp files. Formerly when I finished installing Matlab 2012a and started it, some error messages showed up and I googled out an answer which is:
sudo ln -s /lib/x86_64-linux-gnu/libc.so.6 /lib64/libc.so.6
And then there came out another error message which told me 'missing lstdc++' when I started compiling, the idea of re-installing g++ first came into my mind, and the error message disappeared after I did so. However, finally I got an error which I could not find an answer anywhere:
>> compilemex
ld: cannot find -lguide
mex: link of ' "max_pool.mexa64"' failed.
Error using mex (line 206)
Unable to complete successfully.
Error in compilemex (line 20)
eval(exec_string{1});
During the the process of searching for a solution, I found a thread for my previous 'missing lstdc++' error which differed from what I did to fix it, does this matter or not? And another hint is that I could not find any file named like 'libguide' under the /opt/intel/ directory, how could I fix it?
Thanks in advance!
Googl'ing for libguide, i found this:
http://software.intel.com/en-us/forums/topic/284445
According to this, the build script you're using refers to an old version of the intel compiler. Newer versions seem to have the functions in libguide.so moved to libiomp5.so.
So try replacing -lguide by -liomp5.
Disclaimer: this is pure google knowledge. Personally I have no idea what either library is good for :)
Can anybody give me some hints for solving this?
I'm trying to compile "Kinect Matlab" (on Mac OS 10.7), in the compile script is the following line:
mex('-v','-L/usr/lib/','-lOpenNI',[...],Filename);
This is the full command run by mex: (1)
gcc-4.2 -O -Wl,-twolevel_namespace -undefined error -arch x86_64 -Wl,-syslibroot,/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5 -bundle -Wl,-exported_symbols_list,/Applications/MATLAB_R2011a.app/extern/lib/maci64/mexFunction.map -o "mxNiChangeDepthViewPoint.mexmaci64" mxNiChangeDepthViewPoint.o -L/usr/lib/ -lOpenNI -L/Applications/MATLAB_R2011a.app/bin/maci64 -lmx -lmex -lmat -lstdc++
Then I'm getting the following error:
ld: library not found for -lOpenNI
collect2: ld returned 1 exit status
mex: link of ' "mxNiChangeDepthViewPoint.mexmaci64"' failed.
There is most definitely a file at /usr/lib/libOpenNI.dylib.
What kinds of things cause ld to throw this error?
What I tried:
I have tried creating a symlink called libOpenNI.so, like jmlopez suggested, no effect.
Could it be that libOpenNI is a 32bit library, and ld is not seeing it for that reason? Or would the error then be different?
Regarding the point above, it says that the build is "universal x86/x64"
Env vars:
I've tried to add the library to the environment variables using the following command, from the matlab terminal. No effect.
setenv('DYLD_LIBRARY_PATH', [getenv('DYLD_LIBRARY_PATH') ':/usr/lib/']);
In bash:
Just calling gcc as suggested here https://serverfault.com/questions/54736/how-to-check-if-a-library-is-installed gives no problems.
$ gcc -lOpenNi
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
However, if I run g++ first, then gcc as in (1), same error as before. (library not found). How come gcc can find the library, but when matlab adds the stuff in (1) it messes things up?
So, related to what is said above, I started removing all arguments from (1) until I got a different error. I removed the -Wl,-syslibroot, meaning that -syslibroot would no longer be passed to ld, this seems to have fixed it. So -syslibroot is messing up the library search directory! Now to find a way to remove this argument from the mex() call.
Did you trying adding OpenNi to your LIBRARY_PATH ?
export LIBRARY_PATH=$LIBRARY_PATH:/YOUR-PATH/OpenNi
First option: if libOpenNi isn't of the same architecture as the binary you're compiling, the whole compiler suite will likely ignore it. If you did manage to get it to link anyway, it would probably crash. Find a native 64 bit library and link against that.
Second option: I'm not 100% sure on this, but whenever I've tried doing linking on some esoteric linux projects, I start with a .a object archive in the path specified by -L. If it links, then I'll add -fPIC -shared on x86_64 to get it to compile against the shared library. I'm not sure if this will work on OSX: I've never done development on that platform yet.
BOOM! IT WORKS!
Okay, here it is:
The -Wl,-syslibroot option in the gcc call (1) is sending a -syslibroot option to the linker, and somehow that gets prepended to the library search path (even though it shouldn't according to cannot specify root sdk directory with syslibroot when linking)
So, removing this -syslibroot can solve our problem, this can be done in mexopts.sh. Copying matlab's version from the default location:
cp /Applications/MATLAB_R2011a.app/bin/mexopts.sh ~/.matlab/R2011a/
And then changing this line (201):
LDFLAGS="-Wl,-twolevel_namespace -undefined error -arch $ARCHS -Wl,-syslibroot,$SDKROOT -mmacosx-version-min=$MACOSX_DEPLOYMENT_TARGET"
Removing the -Wl,-syslibroot,$SDKROOT argument.
Additionally, I could remove the -L/usr/lib argument from the call to mex, making it simply:
mex('-v','-lOpenNI',['-I' OpenNiPathInclude],Filename);