scons error "sh: 1: arm-none-eabi-gcc: not found'' - c++

in my project, i using both Scons and Makefile to build. It working good when i use Makefile ,but got error when i use Scons
"arm-none-eabi-gcc -g -mthumb -mlittle-endian -mcpu=cortex-m4
-mcpu=cortex-m4 -Wl,--start-group -lm -lc -Wl,--end-group -Wl,--gc-sections -Wl,-Map,main.map -Tstm32_flash.ld -Wl,--entry=Reset_Handler -DSTM32F407xx -DUSE_STDPERIPH_DRIVER -I/home/minhtan/Downloads/STM32F4-Discovery_FW_V1.1.0/Utilities/STM32F4-Discovery
-I/home/minhtan/Downloads/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/Include
-I/home/minhtan/Downloads/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/ST/STM32F4xx/Include
-I/home/minhtan/Downloads/STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/inc
"-I/home/minhtan/Downloads/led(make file moi)" main.c -c -o
main.o sh: 1: arm-none-eabi-gcc: not found scons:
[main.o] Error 127
scons: building terminated because of errors. "

This looks like the answer to #1 of our "most frequently asked" FAQs at http://scons.org/faq.html could help you out. By default, SCons doesn't import the variables like $PATH from the surrounding shell environment. You have to pull in your $PATH for properly detecting the arm-none-eabi-gcc executable or specify the full path to the executable explicitly...check the mentioned FAQ entry for a more detailed discussion about why things are as they are, and how to provide the required $PATH definitions to your build environments.

Related

Build Makefile C++ project without configure to WASM using Emscripten

I want to compile this C++ project to WASM using Emscripten. For this, I am following the documentation on building projects.
The project only has a Makefile, no Configure or CMake. It should be portable from what I can tell, and the project compiles fine using regular make, as described in the Readme.
Because there is no configure file, I skipped the emconfigure step. The documentation says that I have to edit the Makefile manually in that case, but I can't get it right.
Running emmake make works, and produces .o files in the bin directory, and an executable. This produces the same result as running make normally, from what I can tell. Both executables can be executed as normal (./zilch).
Running emcc bin\main.o is where I get issues though:
wasm-ld: error: unknown file type: bin/main.o
emcc: error: '/home/johannes/emsdk/upstream/bin/wasm-ld -o main.wasm bin/main.o -L/home/johannes/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten -lGL -lal -lhtml5 -lstubs-debug -lnoexit -lc-debug -ldlmalloc -lcompiler_rt -lc++-noexcept -lc++abi-noexcept -lsockets -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --import-undefined --strip-debug --export-if-defined=main --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-if-defined=__main_argc_argv --export-if-defined=fflush --export=emscripten_stack_get_end --export=emscripten_stack_get_free --export=emscripten_stack_get_base --export=emscripten_stack_init --export=stackSave --export=stackRestore --export=stackAlloc --export=__wasm_call_ctors --export=__errno_location --export-table -z stack-size=5242880 --initial-memory=16777216 --no-entry --max-memory=16777216 --global-base=1024' failed (returned 1)
Running file bin/main.o shows: bin/main.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped. Running emmake clearly still compiled it to x86, not wasm.
In the flags.mk file that is imported into the Makefile, the CC variable is set to g++. Changing it to em++ gives this error:
em++: error: Passing any of -msse, -msse2, -msse3, -mssse3, -msse4.1, -msse4.2, -msse4, -mavx, -mfpu=neon flags also requires passing -msimd128 (or -mrelaxed-simd)!
But adding this to CFLAGS in flags.mk only throws another cryptic error message:
em++: error: '/home/johannes/emsdk/upstream/bin/clang++ -target wasm32-unknown-emscripten -fignore-exceptions -fvisibility=default -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr -DEMSCRIPTEN -D__EMSCRIPTEN_major__=3 -D__EMSCRIPTEN_minor__=1 -D__EMSCRIPTEN_tiny__=18 -Werror=implicit-function-declaration -I/home/johannes/emsdk/upstream/emscripten/cache/sysroot/include/SDL --sysroot=/home/johannes/emsdk/upstream/emscripten/cache/sysroot -D__SSE__=1 -D__SSE2__=1 -D__SSE3__=1 -D__SSSE3__=1 -D__SSE4_1__=1 -D__SSE4_2__=1 -Xclang -iwithsysroot/include/compat -O3 -g3 -Wall -fmessage-length=0 -fopenmp -maes -mtune=native -mrelaxed-simd -std=c++11 -Isrc -I/mnt/c/Users/johan/source/repos/Zilch/Zilch/framework/gadgetlib/gadgetlib/../. -I/mnt/c/Users/johan/source/repos/Zilch/Zilch/libstark/src -I/mnt/c/Users/johan/source/repos/Zilch/Zilch/algebra/algebralib/headers -I/mnt/c/Users/johan/source/repos/Zilch/Zilch/algebra/FFT/src -I/mnt/c/Users/johan/source/repos/Zilch/Zilch/framework/zilch/src -c /mnt/c/Users/johan/source/repos/Zilch/Zilch/framework/zilch/main.cpp -o /mnt/c/Users/johan/source/repos/Zilch/Zilch/bin/main.o' failed (returned 1)
I also tried to replace every $(MAKE) with $(EMMAKE) in the Makefile without success.
I am aware that I probably have to convert the project to CMake, or include a Configure file, as the documentation says. But I can't figure out for the life of me how that should look. If it isn't obvious, I am not experienced with any of these tools, so please be kind if I'm missing something super obvious.

