#59 'Program "gcc" not found in PATH' error when creating a project with linaro gcc (aarch64-none-elf-gcc).

Future release
closed-works-for-me
None
4
2015-02-20
2013-10-23
Iulia Vasii
No

Abstract: 'Program "gcc" not found in PATH' error when creating a project with linaro gcc (aarch64-none-elf-gcc).

Steps to reproduce:
- create 'HelloWorld ARM C Project' with 'Cross ARM GCC'
- choose toochain name: Linaro AArch64 bare-metal ELF (aarch64-none-elf-gcc)
- toolchain path: ../gcc-linaro-aarch64-none-elf-4.8_win32/bin (the package is in my eclipse layout)
- finish
- in Problems view I see two errors:

"Error: Program "g++" not found in PATH"
Error: Program "gcc" not found in PATH
- in Properties >> Build Variables I correctly configured ${cross_make} and ${cross_rm}
- build project (the build process finishes without errors, the binaries are created), but the above errors don't disappear

From my investigations, the issue is in Properties >> Preprocessor Include Paths, Macros etc. >> Providers >> CDT GCC Built-in Compiler Settings Cross ARM. I checked "Allocate console in the Console View" and the log is:

11:47:31 * Running scanner discovery: CDT GCC Built-in Compiler Settings Cross ARM *
g++ ${FLAGS} ${cross_toolchain_flags} -E -P -v -dD D:/WORKSPACES/runtime-New_configuration/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Cannot run program "g++": Launching failed
Error: Program "g++" not found in PATH

If I modify the ${COMMAND} to aarch64-none-elf-gcc I get:

11:56:10 * Running scanner discovery: CDT GCC Built-in Compiler Settings Cross ARM *
aarch64-none-elf-g++ ${FLAGS} ${cross_toolchain_flags} -E -P -v -dD D:/WORKSPACES/runtime-New_configuration/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
aarch64-none-elf-g++: error: ${FLAGS}: No such file or directory
aarch64-none-elf-g++: error: ${cross_toolchain_flags}: No such file or directory

I'm using plugin version 1.1.2-201310221203 with eclipse Kepler, Windows host. The .metadata log is attached.

1 Attachments

Discussion

