PDA

View Full Version : Qt Creator debugger doesn't find shared libraries (but the "Run" function does) Linux



megatron78
9th October 2014, 21:01
Hi,

All of my projects in Qt Creator 3.1.0 on Linux have a problem debugging with GDB. When I try to start the debugger, I get the well-known "error while loading shared libraries: libxerces-c.so.27: cannot open shared object file: No such file or directory." I have set the Build Environment for each project to set LD_LIBRARY_PATH to the correct path for the library, and I know it's correct because when I use the "Run" function, it runs fine. The other thing that's odd is that it debugs fine if I enable the "Run in terminal" checkbox under the project's Run Settings, but of course it runs in a separate terminal. I do not get this problem with Qt Creator 2.6.2. Anyone have a solution?

RHELinux 6.2
Qt Creator 3.1.0

davethomaspilot
12th September 2015, 22:46
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>

under


<data>
<variable>ProjectExplorer.Project.Target.0</variable>


and


<data>
<variable>ProjectExplorer.Project.Target.1</variable>


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.