Unable to use gdb with hdf5 c++ application

I am trying to use gdb to debug an hdf5 C++ application that I have written. The h5 package that I am using was installed using conda. The command that I am using is:
h5c++ hdf5.cpp
This generates an executable which I then run with gdb as follows:
gdb a.out
gdb launches alright. But when I add breakpoint using:
b 10
or any line number, it gives a message: No line 10 in file "init.c"
When I press run, it runs the whole program at once (which I don't want) and exits. The h5c++ -show command gives the following output:
x86_64-conda_cos6-linux-gnu-c++ -I/i3c/hpcl/sms821/software/tensorflow/anaconda2/include -D_FORTIFY_SOURCE=2 -O2 -g -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -I/i3c/hpcl/sms821/software/tensorflow/anaconda2/include -fdebug-prefix-map==/usr/local/src/conda/- -fdebug-prefix-map==/usr/local/src/conda-prefix -L/i3c/hpcl/sms821/software/tensorflow/anaconda2/lib /i3c/hpcl/sms821/software/tensorflow/anaconda2/lib/libhdf5_hl_cpp.a /i3c/hpcl/sms821/software/tensorflow/anaconda2/lib/libhdf5_cpp.a /i3c/hpcl/sms821/software/tensorflow/anaconda2/lib/libhdf5_hl.a /i3c/hpcl/sms821/software/tensorflow/anaconda2/lib/libhdf5.a -L/i3c/hpcl/sms821/software/tensorflow/anaconda2/lib -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-rpath,/i3c/hpcl/sms821/software/tensorflow/anaconda2/lib -L/i3c/hpcl/sms821/software/tensorflow/anaconda2/lib -g -lrt -lpthread -lz -ldl -lm -Wl,-rpath -Wl,/i3c/hpcl/sms821/software/tensorflow/anaconda2/lib
I think this has to do with the compiler the compiler that it is using. I tried replacing x86_64-conda_cos6-linux-gnu-c++ with my native g++ compiler in the h5c++ script but that gives linker error.
Please suggest how should make my h5 application work with gdb. Should I install hdf5 from source since I don't have sudo access? I am working on a Linux machine.
I simply installed hdf5 from the source files. While configuring the installation I turned the --enable-build-mode and --enable-symbol switches. Hdf5 has a dependency on szip which I also installed from source code. My exact configuration was as follows:
./configure --prefix=<hdf5 install directory> --enable-cxx --enable-build-mode=debug --enable-symbols=yes --enable-profiling=yes --with-szlib=<szip install directory>
The above solution worked and I was able to compile my h5 application using h5c++ hdf5.cpp and also use gdb to debug it.

Understanding LD under MSYS2

I'm trying to compile the simavr project from https://github.com/buserror/simavr on Windows 10 using MSYS2 and mingw-w64.
After editing the makefiles to enable the MSYS clauses (Which are commented out by default), and changing the order of 2 include files, I can get the project to compile. I do however encounter an error in the linking step.
The output is
C:/Programs/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lsimavr
Editing the makefile to print the ${LDFLAGS}, yield the following.
-L/lib -L/local/lib -L/c/Users/University/GitHub/simavr/simavr/../simavr/obj-i686-w64-mingw32 -lsimavr -lelf -lws2_32
Looking in the folder "obj-i686-w64-mingw32" mentioned in the build script, the file "libsimavr.a" is present. If I copy the file to the msys lib folder the linking step works fine.
The folder structure of the project is as follows:
simavr root (Where i run the makefile from, located in /c/Users/University/GitHub)
simavr
obj-i686-w64-mingw32
As far as I can tell, LD should be able to link properly without me copying the file manually. What am I missing here?
Edit:
The final command before the linker error.
cc -MMD -Werror -O2 -Wall -g -I/usr/local/include -DNO_COLOR -o obj-i686-w64-mingw32/run_avr.elf obj-i686-w64-mingw32/run_avr.o -L/lib -L/local/lib -L/c/Users/University/GitHub/simavr/simavr/../simavr/obj-i686-w64-mingw32 -lsimavr -lelf -lws2_32
Edit 2:
Cleaning the include paths of MSYS folders:
cc -MMD -Werror -O2 -Wall -g -DNO_COLOR -o obj-i686-w64-mingw32/run_avr.elf obj-i686-w64-mingw32/run_avr.o -L/c/Users/University/GitHub/simavr/simavr/../simavr/obj-i686-w64-mingw32 -lsimavr -lelf -lws2_32
C:/Programs/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lsimavr
Passing CC=gcc to make:
gcc -MMD -Werror -O2 -Wall -g -DNO_COLOR -o obj-i686-w64-mingw32/run_avr.elf obj-i686-w64-mingw32/run_avr.o -L/c/Users/University/GitHub/simavr/simavr/../simavr/obj-i686-w64-mingw32 -lsimavr -lelf -lws2_32
C:/Programs/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lsimavr
Edit 3:
Output of the find command:
$ find /c/Users/University/GitHub/simavr -name 'libsimavr.a'
/c/Users/University/GitHub/simavr/simavr/obj-i686-w64-mingw32/libsimavr.a
Note that previous entries have been made using the git bash prompt, not the one from msys2. However, running the same commands in the msys2 prompt or the mingw prompt from msys2 yields the same results.
Using mingw-w64 toolchain to build project you MUST remove from CFLAGS/CXXFLAGS/CPPFLAGS all paths with /usr, /local, /lib, /include as this paths can contain headers and libs from MSYS2 itself. Second, try pass "CC=gcc" to makefile.

Strange libtool behaviour at link time

I'm currently trying to get Autotools to play nice with the D programming language. So far, I've had success with everything except dynamic libraries. I've written a skeleton project aiming to do this, but for some reason, after configure && make, I get the following error:
gdmd -m64 -inline -noboundscheck -g -property -w -wi -O -c -fPIC -ofsrc/foo.lo src/foo.d
/bin/sh ./libtool --tag=CC --mode=link -g -O2 -version-info 0:1:0 -o libfoo-0.1.la -rpath /usr/local/lib src/foo.lo
Usage: /home/koz/Documents/Programming/D/d-skeleton-lib/libtool [OPTION]... [MODE-ARG]...
Try 'libtool --help' for more information.
libtool: error: unrecognised option: '-g'
Makefile:435: recipe for target 'libfoo-0.1.la' failed
make: *** [libfoo-0.1.la] Error 1
I'm not sure why those flags are being passed to libtool at link time - could someone please help me understand what's going on and how to avoid this behaviour?

How to build Qt 5.1 for QNX target (arm)

new update
I think I should edit the title now.
To make sure I got a clean environment, I
download qt5.1.1 src code from qt-prject.
export QNX_TARGET, QNX_HOST, AND add QNX_HOST into PATH.
then Run the script
./configure -opensource -confirm-license -xplatform qnx-armv7le-qcc -v
so in here, -opensource -confirm-license just avoid the Q&A -v is to show full message.
a lot of error message.
Creating qmake...
make: Nothing to be done for `first'.
Running configuration tests...
Determining architecture... ()
qcc -Vgcc_ntoarmv7le -c -Wno-psabi -lang-c++ -g -Wall -W -fPIE -DQT_NO_CLIPBOARD -I../../mkspecs/qnx-armv7le-qcc -I. -I/opt/qnx650/target/qnx6/usr/include -I/opt/qnx650/target/qnx6/usr/include/freetype2 -o arch.o arch.cpp
Unable to determine architecture!
Could not determine the target architecture!
Turn on verbose messaging (-v) to see the final report.
Determining architecture... ()
g++ -c -pipe -g -Wall -W -fPIE -I../../mkspecs/linux-g++ -I. -o arch.o arch.cpp
g++ -o arch arch.o { test -n "" && DESTDIR="" || DESTDIR=.; } && test $(gdb --version | sed -e 's,[^0-9]\+\([0-9]\)\.\([0-9]\).*,\1\2,;q') -gt 72 && gdb --nx --batch --quiet -ex 'set confirm off' -ex "save gdb-index $DESTDIR" -ex quit 'arch' && test -f arch.gdb-index && objcopy --add-section '.gdb_index=arch.gdb-index' --set-section-flags '.gdb_index=readonly' 'arch' 'arch' && rm -f arch.gdb-index || true
Found architecture in binary
CFG_HOST_ARCH="x86_64"
CFG_HOST_CPUFEATURES=" mmx sse sse2"
System architecture: 'unknown'
Host architecture: 'x86_64'
C++11 auto-detection... ()
qcc -Vgcc_ntoarmv7le -c -Wno-psabi -lang-c++ -O2 -Wc,-std=gnu++0x -Wall -W -fPIE-DQT_NO_CLIPBOARD -I../../../mkspecs/qnx-armv7le-qcc -I. -I/opt/qnx650/target/qnx6/usr/include -I/opt/qnx650/target/qnx6/usr/include/freetype2 -o c++11.o c++11.cpp
C++11 disabled.
floatmath auto-detection... ()
qcc -Vgcc_ntoarmv7le -c -Wno-psabi -lang-c++ -O2 -Wall -W -fPIE -DQT_NO_CLIPBOARD-I../../../mkspecs/qnx-armv7le-qcc -I. -I/opt/qnx650/target/qnx6/usr/include -I/opt/qnx650/target/qnx6/usr/include/freetype2 -o floatmath.o floatmath.cpp
qcc -Vgcc_ntoarmv7le -c -Wno-psabi -lang-c++ -O2 -Wall -W -fPIE -DQT_NO_CLIPBOARD -I../../../mkspecs/qnx-armv7le-qcc -I. -I/opt/qnx650/target/qnx6/usr/include -I/opt/qnx650/target/qnx6/usr/include/freetype2 -o freetype.o freetype.cpp
FreeType disabled.
STL auto-detection... ()
qcc -Vgcc_ntoarmv7le -c -Wno-psabi -lang-c++ -O2 -Wall -W -fPIE -DQT_NO_CLIPBOARD -I../../../mkspecs/qnx-armv7le-qcc -I. -I/opt/qnx650/target/qnx6/usr/include -I/opt/qnx650/target/qnx6/usr/include/freetype2 -o stltest.o stltest.cpp
STL disabled.
STL functionality check failed! Cannot build Qt with this STL library.
Turn on verbose messaging (-v) to /home/pasadeveloper/qt-everywhere-opensourcesrc-5.1.1/qtbase/configure to see the final report.
UPDATE:
I am working on QNX for ARM, target is an arm platform device.
Thing is getting weird. in Env Var, I put
$QNX_CONFIGURATION=/etc/qnx
$QNX_JAVAHOME=/opt/qnx650/_jvm
$QNX_TARGET=/opt/qnx650/target/qnx6
$QNX_HOST=/opt/qnx650/host/linux/x86
but when I do qmake qmake.conf mkspecs/qnx-armv7le-qcc folder
it returns an error message Project ERROR: QNX_TARGET environment variable not set
Have no clue what is going on now.
not just qmake qmake.conf
I try to build qt 5.1.2 at another host, ubuntu 12.04-64bit.
also get the same error message. Project ERROR: QNX_TARGET environment variable not set
I was working at Qt development under linux(FYI Ubuntu 12.04 -64bits), but I need to compile this program to binary for QNX.
I install QNX MOmentics IDE which provide QNX-gcc for me.
but I can't find the qmake-qnx.
Under the QT/gcc_64/mkspecs/qnx-armv7le-qcc, there is a file call qmake.conf. I guess this is where I can generate my qmake-qnx. after I run qmake -o Makefile qmake.conf, there is a Makefile generated.
However, when I run make, error occured.
qcc -Vgcc_ntoarmv7le -lang-c++ -Wl,-rpath-link,/opt/qnx650/target/qnx6/armle-v7/lib -Wl,-rpath-link,/opt/qnx650/target/qnx6/armle-v7/usr/lib -Wl,-O1 -Wl,-O1 -Wl,-rpath,/home/pasadeveloper/Qt5.1.0/5.1.0/gcc_64 -Wl,-rpath,/home/pasadeveloper/Qt5.1.0/5.1.0/gcc_64/lib -o qmake -L/opt/qnx650/target/qnx6/armle-v7/lib -L/opt/qnx650/target/qnx6/armle-v7/usr/lib -lm -L/home/pasadeveloper/Qt5.1.0//5.1.0/gcc_64/lib -lQt5Gui -lQt5Core -lGL -lpthread
cc: no files to process
make: *** [qmake] Error 1
pasadeveloper#ubuntu:~/Qt5.1.0/5.1.0/gcc_64/mkspecs/qnx-armv7le-qcc$
You do not "generate" your qmake-qnx like that. You are supposed to use the native qmake for generating proper makefiles for your target to aid the cross-compilation. Also, running qmake qmake.conf in the relevant mkspecs folder is wrong because that is not a project file as you may think.
When building Qt itself for instance, you should be using the proper mkspecs files for the target in which case, it is the one you also mentioned above if it is built for that particular arm qnx variant, called qnx-armv7le-qcc.
Here is the exact command you need to run after downloading the relevant Qt sources, like 5.1.1:
./configure -opensource -confirm-license -xplatform qnx-armv7le-qcc -v
For this QNX version, the bottom line is, if you do not have SP1 and libscreen, it will not work. The QPA plugin would link against it. This library provides the API to the graphics server on newer QNX variants. You need to talk to your QNX representatives.
Here you can find further information about the topic.
$QNX_TARGET=/opt/qnx650/target/qnx6
is probably not doing what you want. In shell scripts, you don't put a "$" in front of a variable when you are defining the variable, only when you access the variable:
X=hello
echo $X