Actions
Forum Thread Details
  • State Not Answered
  • Replies 5 replies
  • Subscribers 312 subscribers
  • Views 958 views
  • Users 0 members are here
Related

'arm-xilinx-linux-gnueabi-gcc' is not recognized

Former Member

Hi,

Iu2019m going through the CTT section 5.4.1, step 19 and I am running into an error. I am running xilinux, not the linux version used in the tutorial. Have you encounter this error before?

**** Build of configuration Debug for project leds_switches ****

make all
Building file: ../leds_switches.c
Invoking: ARM Linux gcc compiler
arm-xilinx-linux-gnueabi-gcc -Wall -O0 -g3 -c -fmessage-length=0 -MMD -MP -MF"leds_switches.d" -MT"leds_switches.d" -o"leds_switches.o" "../leds_switches.c"
'arm-xilinx-linux-gnueabi-gcc' is not recognized as an internal or external command,
operable program or batch file.
make: *** [leds_switches.o] Error 1


I read online that you should install embedded edition, but that has not helped.

  • 0

    The same distribution disk image that installs a perfectly working system in Windows 7 (32-bit) has multiple problems in Linux, Xubuntu 12.10. Re-installing, I then lost EDK functionality also. It now reports an unspecified internal problem and bombs out without exporting the hardware. The installation in Windows, however, works without any glitches. The only problem is a Linux host is required for driver development. It seems they don't want us to build real systems with their tools.

  • 0

    Starting xsdk from planAhead and from the bash command line (after sourcing the appropriate settings.sh) produces the same error result.

    /usr/bin/arm-linux-gnueabi-gcc exists, but I am uncertain of its origins.

    /usr/bin/arm-linux-gnueabi-gcc -v produces the following. The reference to Ubuntu/Linaro causes me some concern that this is not the right compiler for the Zedboard's Zynq.

    Using built-in specs.
    COLLECT_GCC=arm-xilinx-linux-gnueabi-gcc
    COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.7/lto-wrapper
    Target: arm-linux-gnueabi
    Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.7.2 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv5t --with-float=soft --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib
    Thread model: posix
    gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-1ubuntu1)

    ==============
    It would be a simple matter to add the right soft link if it is the right compiler. At the same time, I note that arm-xilinx-eabi-gcc, the bare-metal compiler, is also missing and cannot find its headers when I try to soft-link to that same image.

    What's missing? How do I fix the software build?

    Thanks.

  • 0 in reply to Former Member

    I'm guessing the initial Xilinx install failed to complete the installation for the toolchains. I don't recall whether the scripts were run as sudo or otherwise. It certainly could not have succeeded in updating /usr/bin, /usr/lib and others without root perms.

    Also, I'm assuming the bare-metal toolchain is Codesourcery Lite, which would have failed to install using the defaulted /bin/dash shell for /bin/sh.

    I'll try reinstalling everything with some fixes before commenting further... I seem to recall seeing a post with these and other installer foibles spelled out. It would be handy if that could be made sticky and prominent.

  • 0

    Reinstalling 14.5 by hiding the old installation and re-running xsetup solved the build issues with the SDK. Apparently the Codesourcery installer failed for the initial installation.

    The CodeSourcery website makes note that Ubuntu installations typically link /bin/sh to /bin/dash, which causes problems for its installer. Point this to /bin/bash instead.