I have the same problem, but only on one project.
In fact, it works fine with one "kit". I just cloned the kit for another target device. The only change I made was to change the IP address for the new target.
LD_LIBRARY_PATH is set to /usr/local/lib in the QtCreator "Run Environment" for both the kit that works and the one that doesn't.
I think all the run settings are identical between the kit that works and the one that results in a .so not being found when the debugger is started.
There's no problem if I just "Run" the application, instead of using the debugger. And, it runs fine locally on the remote host also.
This is going to be painful, if I can only debug by using a remote device with the same IP address. Any help, suggestions to further isolate the issue, or workaround would be appreciated.
Thanks!
This was with QtCreator 3.3.0
Added after 1 22 minutes:
I tried checking the debugger log, but I couldn't see anything about setting environment variables.
I also checked the xml from the project's .user file. I see the same:
<value type="QString">LD_LIBRARY_PATH=/usr/local/lib</value>
<value type="QString">LD_LIBRARY_PATH=/usr/local/lib</value>
To copy to clipboard, switch view to plain text mode
under
<data>
<variable>ProjectExplorer.Project.Target.0</variable>
<data>
<variable>ProjectExplorer.Project.Target.0</variable>
To copy to clipboard, switch view to plain text mode
and
<data>
<variable>ProjectExplorer.Project.Target.1</variable>
<data>
<variable>ProjectExplorer.Project.Target.1</variable>
To copy to clipboard, switch view to plain text mode
I'm guessing those are for the two kits
Added after 9 minutes:
Figured it out...
The "sticky" bit was set on /usr/bin/gdbserver. I set that on the problematic target when I needed to debug an application that needed to be run with root privileges. So, when QtCreator started gdbserver on the problem target, it was running as root. Not sure what the mechanism is for setting env variables, but apparently it was NOT setting it for user root, but the username I'd set up for that device (that's the right way to do it).
So, doing:
sudo chmod -s /usr/bin/gdbserver
Solved the problem for me.
Not sure if others having similar issues have done the same thing. I don't know a better way to remotely debug an application and start it with root privileges other than doing the sticky bit thing on gdbserver. There's no root account--locally, you just do "sudo this" or "sudo that". I just have to remember to change it back when I'm not needing to run with root privileges.
Bookmarks