1 2 > >> (Page 1 of 2)
  • Liviu Ionescu (ilg)

    • status: open --> open-accepted
     
  • Iulia Vasii

    Iulia Vasii - 2013-10-23

    I attach my project to see the settings. It has hard-coded paths for ${cross_make}, ${cross_rm} and toolchain path.

     
  • Iulia Vasii

    Iulia Vasii - 2013-10-23

    I reproduced the issue on Linux too. Is there a workaround without having to edit the PATH variable? Can I disable Scanner Discovery somehow?

     
  • Liviu Ionescu (ilg)

    you can disable the scanner providers, but this is by no means a solution; the indexer being one of the main strengths of CDT, without the scanner providers the indexer is rendered useless.

     
  • Iulia Vasii

    Iulia Vasii - 2013-10-23

    Ok. I'll wait for a solution.

     
  • Liviu Ionescu (ilg)

    • toolchain path: ../gcc-linaro-aarch64-none-elf-4.8_win32/bin (the package is in my eclipse layout)

    using relative paths here is not a good idea, since you do not now the current path when the execution is attempted. the actual build is done inside each configuration folder (Debug/Release), the discovery process... I don't know by heart, I have to check

    • in Properties >> Build Variables I correctly configured ${cross_make} and ${cross_rm}

    why would you like to change the internal build variables, when there is a special page to configure all toolchain details.

    please read the new documentation pages on how to configure the path to make & rm, and avoid entering absolute paths in macros, they are not portable across workspaces


    with the correct path to the toolchain (absolute path in Toolchain tabs) and the build tool (make & rm) in a separate folder, with its path added to the entire workspace environment, my test was successful, including correct discovery and indexer.

    19:36:15 * Build of configuration Debug for project t4 *
    make all
    'Building file: ../src/t4.c'
    'Invoking: Cross ARM C Compiler'
    aarch64-none-elf-gcc -mcpu=generic+simd -mcmodel=small -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -Wall -g3 -MMD -MP -MF"src/t4.d" -MT"src/t4.d" -c -o "src/t4.o" "../src/t4.c"
    'Finished building: ../src/t4.c'
    ' '
    'Building target: t4.elf'
    'Invoking: Cross ARM C Linker'
    aarch64-none-elf-gcc -mcpu=generic+simd -mcmodel=small -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -Wall -g3 -Wl,-Map,"t4.map" --specs=rdimon.specs -Wl,--start-group -lgcc -lc -lc -lm -lrdimon -Wl,--end-group -o "t4.elf" ./src/t4.o
    'Finished building target: t4.elf'
    ' '
    'Invoking: Cross ARM GNU Create Flash Image'
    aarch64-none-elf-objcopy "t4.elf" -O ihex "t4.hex"
    'Finished building: t4.hex'
    ' '
    'Invoking: Cross ARM GNU Create Listing'
    aarch64-none-elf-objdump "t4.elf" --source --all-headers --demangle --line-numbers --wide > "t4.lst"
    'Finished building: t4.lst'
    ' '
    'Invoking: Cross ARM GNU Print Size'
    aarch64-none-elf-size --format=berkeley "t4.elf"
    text data bss dec hex filename
    17168 4288 468 21924 55a4 t4.elf
    'Finished building: t4.siz'
    ' '

    19:36:17 Build Finished (took 1s.187ms)

    Note: there is an error logged initially (Program "echo" not found in PATH) that is due to a bug in CDT, which is trying to run the discovery process before the toolchain is properly configured, but if happens only when the project is created, and, if you delete it, it does not happen again.

     
  • Liviu Ionescu (ilg)

    Resolution: 'Program "gcc" not found in PATH' was due to a misconfigured PATH, a relative path was used with a wrong reference point.

    Recommandation: to avoid problems, use an absolute path. Although it is stored in the .cproject file, during the project life span it is stored in the workspace, so projects are portable and can be moved from workspace to workspace (even between windows and non windows) without problems.

     
  • Liviu Ionescu (ilg)

    • status: open-accepted --> closed-works-for-me
     
  • Iulia Vasii

    Iulia Vasii - 2013-10-24

    I did everything you said, absolute toolchain path, read documentation, configured make & rm as mentioned in the doc, same result. To be sure I'm not doing something stupid, I followed 'Create a test project' tutorial using gcc-arm-none-eabi toolchain and not linaro, same story. On Windows, the error is obvious:

    11:43:32 * Running scanner discovery: CDT GCC Built-in Compiler Settings Cross ARM *
    g++ ${FLAGS} ${cross_toolchain_flags} -E -P -v -dD D:/WORKSPACES/workspace_LS2_3/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.
    Cannot run program "g++": Launching failed
    Error: Program "g++" not found in PATH

    On Linux, because gcc/g++ are by default in system path, there are no errors reported in Problems view, but the Scanner Discovery console complains:

    11:39:34 * Running scanner discovery: CDT GCC Built-in Compiler Settings Cross ARM *
    g++ ${FLAGS} ${cross_toolchain_flags} -E -P -v -dD /home/iulia/workspaces/workspace_dev/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
    g++: error: ${FLAGS}: No such file or directory
    g++: error: ${cross_toolchain_flags}: No such file or directory

    This may be the case on Mac OS too (host you are using), to work by chance as it does on Linux. In the test you did previously, can you please enable Scanner Discovery console and check the log?

     
  • Liviu Ionescu (ilg)

    I ran my test on a Windows machine too, so there should not be a platform problem.

    Could you retry the test on a fresh Eclipse?

    • unpack a new Eclipse Kepler CDT
    • install the plug-in
    • create a new project in a new workspace

    If this test fails, you are systematically doing something wrong. If this test passes, the problem should be due to an interference with some other plug-ins.

     
  • Liviu Ionescu (ilg)

    • status: closed-works-for-me --> open-accepted
     
  • Iulia Vasii

    Iulia Vasii - 2013-10-24

    I re-tested on a fresh Eclipse Kepler CDT, it didn't reproduce. I see only the CDT bug 'Program echo not found in PATH', everything else works fine. So apparently, there is an interference between plugins as you mentioned above.

     
  • Liviu Ionescu (ilg)

    Ok, please keep me posted on your findings.

     
  • Liviu Ionescu (ilg)

    Although your suggested configuration is pretty unusual, I did just that, I installed Eclipse Luna 4.4M2 Standard and on top of it I installed CDT 8.2.0 from the master zip, then 1.1.3 from the test site and... the Cortex-M3 template built successfully. :-)

    Another project build with AArch64 toolchain did not exhibit the unusual behaviour reclaimed, just the expected 'aarch64-none-elf-gcc: command not found' (the toolchain was not installed).

    Attached is a screen snapshot of the Eclipse configuration.

    I also did the following tests:
    - Eclipse Kepler 4.3.1 Standard with CDT 8.2.1 from the master zip
    - Eclipse Kepler 4.3.1 CDT
    - Eclipse Luna 4.4M2 Standard with CDT 8.3 from Luna update site
    - Eclipse Luna 4.4M2 Standard with CDT 8.2.1 from master zip

    All worked flawlessly.

    Some general remarks:

    • you mixed Eclipse Luna 4.4, which is the next Eclipse version, not yet released, with CDT 8.2.0, which is the already outdated CDT. If you do this... you're on thin ice; generally CDT and Eclipse should be from the same release, and as up-to-date as possible.

    • you use a separate standard Eclipse release and a separate CDT archive, instead of using the already packed Eclipse CDT (and so you increase the risk of incompatible/missing plug-ins).

    • there must be something else in your configuration that prevents the plug-in to start, since my attempts to run it on multiple fresh Eclipses (even in unusual combinations of versions) could not reproduce the behaviour you describe.

     
  • Iulia Vasii

    Iulia Vasii - 2013-10-25

    I copy + pasted the wrong link for eclipse standard, it should have been
    http://www.eclipse.org/downloads/packages/eclipse-standard-43/keplerr
    This is the one I have. However, I really appreciate you did all these tests, it helped me to understand the faulty combination:
    Eclipse Kepler 4.3 with CDT 8.2.0 from the master zip doesn't work
    Eclipse Kepler 4.3 with CDT 8.2.1 from the master does work
    see attachments.

    Eclipse Kepler 4.3 and CDT 8.2.0 were released almost in the same time, 20130605 and 20130611, so they should be compatible. Anyway, we'll update our procedure and use the whole CDT package to keep out of trouble.

    Thanks again for your support, this ticket can be closed now.

     
  • Liviu Ionescu (ilg)

    • status: open-accepted --> closed-works-for-me
     
  • Liviu Ionescu (ilg)

    Eclipse Kepler 4.3 with CDT 8.2.0 from the master zip doesn't work

    I checked Kepler 4.3 R Standard (not 4.3 SR1 which is current now), plus the 8.2.0 from master zip, plus 1.1.3 from the updates-test and it worked flawlessly, as all other tests.

    we'll update our procedure and use the whole CDT package to keep out of trouble.

    good choice. and go to SR1, not plain R.

    this ticket can be closed now.

    ok

     
  • Iulia Vasii

    Iulia Vasii - 2013-10-25

    This becomes quite awkward. For me, neither eclipse-standard-kepler-R nor eclipse-standard-kepler-SR1 works flawlessly with CDT 8.2.0, only CDT 8.2.1 combinations. But fortunately, eclipse-cdt-kepler works great.

     
  • Albert

    Albert - 2014-05-31

    Hi,

    i had a similar problem, although, in the new-project wizard, i specified an absolute path to the toolchain folder right from the beginning.

    But:
    Error: 'Program "gcc" not found in PATH' !

    Then i double-checked a lot of things, but nothing helped.
    At the end, i was so desperate, that i was beginning to supect that i might need to remove the trailing dash from the toolchain prefix name.
    So i changed "arm-linux-gnueabihf-" to "arm-linux-gnueabihf".
    Now i got a different error message:

    Error: 'Program "arm-linux-gnueabihfgcc" not found in PATH'

    Now this error message actually made sense to me.

    After changing the toolchain prefix back to "arm-linux-gnueabihf-",
    everything unexpectedly worked fine!! No error message anymore! How odd!?

    It seems that the wizard messed up the internal storage of the toolchain prefix name?
    Anyway, it seems that once "touching" the toolchain prefix name entry in the project properties is a functioning workaround.

    Best regards,
    Al

     
  • Liviu Ionescu (ilg)

    Can you retry and see if you can find a way to reproduce the bug and document it in detail?

    Please use a fresh workspace, not the one that you already used before.

    My first thought is that you manually changed the project environment PATH, and this is known to interfere with the plug-in automatic mechanism. So be sure you do not touch the PATH setting except the Global toolchain path.

     
  • Liviu Ionescu (ilg)

    • status: closed-works-for-me --> open
    • Group: --> Future release
     
  • Albert

    Albert - 2014-06-01

    Hi Liviu,

    well yes, i reproduced it with a fresh workspace.
    It was exactly the same this time, without touching anything else.
    I did nothing but this:
    I set up a new C-Project and correctly specify the toolchain path and prefix.
    Then when building, i get the error message:
    'Program "gcc" not found in PATH'
    Then i go to menu Project/Properties/C_C++ Build/Settings/Tool Settings/Cross Settings/Prefix
    and change it from "arm-linux-gnueabihf-" to "arm-linux-gnueabihf-", which is exaclty the same term, which actually should make no difference at all. It's like merely touching that entry.
    Anyway i get rid of the error message, after this.

    So Eclipse seems to ignore the toolchain prefix wich i entered in the wizard.

    So i suspect that the wizard's data is being stored in some corrupted way, but that's just a wild guess, as i am a desperate Eclipse beginner and not aware of any Eclipse internals.
    Sorry for not being of any better help.

    Maybe it's worth mentioning that i use Eclipse 64Bit version:
    Kepler Service Release 2
    Build id: 20140224-0627

    Java 7u60 (64Bit)

    Win7 64Bit with all newest Microsoft updates, stable running, healthy files system, etc...

    Greetings,
    Albert

     
  • Liviu Ionescu (ilg)

    correctly specify the toolchain path and prefix

    oops! toolchain path and prefix?! my wizards no longer require this, are you sure you are using my plug-ins?

    please read the documentation pages carefully and do exactly as instructed there.

    if you still have problems, please report back, but provide full details of the input in the New C Project wizard, especially the selections used for:
    - 'Project type:'
    - 'Toolchains:'

     
1 2 > >> (Page 1 of 2)

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks