support

Forum Replies Created

Viewing 15 posts - 7,276 through 7,290 (of 7,850 total)
  • Author
    Posts
  • in reply to: smarTTY connection failure #2669
    support
    Keymaster

    Hi,

    Note that we have added support for SSH key passhprases to SmarTTY 1.1 (http://smartty.sysprogs.com/download/)

    in reply to: SmarTTY and saving coinnections #2683
    support
    Keymaster

    Hi,

    Fixed in SmarTTY 1.1 (http://smartty.sysprogs.com/download/)

    in reply to: GDBServer on dynamic port #2829
    support
    Keymaster

    We have added support for dynamic port detection to VisualGDB 4.1r8. You can download it from http://visualgdb.com/download/VisualGDB-4.1r8-trial.msi
    Do use this feature please select “Debug with a custom GDB stub” on the Debug Settings page, then setup the stub as “gdbserver” with arguments “:0 $(TargetPath)”.
    Then click on “Setup advanced GDBServer settings” and specify the following settings:

    Wait to ensure the server starts: 5000 msec
    End waiting when the server outputs text: [yes]
    Regex: Listening on port ([0-9]+)
    Override GDBServer port: [yes]
    Regex group: 1

    With these settings VisualGDB will look for the ‘Listening on port …’ message, parse the port number in it and connect GDB to it.

    in reply to: Running GDB on the deployment machine (lose the gdbserver) #2849
    support
    Keymaster

    Hi,

    Using remote gdb for a binary built with a cross-compiled would not be straight-forward, so we would recommend using dynamic gdbserver port instead.
    Please see the reply in viewtopic.php?f=5&t=2839

    in reply to: Variable for user host #2841
    support
    Keymaster

    Hi,

    We looked more into this. Actually, you can simply use the COMPUTERNAME variable that is available on Windows XP and newer versions. Use $(COMPUTERNAME) in your commands in VisualGDB settings.
    Note that you can also use any other environment variables of the current Windows user (if a build variable with the same name exists, it will override the environment variable).

    in reply to: Multi target solution #2847
    support
    Keymaster

    Hi,

    You could exclude some source files by replacing this line in Makefile:

    all_source_files := $(SOURCEFILES)

    with this:

    all_source_files := $(filter-out $(EXCLUDED_FILES),$(SOURCEFILES))

    Then you can define EXCLUDED_FILES in your per-configuration .mak files to have those files excluded from build.

    Regarding configuration reuse, unfortunately there is no direct way. VisualGDB Project Properties editor is way more sophisticated than Visual Studio configuration editor and it heavily relies on the ‘current configuration’ concept (e.g. it substitutes configuration variables on-the-fly, allows browsing files on the currently selected remote machine, etc).
    However, you can use the following techniques to reuse some of the settings:
    1. VisualGDB Make Settings editor edits the .mak file for the current configuration, it does not regenerate it. You can move the common settings to a separate .mak file (e.g. CFLAGS += -ggdb) and include it from the configuration files.
    2. All VisualGDB settings are stored in -.vgdbsettings files. Those files are XML files generated by .Net serializer from public objects inside VisualGDB.EXE assembly. If you are dealing with plenty of configurations you may want to generate those on-the-fly. Using the .Net serializer it’s a very straight-forward process.
    3. VisualGDB supports an project extension mechanism that allows creating .Net extensions to automate things not directly supported by VisualGDB. We could extend it with a method to patch the project settings on-the-fly before building or debugging so that you could have only one .vgdbsettings file and a basic extension DLL that sets the architecture-specific parameters based on the platform.

    in reply to: visualGDB and externel MakeFile #2848
    support
    Keymaster

    In order for Visual Studio to edit your project files, the files need to be accessible from the Windows machine. You can either create a local copy and re-upload modified files each time, or share your project directory on Linux with Samba and mount it on Windows so that Visual Studio accesses them directly.

    Both options are available via the VisualGDB Project Wizard:
    1. On the first page select “Import a project built with command-line tools”
    2. On the third page select “The sources are already on “
    3. On the fourth page select how do you want to access the sources.

    in reply to: VisualGDB Compile Error internal or external command #2846
    support
    Keymaster

    Hi,

    Looks like the project your are trying to build depends on some Linux-style tools.
    You can actually install Cygwin, add Cygwin directories to PATH and try building it again using make.exe from cygwin. This should normally work, as cygwin provides most of Linux tools on Windows (ensure that you install the necessary packages).

    in reply to: GDBServer on dynamic port #2827
    support
    Keymaster

    Hi,

    Unfortunately it’s not currently supported, however we will add this feature in the upcoming maintenance release (4.1r8). Thanks for your feedback.

    support
    Keymaster

    Hi,

    We are aware of the first issue and will be releasing a fix in the next r release. It is safe to ignore the toolchain test fail and save the settings anyway as the issue is only with toolchain testing.

    For the second issue, in the Qt pro file both library names and directories are stored in the same location. VisualGDB displays them in different fields to allow custom editors such as folder browsing. In the debug.pro file, what is the value of the LIBS variable?

    in reply to: Runtime problem with Android libraries tutorial #2812
    support
    Keymaster

    Hi,

    We tried your project, for us the breakpoints were set both in the project and library files. Have you tried rebuilding the project?

    If you still experience issues with breakpoints, try the Android breakpoint issues tutorial for hints or submit us a full gdb log.

    support
    Keymaster

    Hi,

    It looks like the project is successfully built but fails to be deployed to Raspberry Pi. Try deploying manually to see if it fixes the problem.
    To do it, in Visual Studio go to Tools->SSH Host Manager and open a console using the Raspberry Pi connection. You can use the SCP menu to transfer the project’s executable from C:inetpubwwwrootFlashGrowDBFlashGrowDBDebug” to /tmp on Raspberry Pi.

    support
    Keymaster

    Hi,

    Thanks for finding that out. It looks like your GCC does not create a valid binary when being tested, but also does not return any error code and that confuses VisualGDB. Could you please press the “ignore” button in the error dialog and see whether a buildable project is created?

    in reply to: Error cross compiling Qt library for Raspberry #2830
    support
    Keymaster

    Hi,

    This looks like a bug in our toolchain. Thanks for reporting it, we will fix it in the next release. In the meanwhile please use the following workaround:
    1. Download mv.exe to SysGCCRaspberrybin
    2. Modify SysGCCRaspberryarm-linux-gnueabihfsysrootusrshareqt4mkspecsarm-linux-gnueabihfqmake.conf so that QMAKE_MOVE is set to mv:

    QMAKE_MOVE				= mv

    3. Create a file called ln.bat in SysGCCRaspberry with the following contents:

    copy /y %2 %3
    support
    Keymaster

    Hi,

    Could you please verify that the /tmp directory on your Raspberry PI device exists and is writable? You can check it by connecting to your Raspberry PI via SmarTTY and running the following command:

    ls -l / | grep tmp
Viewing 15 posts - 7,276 through 7,290 (of 7,850 total)