This is a fresh install of VEXcode IQ. I am a novice.
I’m running on
VEXcode IQ 2.3.1-24
macOS 10.15.7
IQ Robot Brain gen 1
I wrote a program in the editor and I tried to download and this is the error displayed:
unix build for platform vexiq
CXX src/main.cpp
LINK build/VEXcodeProject.elf
/bin/sh: arm-none-eabi-ld: command not found
make: *** [build/VEXcodeProject.elf] Error 127
make process closed with exit code : 2
I then created an entirely empty program with just a “when started” block and the same error message was produced. It looks like an expected command isn’t installed. How do I install this?
Everything the compiler needs is bundled inside the VEXcode application. There is a process of moving files into the require locations when the application starts up, so you may want to try restarting VEXcode to see if that fixes the issue. If that does not work, can you please try to download a project and then submit feedback (top right of the blue menu bar) with the diagnostic data option checked. You should include a reference to the issue in the feedback message. This will let us look at the compiler log and see if what is happening.
4 Likes
Great! I restarted VEXcode but the problem still remained. I can confirm that the actual executable exists because I searched for it inside the macOS application package. It looks like whatever process is trying to access it either doesn’t have the correct search paths or the tool isn’t getting copied/linked to that search path.
[08:27 AM]/Applications/VEXcode IQ.app/Contents/Resources/toolchain/vexiq/osx/gcc/bin > ls
arm-none-eabi-ld* arm-none-eabi-objcopy* arm-none-eabi-size*
I submitted my issue via the feedback mechanism as you suggested.
1 Like
That’s the right location. The tools don’t get copied anywhere, they are executed directly. can you verify that permissions are correctly set, issue the following at command prompt.
Jamess-Mac-Pro:~ james$ ls -l /Applications/VEXcode\ IQ.app/Contents/Resources/toolchain/vexiq/osx/gcc/bin
total 7520
-rwxr-xr-x 1 root wheel 1493280 Mar 4 08:19 arm-none-eabi-ld
-rwxr-xr-x 1 root wheel 1285632 Mar 4 08:19 arm-none-eabi-objcopy
-rwxr-xr-x 1 root wheel 1066336 Mar 4 08:19 arm-none-eabi-size
you could also just try executing the linker directly to check it runs and what the version is.
Jamess-Mac-Pro:~ james$ /Applications/VEXcode\ IQ.app/Contents/Resources/toolchain/vexiq/osx/gcc/bin/arm-none-eabi-ld --version
GNU ld (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 2.29.51.20171128
Copyright (C) 2017 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
5 Likes
Does this look correct? Again, it seems like the issue is more that the build script can’t find the linker. Thank you for your help.
[11:48 AM]/Applications/VEXcode IQ.app/Contents/Resources/toolchain/vexiq/osx/gcc/bin > ./arm-none-eabi-ld --version
GNU ld (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 2.29.51.20171128
Copyright (C) 2017 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
I still haven’t gotten a reply via email to resolve this issue. Is there a better channel/process I should use to receive support? Thanks!
We have been trying to figure out where the issue could be based on the logs and the information you have provided.
Based on the information we have, the first option is that the path value, where your computer will look for the command, is not getting set correctly. The only issue is that the path is found relative to the application location. Due to how simple this is, we never thought that could go wrong so we don’t have that information in the diagnostic data in the feedback. Since the value is set locally in the app, there is no way to check that without having the info sent from the app. Long term we will work on adding more information like this into the feedback data, but that will not help until the next release. That being said, this seems unlikely as the process that calls arm-none-eabi-ld is also run from that same location.
The other option is even less likely. Is it possible that you have something on your machine that could block some command line applications that are called by another application? we could check this by trying the VEXcode Pro V5 application. This does not need a V5 connected to your computer to test this as you can build the project even without a brain connected. to do this, open the app and select File → New, and click create when prompted. After the project is created click the build button at the top right (see image).
If that works, then it is likely that the issue is with the path generated by VEXcode IQ. If it does not build successfully, then there are still more things we will need to investigate.
3 Likes
Your reply was very helpful. Over the years I have an assortment of software developer tools installed (like homebrew) and have customized my shell environment. Your reply made me consider if some of my customizations might be influencing VEXcode IQs behavior. I created a new local account with default settings and tried compilation and downloading. It worked.
I would still like to be able to use my main account instead of having to use an alternative account just for using VEXcode. I’m guessing there is something in my environment that is modifying the $PATH variable. I’m happy to wait until the next release if it’s not too far off. Another possibility would be for me to provide you my $PATH variable contents and then for you to test on your machine if modifying your shell results in the same behavior.
What would be the best course of action forward?
2 Likes
To be honest, this is something that should not happen as we prefix our folder on the PATH in the shell environment that we are using for the build process to avoid issues. We get that our toolchain folder path by grabbing the path of the app and adding our sub-folder with the toolchain files. The goal was to keep it as simple as possible to prevent issues.
We are aiming to have a release for back to school in August. While we would be able to see what is happening with that release, it may not be something that can be fixed without a new release after that.
If you want to share your path, that could help us narrow down what is happening. It may also help to know if there are any tools you have installed that could change how the shell environment gets passed to VEXcode.
2 Likes
if [[ -x /usr/libexec/path_helper ]]; then
PATH=""
eval `/usr/libexec/path_helper -s`
export PATH=.:~/bin:$PATH
fi
This was the code in my bashrc that was preventing compilation. Removing allowed me to compile. Hopefully this will help someone in the future. The man page for path_helper says that a user (i.e. me) should not invoke this directly. So I think you can chalk this up to user error. At the same time I’m wondering why VEXcode IQ needs to source the user’s shell dot files: to be safe, I would just want VEXcode code to source a known set of dot files. I’m going to mark this as solved and if you think, internally, you guys should investigate this further you can. Thank you for helping me trouble-shoot this.
3 Likes