[Brian Beuken]

hmm Im rather commited to using Bullseye now as it has some features I need to use.. What version of the Raspberry OS do you know works?

 

 

[Brian Beuken]

hmmm thats disspointing, I would rather expect it to fully support NDK based c++ dev. I only basically need to create a boot system so I can then do C++

I did discover I had a version of android preinstalled on my “new” PC, which was outdated and causing confusion,  and once I reset the dirs to point at the latest SDK I did get the sample to build, but not deploy….yet. to an emulator or a device.

In my case I am trying to set up a project on the Oculus quest2, have you any advice on steps to do that?

[Brian Beuken]

updating Visual GDB to 5.5P7 seems to resolve the issue….

[Brian Beuken]

Ah I see, I was hoping it was a rather generic ARM toolchain that could be configured with cc options.

Thanks for the clarification.

[Brian Beuken]

found it.

I figured it had to be something to do with access rights somewhere, so I went to the settings and checked the Securty and Privacy->Password settings. I didn’t see anything odd there, but while I was in I switched to autolog on.

Guess what.. that solves it.. My projects now happily build and run and can be executed from my VisualGDB debug command.

To double check I set autologin back to off and sure enough my VisualGDB failed again

So the secret is… ensure you have automatic login, with your matching ssh username

Bizzare issue…Dunno why this is happening, but very happy I resolved it.

If anyone else is using an Ubuntu 18.04 system and fails to get an Xwindow to open, this may be the cause.

[Brian Beuken]

Ok I’ll update you if I make progress.I noted the issue on Nvidias forums as well, so given that lots of people are doing graphic work  on these boards someone must be also using an ssh connection to develop.

 

 

[Brian Beuken]

If I open a terminal on the Jetson itself, navigate to the tmp\VisualGDB\c…etc folder

and ./runnablebuild

it runs perfectly, of course its running stand alone

If I use VisualGDB I get no X11 display and project fails trying to use a NULL pointer I added a Fail output on no display, and exit

If I use VisualGDB’s SSH manager and a SmarTTY console, I get the same fail

If I use Putty to navigate to the folder and do ./runnablebuild it also fails for the same reasons and exits

So any attempt to run from SSH seems to fail..

I agree it seems to be an issue with the target, but do you have any tips where I can try to find out why a display cannot be opened. I haveused Xhost +, ensured X11Forward is set
Thats as much info as I can locate online

[Brian Beuken]

ok I’ll keep trying and report back if I find a solution, but it really is troubling this has happened on a few Ubuntu systems and means I can’t use VisualGDB on those systems. Until this is resolved.

 

[Brian Beuken]

I’ll install putty, but can you walk me through what you want me to do? Just navigaing to the directory and using ./ gives a segmentation fault, so I assume that also means that it was unable to get a display?

Is there something else I should do?

 

[Brian Beuken]

So after checking around, I was told to check that /etc/ssh/sshd_config had X11Forwarding set to yes

it was.

 

So I am at a loss, I can build test projects on the Jetson no problem and they all build and run fine.. XDisplay is opened with no issue, I can even build them from VisualGDB,  and execute them, but when run any attempt to open an Xwindow on Ubuntu 18.04 fails…. This is only happening when I try to run from VisualGDB actually running them from a terminal on the target, they run fine. So there has to be something going wrong somewhere? I accept you are only sending a request for forwarding but is there anything else that needs to be set on Ubuntu? Or something that would corrupt that request?

 

• This reply was modified 4 years, 10 months ago by Brian Beuken.

[Brian Beuken]

hmm ok but I can’t locate any information that will explain this… I will attempt to do a non GDB build and see what happens

[Brian Beuken]

incidently if I set the debug option LinuxGUI(X11)  to Forward to Windows… The call to XOpenDisplay does indeed return a valid value, but I have no XMing ability on my system, so VistualGDB does seem to have some impact on the XOpenDisplay function?

[Brian Beuken]

Well it does seem to relate to VisualGDB, why would it fail to open an Xwindow when run from GDB and yet happily open it when run from the terminal?

 

[Brian Beuken]

Hi again, returning to this as it is now showing up on my Jetson Nano with Ubuntu 18.04, it does seem to be mostly an issue with Ubuntu systems, though xhost + and sometime sinstalling Xorg-dev usually fixes it.

For this instance, I’ve done xhost +, Xorg and Xorg-dev are in place but when I try to deploy in debug mode via Visual GDB XOpenDisplay(NULL) still returns null and I am unable to open a window. And my program stops as it can’t continue without an Xdisplay

However… if I go to the Jetson and open a terminal, navigate to the folder containing the deployed build… and use  ./runnablebuild
The project works perfectly (though of course there’s no gdb working to get info or stop it)

I have the Linux Gui (X11) set to show on target and as per the warning, I am logged in as brian, and xhost+ has been entered to avoid blocks..

Any ideas what this might be, its rather a pain to not be able to deply and run?

 

[Brian Beuken]

There’s no reference in any of the make files to TestFramework but it always fails on this line

 

include $(ADDITIONAL_MAKE_FILES)

 

But where is it referencing Additional files?

 

[Author]

Posts