Switching to cross compiling

Sysprogs forums Forums VisualGDB Switching to cross compiling

This topic contains 15 replies, has 2 voices, and was last updated by  support 1 year ago.

Viewing 15 posts - 1 through 15 (of 16 total)
  • Author
  • #10642

    Brian Beuken

    For education purposes I’ve been forcing my students to compile on their target systems (raspberry pi). This was to allow them to understand the benefits of wrapping and to increase awareness of compile times which are far more obvious on the targets.

    I am about to introduce cross compiling but wonder if there is a simple way to convert a VGDB project from target based to cross compile?





    You can try adding a new cross-compiler-based Linux configuration to an existing project as shown in this tutorial: https://visualgdb.com/tutorials/porting/linux/


    Brian Beuken

    That sounds like an excellent solution, I’ll try that this week and update you.



    Brian Beuken

    Im having a few problems I wonder if you can advise

    I sent up a cross compiling configuration and Synced sysroot to include all my relevent directories

    The compiler builds ok but the linker fails as its unable to find the 1st 3 of these libs GLESv2 EGL bcm_host pthread openal alut

    The directory (/usr/lib/arm-linux-gnueabihf) containing libGLESv2_static.a  and .so have been copied to my dev PC ok

    but the toolchain test fails with

    Tool arguments: -Wl,–start-group “C:\Users\Brian Beuken\AppData\Local\Temp\/VisualGDB_ToolchainTestProgram.o” -o “C:\Users\Brian Beuken\AppData\Local\Temp\/VisualGDB_ToolchainTestProgram” -Wl,-gc-sections -L/opt/vc/lib -L/usr/lib/arm-linux-gnueabihf -lGLESv2 -lEGL -lbcm_host -lpthread -lopenal -lalut -Wl,–end-group
    d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe: cannot find -lGLESv2
    d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe: cannot find -lEGL
    d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe: cannot find -lbcm_host
    collect2.exe: error: ld returned 1 exit sta

    Im not sure why it fails to find the files, any ideas?

    • This reply was modified 1 year, 1 month ago by  Brian Beuken.


    Please try enabling the verbose mode for the linker (add -Wl,-verbose to the LDFLAGS) to see a detailed log on the paths checked by the linker when it attempts to locate those files. This should explain why they are not found.


    Brian Beuken

    It provides a very long list of directories it attempt so find the missing files in .a and .so formats, and then reports a fail


    attempt to open failed
    attempt to open /opt/vc/lib/libGLESv2.so failed
    attempt to open /opt/vc/lib\libGLESv2.a failed
    attempt to open /usr/lib/arm-linux-gnueabihf/libGLESv2.so failed
    attempt to open /usr/lib/arm-linux-gnueabihf\libGLESv2.a failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/libGLESv2.so failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9\libGLESv2.a failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/libGLESv2.so failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf\libGLESv2.a failed
    attempt to open d:/sysprogs/bin/../lib/gcc/libGLESv2.so failed
    attempt to open d:/sysprogs/bin/../lib/gcc\libGLESv2.a failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/lib/libGLESv2.so failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/lib\libGLESv2.a failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/lib/arm-linux-gnueabihf/libGLESv2.so failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/lib/arm-linux-gnueabihf\libGLESv2.a failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/lib/libGLESv2.so failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/lib\libGLESv2.a failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/usr/lib/arm-linux-gnueabihf/libGLESv2.so failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/usr/lib/arm-linux-gnueabihf\libGLESv2.a failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/usr/lib/libGLESv2.so failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/usr/lib\libGLESv2.a failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/q/gnu/linux/raspberry-jessie/out/arm-linux-gnueabihf/lib/libGLESv2.so failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/q/gnu/linux/raspberry-jessie/out/arm-linux-gnueabihf/lib\libGLESv2.a failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/usr/local/lib/libGLESv2.so failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/usr/local/lib\libGLESv2.a failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/lib/libGLESv2.so failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/lib\libGLESv2.a failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/usr/lib/libGLESv2.so failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/usr/lib\libGLESv2.a failed
    attempt to open /opt/vc/lib/libEGL.so failed
    attempt to open /opt/vc/lib\libEGL.a failed
    attempt to open /usr/lib/arm-linux-gnueabihf/libEGL.so failed
    attempt to open /usr/lib/arm-linux-gnueabihf\libEGL.a failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/libEGL.so failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9\libEGL.a failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/libEGL.so failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf\libEGL.a failed
    attempt to open d:/sysprogs/bin/../lib/gcc/libEGL.so failed
    attempt to open d:/sysprogs/bin/../lib/gcc\libEGL.a failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/lib/libEGL.so failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/lib\libEGL.a failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/lib/arm-linux-gnueabihf/libEGL.so failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/lib/arm-linux-gnueabihf\libEGL.a failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/lib/libEGL.so failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/lib\libEGL.a failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/usr/lib/arm-linux-gnueabihf/libEGL.so failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/usr/lib/arm-linux-gnueabihf\libEGL.a failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/usr/lib/libEGL.so failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/usr/lib\libEGL.a failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/q/gnu/linux/raspberry-jessie/out/arm-linux-gnueabihf/lib/libEGL.so failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/q/gnu/linux/raspberry-jessie/out/arm-linux-gnueabihf/lib\libEGL.a failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/usr/local/lib/libEGL.so failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/usr/local/lib\libEGL.a failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/lib/libEGL.so failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/lib\libEGL.a failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/usr/lib/libEGL.so failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/usr/lib\libEGL.a failed
    attempt to open /opt/vc/lib/libbcm_host.so failed
    attempt to open /opt/vc/lib\libbcm_host.a failed
    attempt to open /usr/lib/arm-linux-gnueabihf/libbcm_host.so failed
    attempt to open /usr/lib/arm-linux-gnueabihf\libbcm_host.a failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/libbcm_host.so failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9\libbcm_host.a failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/libbcm_host.so failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf\libbcm_host.a failed
    attempt to open d:/sysprogs/bin/../lib/gcc/libbcm_host.so failed
    attempt to open d:/sysprogs/bin/../lib/gcc\libbcm_host.a failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/lib/libbcm_host.so failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/lib\libbcm_host.a failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/lib/arm-linux-gnueabihf/libbcm_host.so failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/lib/arm-linux-gnueabihf\libbcm_host.a failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/lib/libbcm_host.so failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/lib\libbcm_host.a failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/usr/lib/arm-linux-gnueabihf/libbcm_host.so failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/usr/lib/arm-linux-gnueabihf\libbcm_host.a failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/usr/lib/libbcm_host.so failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/usr/lib\libbcm_host.a failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/q/gnu/linux/raspberry-jessie/out/arm-linux-gnueabihf/lib/libbcm_host.so failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/q/gnu/linux/raspberry-jessie/out/arm-linux-gnueabihf/lib\libbcm_host.a failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/usr/local/lib/libbcm_host.so failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/usr/local/lib\libbcm_host.a failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/lib/libbcm_host.so failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/lib\libbcm_host.a failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/usr/lib/libbcm_host.so failed
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/usr/lib\libbcm_host.a failed
    attempt to open /opt/vc/lib/libpthread.so failed
    attempt to open /opt/vc/lib\libpthread.a failed
    attempt to open /usr/lib/arm-linux-gnueabihf/libpthread.so failed
    attempt to open /usr/lib/arm-linux-gnueabihf\libpthread.a failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/libpthread.so failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9\libpthread.a failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/libpthread.so failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf\libpthread.a failed
    attempt to open d:/sysprogs/bin/../lib/gcc/libpthread.so failed
    attempt to open d:/sysprogs/bin/../lib/gcc\libpthread.a failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/lib/libpthread.so failed
    attempt to open d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/lib\libpthread.a failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/lib/arm-linux-gnueabihf/libpthread.so failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/lib/arm-linux-gnueabihf\libpthread.a failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/lib/libpthread.so failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/lib\libpthread.a failed
    attempt to open d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/usr/lib/arm-linux-gnueabihf/libpthread.so succeeded
    opened script file d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/usr/lib/arm-linux-gnueabihf/libpthread.so
    opened script file d:/sysprogs/bin/../arm-linux-gnueabihf/sysroot/usr/lib/arm-linux-gnueabihf/libpthread.so
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/lib/arm-linux-gnueabihf/libpthread.so.0 succeeded
    /lib/arm-linux-gnueabihf/libpthread.so.0 (d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/lib/arm-linux-gnueabihf/libpthread.so.0)
    attempt to open d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/usr/lib/arm-linux-gnueabihf/libpthread_nonshared.a succeeded
    d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe: cannot find : Invalid argument
    d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe: cannot find -lGLESv2
    d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe: cannot find -lEGL
    d:/sysprogs/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe: cannot find -lbcm_host
    collect2.exe: error: ld returned 1 exit status


    But, the files are indeed in place on my laptop in D:\SYSProgs\arm-linux-gnueabihf\sysroot\opt\vc\lib

    which is where the synchronisze sysroot put the directories, the list of failed directies does not include

    d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/opt/vc/lib  int its searches. Am I missing something obvious here?



    • This reply was modified 1 year, 1 month ago by  Brian Beuken.

    Brian Beuken

    hard coding the directories and removing the short names does allow it to compile, but the linker then reports a issue  related to an unresolved reference to

    vchiq_release_message in bcm_host


    Im going to attempt a complete upload of the Pi’s directories to see if that resolves this but it is confusing, that I cannot simply use synchronise sysroot, and have it look at the library directories and produce the correct settings?


    edit, a full sync of the entrie dir structure, short lib names still not found

    adding full path names, allows compile but link throws up countless undefined references

    So still unablet to successfully link or deploy to target.



    • This reply was modified 1 year, 1 month ago by  Brian Beuken.

    Brian Beuken

    I made some progress which may help others.

    I decided to update my Raspberry pi toolchain (do this without a project loaded) and clean my PC side directories, then allow the suggested directories on sync sysroot to download to my PC

    at the end of the sync, I was informed some functions were not compatible with windows and was offered a fix, which I accepted.
    But sadly on 1st attempt to build, with short file names it still was unable to locate GLESv2 EGL and bcm_host, it just ffailed to find the ..\opt\vc\lib dir.

    I removed the short names and provided full directory names in the additional linker options and that passed the tool change test, but an attempt to compile for deploy, only provides a large list of DSO missing errors mostly coming from bcm_host.so but I was able to locate and add so it now looks like this

    D:\SYSProgs\arm-linux-gnueabihf\sysroot\opt\vc\lib\libGLESv2.so D:\SYSProgs\arm-linux-gnueabihf\sysroot\opt\vc\lib\libbcm_host.so D:\SYSProgs\arm-linux-gnueabihf\sysroot\opt\vc\lib\libEGL.so D:\SYSProgs\arm-linux-gnueabihf\sysroot\opt\vc\lib\libvchiq_arm.so d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/opt/vc/lib/libvcos.so


    I then realised that perhaps linking the static.a files was a mistake  and switched to .so file

    Finally, this worked, my project now does indeed compile and deploy, and run.

    It turns out with all .so files I didn’t need to add the 2 apparently missing DSO’s D:\SYSProgs\arm-linux-gnueabihf\sysroot\opt\vc\lib\libvchiq_arm.so d:\sysprogs\bin\../arm-linux-gnueabihf/sysroot/opt/vc/lib/libvcos.so

    it does deploy and run now, though I have not worked out how to send my projects assets to the target? There seems to be no auto synchronization process for that as exists on the build on target options?






    • This reply was modified 1 year, 1 month ago by  Brian Beuken.
    • This reply was modified 1 year, 1 month ago by  Brian Beuken.

    Brian Beuken

    A final comment, which I hope will help others

    Sending assets is done via the Custom build step settings, actually quite painless once I found it. You can do it before the build

    Also setting up an MSbuild config, rather than a GCC config is way easier, GCC is just too fussy,  MSbuild, allows use of short lib filenames and had little issues getting it set up, though do be aware if where you deploy it, on the target, it defaults to /tmp  I changed it to /tmp/obj and then let my assets transfer  into /tmp
    this is more compatible with  an on target built  file structures which assumes your obj is running in a debug folder allowing you to do a step ../ back then into your Resource directories.

    I can now easily swap between on target build  and cross compile configurations as needed.

    MSbuild is also blindingly fast compared to gcc
    Sorry if this has been a strange incoherent set of posts 😀

    It would be nice if Sysprogs could provide some automation of converting an on target build to cross compile build, any chance we might see that or is it there and I missed it?




    Just wanted to let you know that instead of hardcoding the library paths, we would recommend adding “=/opt/vc/lib” to the “library search path” field.

    Regarding the project conversion, the easiest way to do that is to add another configuration and copy the settings there. As switching large projects between direct and cross-build looks like a relatively rare scenario, we don’t want to add a specific fully-automatic command for it. That said, if we get more requests for this feature, we will reconsider this.


    Brian Beuken

    Thank you, yes indeed using the = to append the dir to the sysroot is much cleaner, also important to remember that MSbuild expects semi colons as seperators when you enter in the libs.


    I do feel that if you are creating a new configuration in a project it should be possible to transfer your directory structure and library names to the new config as a default, could that be added.


    A final question, When I create a new config, I find that I now have multiple configs for all my builds, including the on target ones, win32 and Visual GDB, why does the wizard produce these, I noticed if I deleted the win32 ones it had a catastrophic result, bu I find having so many configs generated when I only expect 3 (on target debug, on target release, cross debug) to be confusing?





    Please use the VisualGDB Project Properties window to create new configurations. It will ensure that all the settings get copied properly.

    The Win32/VisualGDB platforms is a side effect of the way Visual Studio manages configurations/platforms. The MSBuild-based projects use the “VisualGDB” platform name, while the rest (e.g. Make-based) use Win32. If you are only using MSBuild, you don’t need the Win32 platform and can normally delete it. If your project uses both MSBuild and non-MSBuild build systems in different configurations, you will have 2 separate copies of each configuration (one for Win32 and one for MSBuild) due to VS limitations.


    Brian Beuken


    ok thanks for explaining the configs. I won’t delete anything just in case things break


    The copying of settings only works if you are using the add to current config, I prefer to use GCC for my on target builds, and MSbuild for my Remote builds, but creating a new MSbuild, of course sets up a blank list of settings. Is there a way to import and convert where needed the Gcc settings?




    You can convert non-MSbuild projects to MSBuild via right-clicking in Solution Explorer, but not back.

    BTW, is there any reason why you don’t want to use MSBuild for remote projects? We have thoroughly optimized it to be fast and efficient in both modes (for remote builds it actually generates a temporary Makefile and runs Make on the Linux side), so we recommend it for all new projects.


    Brian Beuken

    I don’t really want to convert my non ms build…so we are at a stalemate. So best to just hand copy directory and lib names over.

    If I’m honest I don’t have good defend-able reasons for preferring GCC on remote builds,  other than I find the set up and addition of parameters much easier with GCC, and in turn its easier to explain the workings to my students.  MS build requires I have to go into VS properties to alter some things when I need to change the build, GCC tends to have it all accessible through VisualGDB properties.  When all said and done, I am not someone who jumps to change too quickly even if there are benefits, GCC on target is familiar and clear to me, I like the error and warning levels more and I am actually quite interested in how long files take to compile to demonstrate good code/file structure.
    MSbuild hides too much even though I am sure it will be faster and have more benefits (like allowing VS dependency to work). Ironically I much prefer MSbuild for my PC based cross compiles. I guess its just down to preference and taste.


    I will try it though…promise.



Viewing 15 posts - 1 through 15 (of 16 total)

You must be logged in to reply to this topic.