Sysprogs forums › Forums › VisualGDB › Visual GDB error with shared librarys from remote machine
Tagged: shared libraries
- This topic has 8 replies, 2 voices, and was last updated 7 years, 5 months ago by support.
-
AuthorPosts
-
June 22, 2017 at 15:13 #11554JodoParticipant
Compiling from remote machine and execution from remote machine works. The error occurs when running the programs from the remote machine. I do not really know what caused this, it seems like it “just happened”.
Error messages are:
Usage: ld.so [ OPTION ]… EXECUTABLE-FILE [ ARGS-FOR-PROGRAM… ]
You have invoked ‘ld.so’, the helper program for shared library executables.
This program usually lives in the file ‘/lib/ld.so’, and special directives
in executable files using ELF shared libraries tell the system’s program
loader to load the helper program from this file. This helper program loads
the shared libraries needed by the program executable, prepares the program
to run, and runs it. You may invoke this helper program directly from the
command line to load and run an ELF executable file; this is like executing
that file itself, but always uses this helper program from the file you
specified, instead of the helper program file specified in the executable
file you run. This is mostly of use for maintainers to test new versions
of this helper program; chances are you did not intend to run this program.–list list all dependencies and how they are resolved
–verify verify that given object really is a dynamically linked
object we can handle
–inhibit-cache Do not use /etc/ld.so.cache
–library-path PATH use given PATH instead of content of the environment
variable LD_LIBRARY_PATH
–inhibit-rpath LIST ignore RUNPATH and RPATH information in object names
in LIST
–audit LIST use objects named in LIST as auditorsChild exited with status 127
Or when starting a Programm with an argument:
my_argument: error while loading shared libraries: my_argument: cannot open shared object file: No such file or directory
Any idea what could cause the error? Please ask, if more information is needed and I try to provide it as best as possible!
June 22, 2017 at 18:53 #11558supportKeymasterIt looks like you are trying to debug the system linker application instead of your own application.
Please check the debug page of VisualGDB Project Properties and ensure you debug the $(TargetPath) instead.
June 26, 2017 at 12:21 #11577JodoParticipantIt seems like that is not the issue. Here is my Debug Settings Page: https://www.dropbox.com/s/ksv56yj717b8byd/config_debug.JPG?dl=0
June 26, 2017 at 17:32 #11578supportKeymasterHi,
Strange. The first step for diagnosing this would be to understand which component causes this message. Do you get it in the “GDBServer” window in Visual Studio, or elsewhere? If you are not sure, please simply attach a screenshot.
June 28, 2017 at 09:13 #11602JodoParticipantYes I get it in the GDBServer Windows (VisualGDB Programm Output). I uploaded both outputs Programm and Luncher to dropbox:
https://www.dropbox.com/s/72xh7p5bh70ejw8/visualgdb%20launcher%20output.JPG?dl=0
https://www.dropbox.com/s/fj0bdyoif0rk1yz/visualgdb%20program%20output.JPG?dl=0
June 28, 2017 at 19:53 #11607supportKeymasterHi,
The “launching custom program console” could be related. Please check the corresponding setting under VisualGDB Project Properties -> Custom Debug Steps. You might be accidentally launching ld.so as the custom console command.
June 30, 2017 at 07:38 #11626JodoParticipantI don’t have any “Custom Debug Steps” Categorie. The one closest would be “Additional GDB Commands”? This is empty.
June 30, 2017 at 12:33 #11627JodoParticipantAn Update, it seemed to be a problem of the target system. I set up a fresh target system and put everything back together (basically the same as before) and now it works again. What bugs me so is, that I am not sure what the issue was with the old system…
July 1, 2017 at 04:35 #11629supportKeymasterHi,
Normally, checking the VisualGDB Diagnostics Console for the exact list of commands executed by VisualGDB adn re-running them manually should explain what is going on. Most likely some of the system tools (like gdbserver) got corrupt and resulted in invoking ld.so instead.
-
AuthorPosts
- You must be logged in to reply to this topic.