[Mustrum]

Hi lwwin,

Thanks for trying, but it didn’t seem to matter — the standalone download of SmarTTY behaved just the same.

You said that you installed SmarTTY standalone first, and then VisualGDB, and that worked fine with Xming. I assume that meant you could use VisualGDB on graphics output programs.

I am afraid that I am new enough at Linux and the X client/server operation that the problem may be something just a bit higher on the trouble shooting list than “did you turn on the computer?”, that isn’t written down anywhere because everybody knows that! So just to be painfully clear, what should I expect to see happen? This is the simplest mode it hasn’t worked in:

1. I run SmarTTY on my XP computer.

2. SmarTTy appears as a window, with the Linux command line prompt in it. It has already logged me in on the Linux side using SSH.

3. I can do anything I could do if I were connected to the Linux system directly, except any graphics. I can run commands, their output appears on the SmarTTy window just like I would expect. Anything command that puts the screen into graphics mode just looks as if it’s died. Nothing happens and the prompt doesn’t come back. Whatever program it launched is running though, and directing its output to the physical HDMI connector on the RaspberryPi board. I can see it by switching my monitor input, as I said.

I have insured that the path to the Xming executable is specified and correct.

Was there maybe something I had to do differently the first time I connected, when SmarTTY set up the public key authentication? I just had to enter the username and password, I don’t think there was much else on that screen. Could a bad path to Xming at that time keep causing an issue? Do I have to start the Xming server by itself first? Does Xming need some configuration that might not happen automatically. Its existence isn’t even referred to during the SmarTTY install that I remember.

I am really worried that I’m missing something as obvious as breathing here, is the point I’m trying to make. Nobody worry about insulting my intelligence. (Just to be clear, I did turn on both systems. 😉 )

[Mustrum]

Hi ket,

Thank you for the reply and the suggestion. Unfortunately, when I tried it, and several variations I could think of, but it still did not result in a successful link. Many of the variations in the order of directory in and library specifications did give the result that a different symbol was identified as being the one not found.

I did solve the problem in the end. I was aware of the possible problems with symbolic links and I had used the method that you suggested for copying files from the Raspberry Pi. But I noticed that some of the time, the error message produced referred to an unfound archive by an explicit full pathname. The reference was to archives that were in directories I had copied, and the PC directory I had copied them to was specified in the search path (specifically the LC:/RaspberryPi/usr/lib/arm-linux-gnueabihf directory), but on the Raspberry Pi, the path started at the root. This would only occur when I had got as far as getting the archive freetype to be included in the link, and I thought perhaps it somehow contained absolute path names for the archives it needed. This seemed to be the case, because when I made copies of those archives starting from the root directory on my PC, the link suddenly worked and produced a working executable file. So the problem seems to have been with the archives of the Raspberry Pi I was trying to link, and nothing to do with the toolchain I had loaded along with my VisualGDB trial, nor with the VisualGDB plugin. I probably would have got there eventually, but your comment about the default location for additional libraries to be placed got me thinking along those lines, so it probably saved me a week of frustration. Thanks.

[Author]

Posts