[support]

For GNU Make, the default log settings should already contain the necessary command lines.

Please try rebuilding the project and check the output for the line containing liblog4cplus.a. Simply post that line here and we will help you understand it.

[support]

Hi,

Thanks for the clarification. It looks like you have installed the new toolchain and then resynchronized its sysroot with an incompatible SD card image, thus, breaking the build process.

Please note that each toolchain is compatible with a specific version of the target system (see this page for a full list) and synchronizing it with a different target system version would lead to the problems you described.

If you are no longer sure which SD card image you are using, please try downloading the latest one listed on our toolchains page  and writing it to your SD card (this will replace the previous card contents). Then, install a toolchain that is compatible with that image. This should allow creating Qt projects correctly. Once you can confirm that the new projects work, you can install the necessary libraries (e.g. QtSerial) via apt-get and resynchronize the sysroot to make those libraries available to the cross-toolchain.

[support]

Unfortunately, as you have cropped the project properties window screenshot, it’s hard to see which build subsystem you are using and give specific advice.

Generally, the use of absolute paths vs. “-l” syntax should not affect the link outcome, as long as the libraries are found. Either way, the undefined reference to `log4cplus::Logger::~Logger()’ message means that the ~Logger() symbol is either missing, or the library providing it is specified outside the -start-group/-end-group pair (see this page for a discussion about linker groups).

Please try enabling the verbose build logs and double-check that the the library paths end up between the -start-group and -end-group arguments. If not, please let us know the build system you are using (Make/CMake/QMake/MSBuild) and we will help you find the relevant settings.

If the library is specified as expected, please check that the one of the source files in the library actually defines the ~Logger() symbol. You can read more about symbol declarations and definitions here: https://visualgdb.com/tutorials/tips/externc/

 

[support]

No problem. As soon as you renew your license, we should be able to help you further.

[support]

Hi,

This one unfortunately looks like a bug in gdb itself:

-var-create --frame 0 --thread 1 - * "Status"
^done,name="var23",numchild="1",value="{...}",type="CReturnCode",thread-id="1",has_more="0"
-var-list-children --simple-values "var23\.public" 0 5
bash: line 1: 25479 Segmentation fault (core dumped) /work/apm/crosstools/apm-aarch64/8.0.10-le/bin/aarch64-apm-linux-gnu-gdb -interpreter=mi --args uxx n=2

The easiest way to resolve this would be to try building a newer gdb from source code (it’s usually much easier than building the entire toolchain and just involves running ./configure –target=<…> and making sure you have libexpat available). Another option would be to try specifying another debug information format in build settings (e.g. DWARF-2 or DWARF-4) or simply avoiding the evaluation of the variable that triggers the crash.

[support]

No problem. We can help you track it down, however we would first kindly ask you to renew your license and update to the latest VisualGDB 5.4 as the issue you have might be specific to an older VisualGDB version.

[support]

Hi,

This looks like the libstdc++ library bundled with your GCC may not contain the implementations for some functions required by the library.

Please try building the library from sources using the same compiler. If you get c++11-related errors, the compiler does not provide the language support required by the library. If the build succeeds, the library should link to the main project without errors.

Also depending on your compiler’s multilib configuration, you may need to specify -std=c++11 to the linker flags (and also ensure you are using g++, not gcc to link).

[support]

Thanks for sharing the solution! We have updated the post.

[support]

Sorry, unfortunately there is no easy way to do this, as the Arduino build logic is handled by the Arduino builder and not directly by VisualGDB.

You should be able to extract the gcc command lines by parsing the VisualGDBCache\<Target>\CodeModel.json file, extracting the gcc arguments from there and running it manually with the -S option instead of -c, although that would require some scripting on your side.

[support]

Hi,

Looks like you forgot to specify the “–interpreter mi” argument in the gdb command line. This argument is required in order to enable the “machine interface” – a special mode where gdb produces machine-readable replies to commands instead of the regular text replies.

VisualGDB would normally handle this automatically for the regular debug configurations, however using the fully custom mode shown on the screenshot requires specifying it manually.

[support]

Hi,

It looks like the project has some leftovers from the previous BSP version, or previous configuration. Please try rebuilding it via Build->Rebuild All.

[support]

According to our records, the recent VisualGDB updates did not change anything that could be causing this issue.

You have also mentioned several different issues in this thread that would occur under different setups, so it is hard to understand what is going on based on your description.

Please try installing the toolchain from scratch and check whether creating a new Qt5-based project for the target works.

[support]

Hi,

According to our records, your support period has expired. In order to continue receiving technical support, please renew your key here. If you have purchased a different key with another email address, please let us know or update your forum profile.

[support]

It looks like your toolchain is not compatible with your target. As a workaround, please try building the code directly on the target.

[support]

Hi,

Sorry, but the only way to tell what is going on is to check the View->Output window as suggested by the second error message on the screenshot. It will show the detailed build log that should point to a specific part of the build that failed.

[Author]

Posts