support

Forum Replies Created

Viewing 15 posts - 6,616 through 6,630 (of 7,815 total)
  • Author
    Posts
  • in reply to: -fvisibility flags in VisualGDB #7368
    support
    Keymaster

    Please try adding the -fvisibility options to COMMONFLAGS, not CFLAGS.

    in reply to: User variables expansion in #7367
    support
    Keymaster

    This should already be supported. If it does not work, can you reproduce it on a “Hello, World” project and send the project archive to us?

    in reply to: ld returned 1 exit status #7366
    support
    Keymaster

    Please try adding -Wl,-verbose to the LDFLAGS and build your project again. Then check the build log for clues. If nothing helps, please try the black box approach – pick a project that links successfully and try eliminating the differences between that project and your current project one by one (source files, flags, softdevice, linker script) to see which one is causing the bug.

    support
    Keymaster

    Hi,

    We understand your frustration with the build. However the problem is that there are many libraries and platforms supported by VisualGDB, so if we wanted to ship prebuilt versions of various libraries, we would have to rise the VisualGDB license price or switch it to a subscription model, making it unacceptable for many users. Hence we decided to provide free cross-toolchains (that are especially tough to build), but leave building of third-party libraries not included in the distros to our users.

    Regarding the “48” suffix, most likely some of the headers is hardcoding this version and it did not get updated during sysroot resync. You can pinpoint it as follows:

    1. Search the object files (.o) for the ucnv_getStandardName_48 function name
    2. Once located one file, delete it and build Qt again with verbose mode on
    3. Find an copy the command line used to build the .o file
    4. Replace the -c with -E and .o with .E and run the command line manually
    5. The .E file will contain preprocessed .cpp file (having all macros expanded). Search for ucnv_getStandardName_48 in the .E file to see where it comes from.
    6. Use the comments in the preprocessed file to pinpoint which header is causing this.

     

    in reply to: Unexpected reply from ESP8266 #7354
    support
    Keymaster

    Hi,

    Can you try hardwiring GPIO0 to ground so that it’s always set to 0? Does that fix the bootloader synchronization?

    in reply to: QT5 toolchain error #7353
    support
    Keymaster

    Hi,

    Sure. If you encounter any problems, feel free to let us know.

    support
    Keymaster

    Hi,

    The Qt build does usually take a lot of time and multi-threaded build usually hangs due to a bug in MinGW. Sorry, this is a limitation of the MinGW-based toolchain and does not come from us.

    We do offer a service of building tricky libraries and tools for our customers. If you want to sponsor building and testing a Qt5 build for the latest Raspberry Pi image, please contact our sales for a quote. Otherwise feel free to share any problems you encounter while building it and we will help you overcome them.

    support
    Keymaster

    Hi,

    It looks like you compiled your program against libicu18n version 48 and then updated your Raspberry PI image to libicu18n version 52.

    Please delete the cross-compiled Qt, resynchronize the sysroot and build it again so that it is linked against version 52, not version 48.

    in reply to: Unexpected reply from ESP8266 #7344
    support
    Keymaster

    Hi,

    Strange. The boot mode should be “1,7” for the bootloader. Can you put breakpoints on the Sleep() calls after _Port.EscapeFunction() calls in the bootloader test program and check the state of GPIO0, GPIO2, GPIO15 and RESET at each sleep() call? Does it perform a device reset and does it hold the “UART Download Mode” (0/1/0) once reset is released?

    in reply to: Ninja Build #7343
    support
    Keymaster

    Hi,

    We don’t support it directly. However you can import a Ninja Build project to VisualGDB by selecting “Import a project built with other tools” in the wizard and specifying the build command line and the path to the built executable. VisualGDB will then invoke the command line you specified to build your project.

    in reply to: arm-elf toolchain corrupted? #7342
    support
    Keymaster

    OK, no problem. Let us know if you encounter problems with the arm-eabi toolchain.

    in reply to: There is an error in XML document #7339
    support
    Keymaster

    No problem. Enjoy VisualGDB!

    in reply to: QT5 toolchain error #7338
    support
    Keymaster

    Hi,

    The Qt framework has a bad habit of hardcoding various paths in the executables like qmake.exe, hence moving the toolchain to a different location would break everything.

    The easiest workaround would be to make a symlink from c:\SysGCC to d:\SysGCC:

    mklink /d c:\SysGCC d:\SysGCC

    This way your files will be physically located in d:\, but you can still use the c:\SysGCC path to access them.

    in reply to: XMC1100 Linking fails #7337
    support
    Keymaster

    Hi,

    Based on the log you provided it looks like the linker eliminates all code and data from the output image as it assumes it is all unused.

    You can resolve this by adding a KEEP statement to the declaration of the interrupt vector table in your linker script. This will mark the vector table as used and will in turn bring in the reset handler, main(), and the functions called by it. You will also need to explicitly specify the entry point in your linker script so that gdb can jump to it automatically after programming your FLASH.

    Please refer to our STM32 linker scripts for examples on the KEEP() statement and the entry point definition.

    in reply to: Build error during Pi Tutorial #7332
    support
    Keymaster

    Hi,

    Sorry to hear that. Building the kernel can be indeed tricky, but we tried to cover all the complexities in our kernel building tutorial. Did you encounter problems not mentioned there?

Viewing 15 posts - 6,616 through 6,630 (of 7,815 total)