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
Related
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.
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.
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?
I’m running Netbeans 7.4 on Mavericks. In order to be able to use gdb, compilation with the -ggdb flag seems to be necessary. However, even though I specify it through the Project’s Properties/Additional Options wizard, Netbeans also emits -g during compilation. Unfortunately, it turns out that this behavior has an adverse effect when the debugging session commences. Is there any way to force Netbeans not to also emit -g?
Output during compilation:
g++ -m64 -ggdb -c -g -Werror -std=c++11 -MMD -MP -MF "build/Debug/macport_GNU-MacOSX/main.o.d" -o build/Debug/macport_GNU-MacOSX/main.o main.cpp
mkdir -p dist/Debug/macport_GNU-MacOSX
g++ -m64 -ggdb -o dist/Debug/macport_GNU-MacOSX/executable build/Debug/macport_GNU-MacOSX/main.o
Alexander.Simon#oracle.com responded here [1] to set "Development Mode" to "No Flags", then specify -ggdb in the "Additional Options".
1 - https://netbeans.org/projects/cnd/lists/users/archive/2014-02/message/12
my program compiles nicely for Android, however when I try to copy it to the Android emulator, it gives the following error:
knight666#Katja-Linux /media/Data/Shared/Galaxians $ acpy Galaxians.android
Filename: 'Galaxians.android'
819 KB/s (420657 bytes in 0.501s)
link_image[1638]: 825 could not load needed library 'libstdc++.so.6' for '/system/sbin/Galaxians.android' (load_library[984]: Library 'libstdc++.so.6' not found)CANNOT LINK EXECUTABLE
acpy is a small script I wrote that does the following:
#!/bin/sh
FILEPATH=`dirname $1`
FILENAME=`basename $1 .c`
echo "Filename: '$FILENAME'"
adb push $FILEPATH/$FILENAME /system/sbin/$FILENAME
adb shell chmod 777 /system/sbin/$FILENAME
adb shell /system/sbin/$FILENAME
Here is how I build my application:
oem#androiddev /media/YoghurtGum/Tests/Galaxians $ sudo make
arm-none-linux-gnueabi-g++ -static-libgcc -g -Wall -Werror -O2 -w -I ../../YoghurtGum/src/GLES -I ../../YoghurtGum/src -c src/Alien.cpp -o intermediate/Alien.o
arm-none-linux-gnueabi-g++ -static-libgcc -g -Wall -Werror -O2 -w -I ../../YoghurtGum/src/GLES -I ../../YoghurtGum/src -c src/Bullet.cpp -o intermediate/Bullet.o
arm-none-linux-gnueabi-g++ -static-libgcc -g -Wall -Werror -O2 -w -I ../../YoghurtGum/src/GLES -I ../../YoghurtGum/src -c src/Game.cpp -o intermediate/Game.o
arm-none-linux-gnueabi-g++ -static-libgcc -g -Wall -Werror -O2 -w -I ../../YoghurtGum/src/GLES -I ../../YoghurtGum/src -c src/Player.cpp -o intermediate/Player.o
arm-none-linux-gnueabi-gcc
-Wl,--entry=main,
-dynamic-linker=/system/bin/linker,
-rpath-link=/home/oem/android-ndk-r3/build/platforms/android-5/arch-arm/usr/lib,
-rpath=../../YoghurtGum/lib/Android,
-L/home/oem/android-ndk-r3/build/platforms/android-5/arch-arm/usr/lib
-nostdlib
-lstdc++
intermediate/Alien.o
intermediate/Bullet.o
intermediate/Game.o
intermediate/Player.o
../../YoghurtGum/lib/Android/libstdc++.a
../../YoghurtGum/bin/YoghurtGum.a
-o bin/Galaxians.android
Line breaks are only for clarity, none exist in the actual output.
YoghurtGum is my game library that already statically and dynamically links to libstdc++.
When I remove lstdc++, the program doesn't compile because it can't find the library.
Is there a way to link to stdlibc++ statically or link the application to the correct dynamic library in the emulator?
Thanks in advance.
There is a modification of the ndk with support for exceptions, RTTI and stdlibc++.
http://www.crystax.net/android/ndk-r3.php
The other alternative involves porting just what you need, by hand... eek!