Visual GDB error with shared librarys from remote machine

[Jodo]

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 auditors

Child 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!

 

• This topic was modified 6 years, 10 months ago by Jodo.
• This topic was modified 6 years, 10 months ago by Jodo.

[support]

It 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.

[Jodo]

It seems like that is not the issue. Here is my Debug Settings Page: https://www.dropbox.com/s/ksv56yj717b8byd/config_debug.JPG?dl=0

[support]

Hi,

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.

[Jodo]

Yes 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

[support]

Hi,

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.

[Jodo]

I don’t have any “Custom Debug Steps” Categorie. The one closest would be “Additional GDB Commands”? This is empty.

[Jodo]

An 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…

[support]

Hi,

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.

[Author]

Posts