2022-01-26 09:40 AM
When I try to run the gdbserver included with cubeIDE the program reports it's missing "_Z19STLink_GetLibApiVerv", as in it cannot lookup the symbol within the binary.
I encountered this error with both 1.7.0 and 1.8.0.
I'm not sure if my LD_LIB_PATH is set correctly. Is anyone else getting this.
It *was* working just fine. I must have installed something that mangled the environment, but have no idea where to start resolving this.
There seems to be an issue with Visual Studio Code that is causing this.
Solved! Go to Solution.
2022-02-03 12:27 AM
The user is not intended to add anything to the LD_LIBRARY_PATH to get CubeIDE running.
LD_LIB_PATH could override the search order for libraries.
A CubeIDE installation bundles multiple versions of ST-LINK libraries since it includes multiple tools which may not use the same ST-LINK library version.
By setting LD_LIB_PATH, maybe the incorrect library version is selected when launching ST-LINK GDB server?!
This is just a theory. But, not totally unlikely. You solved it yourself, so I think we will leave it there and consider solved.
2022-02-02 03:43 AM
Were you able to solve this? Sounds like an issue on your system only.
2022-02-02 09:39 AM
It appears to be an issue with LD_LIBRARY_PATH. If CubeIDE is added explicitly to the path, the libraries fail to load with the above error.
If LD_LIBRARY_PATH does not include the CubeIDE, or is blank, everything works as expected.
Very confusing issue.
2022-02-03 12:27 AM
The user is not intended to add anything to the LD_LIBRARY_PATH to get CubeIDE running.
LD_LIB_PATH could override the search order for libraries.
A CubeIDE installation bundles multiple versions of ST-LINK libraries since it includes multiple tools which may not use the same ST-LINK library version.
By setting LD_LIB_PATH, maybe the incorrect library version is selected when launching ST-LINK GDB server?!
This is just a theory. But, not totally unlikely. You solved it yourself, so I think we will leave it there and consider solved.