CMAKE_SYSTEM_PROCESSOR seems to be ignored

Sysprogs forums › Forums › VisualGDB › CMAKE_SYSTEM_PROCESSOR seems to be ignored

Tagged: 

This topic contains 6 replies, has 2 voices, and was last updated by  support 6 months, 4 weeks ago.

Log In Register Lost Password
Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • August 24, 2022 at 07:38 #33068

    Nomen.Nescio
    Participant

    I’m currently evaluating VisualGDB for cross-compiling. I try to compile existing software/libraries for Raspberry locally on Windows (Linux -> Import CMake-Project). Unfortunately, the information about the processor (here: arm6l) does not seem to be ascertainable or specifiable. E.g. on libjpeg-turbo-2.1.4: CMAKE reports an empty string: “CMAKE_SYSTEM_PROCESSOR”, although I tried to specify it in VARIOUS places:
    1. VisualGDB Project Properties | CMake Build Settings | Extra CMake Configuration Variables: “CMAKE_SYSTEM_PROCESSOR=arm6l”
    2. CMake command | Argument “-DCMAKE_SYSTEM_PROCESSOR=arm6l”
    3. In the solution explorer in the root file “toolchain.cmake” under the imported project:
    SET(CMAKE_SYSTEM_NAME Linux)
    **** set(CMAKE_SYSTEM_PROCESSOR arm6l) ****
    SET(VISUALGDB_TOOLCHAIN_TYPE Linux)
    SET(VISUALGDB_TOOLCHAIN_SUBTYPE GCC)
    SET(CMAKE_C_COMPILER “${TOOLCHAIN_ROOT}/bin/arm-linux-gnueabihf-gcc.exe”)
    4. Likewise in the solution explorer in the file of the same name “toolchain.cmake” under the link: build/VisualGDB/Debug
    Everything does not help, I do not understand that!
    The output appears:

    <hr />

    C:\Users\ XXX \AppData\Local\VisualGDB\CMake\bin\cmake.exe ../../.. -G “Ninja” -DCMAKE_BUILD_TYPE=DEBUG -DTOOLCHAIN_ROOT=C:/PRG/SysGCC/RPi-GCC-v8.2.1 -DCMAKE_MAKE_PROGRAM=”C:/Program Files (x86)/Sysprogs/VisualGDB/ninja.exe” -DCMAKE_TOOLCHAIN_FILE=C:\Users\ XXX \libjpeg-turbo-2.1.4\./build/VisualGDB/Debug/toolchain.cmake -DCMAKE_SYSTEM_PROCESSOR=arm6l

    — CMAKE_BUILD_TYPE = DEBUG
    — VERSION = 2.1.4, BUILD = 20220824
    CMake Error at CMakeLists.txt:60 (string):
    string no output variable specified

    — 32-bit build ()
    — CMAKE_INSTALL_PREFIX = /opt/libjpeg-turbo

    <hr />

    What am I doing wrong? Where would be the best place to specify the (target) processor? Why are there multiple entries for “toolchain.cmake” in Solution Explorer? Where can one set presets that should always be used for a toolchain (e.g. processor, which would be clumsy in this case because there are different RPi-ARMs)?

    I am thankful for every help.

    N.N.

    Attachments:
    You must be logged in to view attached files.
    August 24, 2022 at 21:28 #33072

    support
    Keymaster

    Hi,

    This looks like more of a generic CMake question than something specific to VisualGDB. Feel free to post it on CMake forums, if you get a CMake-specific advice, we can help you map it to particular VisualGDB settings. You can also dump the CMake command line used by VisualGDB to a batch file as shown here, and experiment by modifying the CMake command line directly instead of going through various VisualGDB settings. If you find a command line that works better, we can help you find VisualGDB settings that will replicate it.

    The CMake files shown in Solution Explorer (including multiple instances of toolchain.cmake) are reported by CMake via the cmakeFiles-v1-<ID>.json files. The one used by VisualGDB should have the path of C:\Users\ XXX \libjpeg-turbo-2.1.4\./build/VisualGDB/Debug/toolchain.cmake. You can try using our CMake debugger to find out which file references the second one.

    August 26, 2022 at 08:35 #33076

    Nomen.Nescio
    Participant

    I don’t think it’s due to CMake. Unfortunately, I can’t find the setting shown in the link (from an earlier version?): “Dump command line to batch file” There is also no option to choose between “Build” and “Configuration” (see figure).

    Attachments:
    You must be logged in to view attached files.
    August 26, 2022 at 09:16 #33078

    support
    Keymaster

    Unfortunately, it is hard to suggest anything specific based on the description you provided.
    In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
    Please provide complete and detailed steps to reproduce the issue as described below:

    1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
    2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
    3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

    You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

    Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

    You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.

    August 28, 2022 at 07:03 #33084

    Nomen.Nescio
    Participant

    I try it several times – it reproducible. Now with ALL steps an (hopefully) all necessary informations:

    Running Software Versions:
    Visual Studio Community 2017 (15.9.42)
    Visual GDB 5.5R5 (build 4124)

    My example code:

    libjpeg-turbo-2.1.4 (https://sourceforge.net/projects/libjpeg-turbo/files/2.1.4/)

    that has CMake configuration:

    So I tried to import a CMake-project:

    File | New Project | VisualGDB > Linux Project Wizard
    Name: libjpeg-turbo-2.1.4
    No Project map folder

    Import a project | Import a CMake project
    Build system Ninja
    Use the advanced CMak Project Subsystem

    Build the project locally with a cross-compiler
    Cross-toolchain: Paspberry Pi in: …
    Deployment computer: pi@…
    Deployment folder: /tmp
    Automatically test connetcion to … befor creating the project

    -> Connection checking: every thing ok

    Import CMake Project | New Linux Project
    Common Build Settings:
    Directory with CMakeLists.txt: [SELECTED] …\libjpeg-turbo-2.1.4
    CMake binary: [by VisualGDB: $(SYSPROGS_CMAKE_PATH)]
    Additional environment: [by VisualGDB: EMPTY]
    Build subdirectory: [by VisualGDB: build/$(PlatformName)/$(ConfigurationName)]

    Where the Variable PlatformName is defined? It seems to be now “VisualGDB” – thats a little bit confusing, because ARM or similar it should be?!

    Common Build Settings:
    Use existing CMAKE_TOOLCHAIN_FILE: [not checked by VisualGDB]

    Path mapping (advanced)
    Use toolchain default NO ENTRIES AND NOTHING CHANGED

    After click FINISH one get the following screen shot SS-01

    The VisualGDB Log-Window has the following lines:

    <hr />

    The CMakeOutput.log looks like:

    <hr />

    CMakeLists.txt around line 60 is (fragment):

    (…)

    ——————

    simd/CMakeLists.txt around line 5 is (fragment):

    (…)

    ——————

    simd/CMakeLists.txt around line 541 is (fragment):

    <hr />

    Now I make the following entry by my self: see screen shot SS-02

    Commandline is changing, but it still the same result, as one can seen in screen shot SS03

    Even I make an explicite an additional Argument for CMake command, as shown in screen shot SS04 – Command line is changing but not the result (screen shot SS05):

    I dont expect, that this error is from CMake and it is not specific to 3rd party code (even it is 3rd party code), because CMake will not get an necessary basis argument?!
    How and where can I find the menu entry that is recommandet in https://visualgdb.com/documentation/projects/cmake/#troubleshooting for dumping configuration commands in a batch file? I can’t find it in the VisualGDB Build window (as you can see in the screen shots)?

    I hope, that my description of the problem is now clear and understandable.

    Many thanks for your help!

    Attachments:
    You must be logged in to view attached files.
    August 28, 2022 at 07:05 #33089

    Nomen.Nescio
    Participant

    Unfortunately I couldn’t attach the screenshot SS-05 anymore, so it is here.

    Attachments:
    You must be logged in to view attached files.
    August 28, 2022 at 08:37 #33091

    support
    Keymaster

    Hi,

    The steps you provided involve importing a 3rd-party project. If you would like to get it working with VisualGDB, please make sure you can build it by running CMake/Ninja manually on the same machine using the same toolchain. If the project doesn’t build/work on your platform, it may need to be ported to it and VisualGDB cannot do it automatically.

    Once you get the manual build to work, please share:

    1. The manual CMake command line that produces a successful build
    2. CMake command line from the VisualGDB build log

    We can then help you adjust the VisualGDB settings to match the manual build command line that works.

    • This reply was modified 6 months, 4 weeks ago by  support.
  • Author
    Posts
Log In Register Lost Password
Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.