Error Mapping Shared Libraries with Eclipse CDT and GDB - eclipse

I'm trying to debug a program using a Ubuntu 12.04 host and an ARM client with Eclipse Kepler, CDT, and GDB. The host is running GDB 7.4 and the client 7.0.1.
In my .gdbinit file I set sysroot /usr/local/arm-none-gnueabi/arm-none-linux-gnueabi/
However, when I try to debug I get the following error:
Warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
The target endianness is set automatically (currently little endian)
Error while mapping shared library sections:
/usr//lib/libstdc++.so.6: No such file or directory.
Error while mapping shared library sections:
/lib/libm.so.6: No such file or directory.
Warning: .dynamic section for "/usr/local/arm-none-linux-gnueabi/arm-none-linux-gnueabi/lib/libgcc_s.so.1" is not at the expected address (wrong library or version mismatch?)
Error while mapping shared library sections:
/lib/libc.so.6: No such file or directyory.
Error while mapping shared library sections:
/lib/ld-linux.so.3: No such file or directory.
I've searched this problem to death and can't seem to resolve it. Any answers would be most appreciated!

Related

Eclipse CDT 4.11.0 crashes with SWT library not found error

I am trying to get Eclipse 4.11.0 running on my RHEL 6.10 system but it crashes when I try to run it. It points me to a log file that states:
...UnsatisfiedLinkError org.eclipse.swt.internal.gtk.OS._cachejvmptr()V
I tried running it again and it crashed again with a different log file entry:
...UnsatisfiedLinkError Could not load SWT library
It was looking for:
~/.swt/lib/linux/x86_64/libswt-pi4-gtk-4924r25.so
but the only file in that directory was libswt-pi3-gtk-4924r25.so
I also found libswt-pi3-gtk-4924r25.so in eclipse/configuration/org.eclipse.osgi/458/0/.cp.
I removed my ~/.swt directory and ran it again. Once again I got:
...UnsatisfiedLinkError org.eclipse.swt.internal.gtk.OS._cachejvmptr()V
I noticed that it made the ~/.swt/… directory structure and put the libswt-pi3-gtk-4924r25.so file in it so I tried to run it again and it (not surprisingly) gave me the following:
...UnsatisfiedLinkError Could not load SWT library
Does this have something to do with the version of gtk that I'm running on my system? Why does eclipse include the libswt-pi3-gtk.4924r25.so library in their installation, then look for the libswt-pi4-gtk-4924r25.so library?
Installing libgthread resolved the issue for me (SLES15, GTK3).

Eclipse remote debugging arm-linux library

