Sysprogs forums › Forums › VisualGDB › Switching to cross compiling
- This topic has 15 replies, 2 voices, and was last updated 7 years, 8 months ago by support.
-
AuthorPosts
-
March 12, 2017 at 18:29 #10642Brian BeukenParticipant
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?
March 12, 2017 at 20:12 #10644supportKeymasterHi,
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/
March 12, 2017 at 22:46 #10650Brian BeukenParticipantThat sounds like an excellent solution, I’ll try that this week and update you.
March 20, 2017 at 17:51 #10720Brian BeukenParticipantIm 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 staIm not sure why it fails to find the files, any ideas?
- This reply was modified 7 years, 9 months ago by Brian Beuken.
March 21, 2017 at 01:27 #10726supportKeymasterPlease 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.
March 21, 2017 at 10:59 #10736Brian BeukenParticipantIt 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 statusBut, 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 7 years, 9 months ago by Brian Beuken.
March 21, 2017 at 11:28 #10738Brian BeukenParticipanthard 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 7 years, 9 months ago by Brian Beuken.
March 21, 2017 at 12:43 #10740Brian BeukenParticipantI 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 7 years, 9 months ago by Brian Beuken.
- This reply was modified 7 years, 9 months ago by Brian Beuken.
March 21, 2017 at 14:29 #10743Brian BeukenParticipantA 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?
March 22, 2017 at 22:25 #10754supportKeymasterHi,
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.
April 3, 2017 at 13:35 #10855Brian BeukenParticipantThank 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?
April 4, 2017 at 05:06 #10859supportKeymasterHi,
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.
April 4, 2017 at 19:46 #10863Brian BeukenParticipantHi
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?
April 5, 2017 at 04:58 #10868supportKeymasterHi,
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.
April 5, 2017 at 05:40 #10872Brian BeukenParticipantI 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.
- This reply was modified 7 years, 8 months ago by Brian Beuken.
-
AuthorPosts
- You must be logged in to reply to this topic.