due to other work processes I like to work with Visual Studio via remote compiling.
Therefore i need gcc and gdb on my colibri.
I tried the following:
opkg install gdb
opkg install gcc
I can see via opkg list-installed that gcc an gdb are installed.
gcc - 7.2.0-r0.0
gdb - 8.0-r0.0
When i try gdb from the console it seems to work fine, but when i try to run gcc from the console the machine says:
-sh: gcc: not found
When i search for gcc on the system it didnt find anything. So i think something went wrong with the installation.
I have the following OS-Version
Static hostname: colibri-imx6ull
Icon name: computer
Machine ID: b9dbfface73c4e1d935c090f9d157525
Boot ID: 6d21af42d3d84fa8a9a3e6faa447c379
Operating System: The Ångström Distribution v2017.12
Kernel: Linux 4.9.220-2.8.7+g57229263ff65
Does anybody has a clue what i can do?
thanks in advance
Thanks for joining the community ! Please feel free to roam around.
Before we try to propose you some solutions, we would like to understand if there is a reason for you to use the Angstrom Distribution as it’s already a bit older and we would not recommend it for newer projects. Please check this page: Embedded Linux Release Matrix | Toradex Developer Center to see our newest releases.
thank you for the fast response. I used Ängström because it loaded gcc and gdb via opkg. The recommended image does not load anything with opkg.
I changed the os to the following:
NAME=“TDX Wayland with XWayland”
PRETTY_NAME=“TDX Wayland with XWayland 5.7.0+build.20 (dunfell)”
I get the following messages when I try to install via opkg.
root@colibri-imx6ull-07174691:~# opkg update (<- i see no process and no messages when i start this command)
root@colibri-imx6ull-07174691:~# opkg install gcc
- opkg_prepare_url_for_install: Couldn’t find anything to satisfy ‘gcc’.
root@colibri-imx6ull-07174691:~# opkg install gdb
- opkg_prepare_url_for_install: Couldn’t find anything to satisfy ‘gdb’.
Thanks for the update. Usually, the ideal process of adding packages to an embedded Linux image is to add them through Yocto and not to source them every time through a package manager such as opkg or apt-get. You may want to have a look here:
Is there any specific reason behind your goal to use Remote Compiling from Visual Studio? Using a Cross Compiler on your host machine wouldn’t fit your goal?
Also, which exact Colibri iMX6ULL Version do you have?
thank you very much for the support. I am developing a controller and so far I was used to work with a Linux that can be customized by sourcing packages. For me this is much easier than putting together a complete operating system myself. I didn’t factor in the time I would have to put into configuring it.
The advantage of remote debugging is that you can start right away no matter what the host pc looks like and you don’t have to configure the SDK.
I develop programs exclusively in c and the embedded system has enough power for debugging.
I am using the Colibri iMX6ULL 512MB IT.
In the meantime I managed to get the gcc compiler working.
Hi @Wilhelm, how are you?
Thanks for the update on your needs.
I agree this can be easier especially if you have just a few modules but once the production escalates then you’d profit from having all of them already sourced on the image.
This is great to hear! If you want to share how you’ve done this so that other community members could profit from your tests this would be wonderful
Hey @gclaudino.tx ,
i went back to angstrom because opkg loaded packages here at all. I then had to load more packages (gcc-symlinks, binutils, build-essential)so that gcc ran.
With it then the problems occurred, which are described under the following link.
I was then shocked to find out that the solution to the problem at the end of the topic was to create a new image. But I had no desire to do so…
So i took another linux distro for an arm mcu and copied the missing gcc files from it
Sure it’s not an elegant way, but it’s easy to implement and works for fine me.
Hi @Wilhelm !
I just would like to comment that although I understand that adding all the compiling and debugging tools on the target might be a good workflow for you, this might not be the best for a reproducible development environment. In other words, it is not aligned with the best practices.
If you have time, maybe you find it suitable to learn about the Extensible SDK that Yocto is able to generate: 1 Introduction — The Yocto Project ® 3.1.999 documentation