I am running:
Eclipse 3.8.1 (Build id: deb build).
On Ubuntu 16.04 LTS in a VM and UbuntuMATE 16.04 LTS on target Raspberry Pi 3.
gdb-multiarch(architecture set to arm in .gdbinit) locally andgdbserver` on the target.
Cross compilation and remote deployment is successful. However, there appears to be some library issue when I run on the remote target. Output from gdb-multiarch below (superfluous text removed):
GNU gdb (Ubuntu 7.11-0ubuntu1) 7.11 Copyright (C) 2016 Free Software
Foundation, Inc. License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html This GDB was configured as
"x86_64-linux-gnu".
Program stopped. 0x76fd7a40 in ?? () from
/home/fred/raspberrypi/rootfs/lib/arm-linux-gnueabihf/ld-2.23.so
Execution stops at main. However, it doesn't appear to stop due to a breakpoint. The stop appears to be the result of some library issue possibly and unresolved symbol (or something more serious) resulting in the ??.
I have set sysroot in the .gdbinit file to indicate where the shared libraries can be found. The StepIn, StepOut icons are hi-lighted in Eclipse, and I can read ARM registers if I press pause and see which core is being used to run the process (with process ID)!
After further resume & pause operations a segmentation fault occurs:
Program stopped. 0x76fe2e92 in ?? () from
/home/fred/raspberrypi/rootfs/lib/arm-linux-gnueabihf/ld-2.23.so
Program received signal SIGSEGV, Segmentation fault. 0x76fd905e in ??
() from
/home/fred/raspberrypi/rootfs/lib/arm-linux-gnueabihf/ld-2.23.so
Program terminated with signal SIGSEGV, Segmentation fault. The
program no longer exists.
Any ideas? (I am very much new to Linux as it probably shows.)
Thanks for the questions which have resulted in further exploration below:
In Eclipse I started GDB by selecting Debug Configuration and then choosing the remote configuration that I had set up.
The code is very simple, consisting of a stream operator to output some text and then a loop, however it is never reached. I think I have just managed to reproduce the issue from the command line. Incidentally I started the target going first. (Again superfluous text was removed for clarity.)
gdb-multiarch Hello_Raspberry_Pi
Reading symbols from Hello_Raspberry_Pi...done.
The target architecture is assumed to be arm
(gdb) target remote ubuntumate-pi
(gdb) target remote 192.168.0.12:2345
Remote debugging using 192.168.0.12:2345
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initialisers
and track explicitly loaded dynamic code.
0x76fd7a40 in ?? ()
(gdb) set architecture arm
The target architecture is assumed to be arm
(gdb) set sysroot /home/fred/raspberrypi/rootfs/lib/arm-linux-gnueabihf
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initialisers
and track explicitly loaded dynamic code.
(gdb)
The target side behaved as would be expected:
fred#UbuntuMATE-Pi:~/Hello_Raspberry_Pi$ gdbserver 192.168.0.7:2345 Hello_Raspberry_Pi
Process Hello_Raspberry_Pi created; pid = 17363
Listening on port 2345
Remote debugging from host 192.168.0.7
So perhaps Unable to find dynamic linker breakpoint function. is a big clue?
It would appear that I had defined Shared Libraries incorrectly. When I deleted this setting something closer to expected behaviour occurred. As shown below, however I there is still a warning that I would like to remove:
For help, type "help".
Type "apropos word" to search for commands related to "word".
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initialisers
and track explicitly loaded dynamic code.
0x76fd7a40 in ?? ()
Breakpoint 2, main () at ../src/Hello_Raspberry_Pi.cpp:18
18 cout << "I'm in the While loop and the value of variable i is: " << i << endl;
Breakpoint 1, main () at ../src/Hello_Raspberry_Pi.cpp:20
20 usleep(1000000); //wait for 1 seconds
So now Eclipse does breakpoint at main and permit stepping - finally!
I also faced problems similar to this, getting segmentation fault from ld.so. Did the following steps to fix it.
Install libc6-dbg package in both sysroot and target.
create a folder /lib/.debug in both sysroot and target.
copy /usr/lib/debug/lib/arm-linux-gnueabihf/ld-2.23.so to /lib/.debug in both sysroot and target.

Oprofile not finding libraries

I'm trying to use OProfile on Eclipse (3.8). The Juno version of oprofile didn't work, so I installed the Luna one. This one at least starts up, but can never find the libraries.
Here is the error:
ns3-dev-lena-profiling-debug: error while loading shared libraries: libns3-dev-lte- debug.so: cannot open shared object file: No such file or directory
profiled app exited with the following status: 127
I know that that means I need to add the library path. So I went to Profiling Tools Configurations, and specified the path under environmental variables as:
name: LD_LIBRARY_PATH
value: {workspace_loc:ns3dev2}/build (appended)
I manually checked and the library is located in the build folder. Furthermore, this library path works fine if I debug the same project instead (or run it...).
I've deleted the configuration and remade it, but it's the same error.
I also tried adding the same path to PATH instead of LD_LIBRARY_PATH, but that doesn't make any difference. (Just tried it for the hell of it).
Any thoughts?
Edit, I get the same problem on Eclipse 4.4 (Luna). I found the logs for the errors and the error is:
!ENTRY org.eclipse.linuxtools.oprofile.core 4 0 2014-10-27 12:33:07.200
!MESSAGE opreport process error output: warning: /no-vmlinux could not be found.

Issues with g++ and Eclipse on Linux - unresolved symbols

I am running Ubuntu 64bit version, and downloaded the latest 64bit Eclipse.
Installed g++ along with build-essential. Tested g++ to make sure it works from terminal, and it works fine.
alex#ubuntu:~/Desktop$ g++ test.cpp -o test
alex#ubuntu:~/Desktop$ ./test
Hello World!alex#ubuntu:~/Desktop$
However, trying to build simple C++ Hello Word project(one of the default projects that comes with Eclipse), I am getting error.
Description Resource Path Location Type
Program "g++" not found in PATH Preferences, C++/Build/Settings/Discovery, [CDT GCC Builtin Compiler Settings] options C/C++ Scanner Discovery Problem
I have added Environment variable named g++ with value /usr/bin/g++ and the above error went away, however, now I am getting unresolved errors, though project compiles and in the Console shows !!!Hello World!!!
Description Resource Path Location Type
Symbol 'endl' could not be resolved test_hello.cpp /test_hello/src line 13 Semantic Error
Symbol 'cout' could not be resolved test_hello.cpp /test_hello/src line 13 Semantic Error
Symbol 'std' could not be resolved test_hello.cpp /test_hello/src line 10 Semantic Error
Have I correctly entered Environmental variable ?? How can I get fix the "unresolved" error ?? Thanks !
When compiling there are two important things to consider:
1.) Is my path up-to-date with executables?
2.) Is my library path correct?
It appears you satisfy 1.) but not 2.)
The unresolved symbol error means that Eclipse cannot find your library via LD_LIBRARY_PATH or some other medium. It's attempting to locate the standard compiled C++ library.
How did you install g++?
Kindly do this and post the results:
Project > Properties > C/C++ Build > Environment
If everything there appears nominal, you can try
/sbin/ldconfig
which should hopefully re-parse your system library paths and might update your environment.

Running SimpleOpenNI and leJOS in same project

We have a project in which we want to control a Lego Mindstorms robot with the Microsoft Kinect sensor. We decided to use SimpleOpenNI with Processing to read the sensor and leJOS to control the robot for a simple reason: since both is in Java, we can specifiy a kind of RoboHandler and call its methods from the sensor reading class.
In order to achieve that, we downloaded the leJOS plugin for eclipse, created a new leJOS NXT project and put the processing and SimpleOpenNI libraries in the build path. Note that to use SimpleOpenNI, it is required an old processing version without Java.
Now the problem is, that when installing leJOS, it strictly requires a 32-bit Java JDK, so I had to download this and point to it at installation.
At this point, following build paths are in the project:
LeJOS NXT Runtime (which has among others java.awt classes)
core.jar (used to run Processing in eclipse)
SimpleOpenNI.jar
Having all this, and setting up a first Processing sketch like
import processing.core.*;
public class Test extends PApplet{
(....)
}
results in following error code:
Multiple markers at this line
- The type java.awt.event.MouseMotionListener cannot be resolved. It is indirectly referenced from
required .class files
- The type java.applet.Applet cannot be resolved. It is indirectly referenced from required .class files
- The type java.awt.event.MouseListener cannot be resolved. It is indirectly referenced from required .class files
- The hierarchy of the type FirstTry is inconsistent
- The type java.awt.event.FocusListener cannot be resolved. It is indirectly referenced from required .class files
- The type java.awt.event.KeyListener cannot be resolved. It is indirectly referenced from required .class files
When I downloaded the Processing without Java version, I wasn't able to choose from 32bit- or 64bit version. The SimpleOpenNI is installed as 64bit-version.
When adding the 64bit-JDK (eclipse workspace default) as workspace too, the error disappears, but when trying to run a sketch, following error gets printed in the console:
Invalid layout of java.lang.Thread at name
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (javaClasses.cpp:128), pid=9176, tid=8740
# fatal error: Invalid layout of preloaded class
#
# JRE version: 7.0_04-b22
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.0-b21 mixed mode windows-amd64 compressed oops)
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\Valentino\Desktop\workspaces\workspace_processing\RoboZeugs\bin\hs_err_pid9176.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#
So in my oppinion there is a problem with the JDK versions (32 and 64 bit), but there must be a way to handle this. Has anyone experience on this specific topic, maybe even with Kinect -> Mindstorms? Can anybody tell me what this error exactly means?
You're mixing classes that are designed to run with the JVM on the NXT brick (i.e. everything in classes.jar) with classes that are designed to run with a fully fledged JVM on the PC.
Don't do that. If you want to remote control an NXT, use pccomms.jar and everything else in lib/pc. But never add classes.jar or anything else in lib/nxt to the classpath when you're starting a Java program on your PC.
The error message about java.lang.Thread is probably due to the fact, that java.lang.Thread in classes.jar in by no means compatible with java.lang.Thread that comes with the JVM on your PC.