Forum Replies Created
-
Posts
-
I actually found the TestFramework.mak file on my PC…its empty, created by VisualGDB surprisingly (I must have done a testframework for that too) and I added it to my svn and now the laptop is happy again.. But I would like to remove this dependancy, and just can find where to do that?
Reverting back to SCP transfer on the specific SSH connection for a device seems to have resolved it… maybe there’s an issue in your time checks?
That was my 1st thought, since the 3587 seconds is basically 1 hour out, and I am in the Netherlands using +1 from UTC, but both my main system and Raspberry target, take their time signals from the internet and are both set to UTC+1. So both are in the same time zone…its kinda strange.
I don’t seem to have Tools->VisualGDB->Manage SSH Connections->Per-host Settings as an option but I do have SSH Host manager, however it gives me no offsets or timestamp options
I am using VisualGDB 5.4 beta 2, 2675
I’ll have to leave this for a few days, as I need to focus on the on target builds that are working, but I will let you know how I get on with these steps.
ok I updated to 5.4 and also changed to a clean Raspberry 3B+ with a new version of Stretch, so everything is shiny and new.
1st issue, I had to install gdbserver onto the pi, it never needed it when I used it as the on target compile but ok.
I did a full resync with the new version of sysroot sync which is much faster, well done on speeding that up
But Im afraid now I can’t build my project as I get this error.
1> c:/sysgcc/raspberry/bin/../arm-linux-gnueabihf/sysroot/usr/lib/arm-linux-gnueabihf/libm.so: file not recognized: File truncated
1>collect2.exe : error : ld returned 1 exit status
1> make: *** [Debug/PiGauntlet] Error 1I did a new sysroot sync, and noticed this error throwing up a lot
Cannot create c:\SysGCC\raspberry\arm-linux-gnueabihf\sysroot/usr/lib\node_modules\node-red\node_modules\serialport\node_modules\node-pre-gyp\node_modules\npmlog\node_modules\gauge\node_modules\string-width\node_modules\is-fullwidth-code-point\node_modules\number-is-nan\package.json: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
Thats a bit of a problem, I think? Especially since I am unable to edit the sysroot location to a shorter name?
Im using the Raspberry Pi toolchain (latest version it seems) and a Jessie (with updates from stretch) image of Raspbian.
thanks for fixing that status mix up,
I did do a “reccomended” sysroot sync when I set up the project, and also tried a full sysroot sync when I first encountered the issue (indeed I realised it was some kind of mislink), so my sysroot current has a full copy of my image, and still I get the issue.
Am I missing any other VisualGDB cross compile settings I should have?
Hi
no my support ends on 16/03/2019 its registered in my university’s name under our purchase mananager, William van Nieuwburg, NHTV
hmmm the formatting is very strange, sorry can’t seem to fix it
the gist of it is
CXXABI_1.3.9 not found
GLIBCXX_3.4.21 not found
This only appears on a large project, a small test project doesn’t give any issues so I assume its looking for a couple of libs, but I don’t know how to set up VisualGDB to point to them?
The trial version is usually a full ultimate version, which after 30 days reverts to whichever license you choose. We noticed that some of our students used some of the advanced features at the start of their 30 days, only to find they lost them when reverting to a standard Linux build when they activated their licenses.
Hi
I’m building on the targets.
No, the setting in the VGDB properties is set to RemoteX11 windows not allowed. but setting to Display = 0 or Shown via XMing work either.
SmarTTY seems to work fine launched from the Visual Studio tool SSH manager, I’ve not tried it any other way.
The code compiles and starts up fine, but during my linux X11 display set up, I get to here
/*
* X11 native display initialization
*/x_display = XOpenDisplay(NULL);
if (x_display == NULL)
{
return ; // we need to trap this;
}where x_display is NULL causing a return (currently untrapped)
