Compiling C++ code to a Rocket chip RTL simulator - riscv

I'm trying to compile a C++ hello-world (using the standard C++ library) to a verilator simulation of the Rocket chip.
I'm also using the Chipyard 1.6.2 environment to facilitate the process.
The compilation steps I'm using are the following:
#!/bin/bash -e
export COMMON="/root/chipyard/toolchains/esp-tools/riscv-tests/benchmarks/common"
export RV_ENV="/root/chipyard/toolchains/esp-tools/riscv-tests/env"
export STARTFILES_DIR="/root/chipyard/esp-tools-install/lib/gcc/riscv64-unknown-elf/9.2.0"
# define GCC start files to link
export GCC_STARTFILES="\
${STARTFILES_DIR}/crtbegin.o \
${STARTFILES_DIR}/crtend.o
"
# define GCC flags for compilation
export FLAGS="\
-I${COMMON} \
-I${RV_ENV} \
-mcmodel=medany \
-static \
-std=gnu99 \
-g \
-Og \
-ffast-math \
-fno-common \
-fno-builtin-printf \
-fno-tree-loop-distribute-patterns \
-march=rv64gcxhwacha \
-static \
-nostartfiles \
-lm \
-lgcc \
-T ${COMMON}/test.ld \
"
# create cpp hello world
cat << EOF > hello.cpp
#include <iostream>
int main() {
std::cout << "Hello World!\n";
return 0;
}
EOF
# generate object files
riscv64-unknown-elf-gcc ${FLAGS} -c -o crt.o ${COMMON}/crt.S
riscv64-unknown-elf-gcc ${FLAGS} -c -o syscalls.o ${COMMON}/syscalls.c
riscv64-unknown-elf-g++ ${FLAGS} -c -o hello.o hello.cpp
# link object files
riscv64-unknown-elf-g++ ${FLAGS} \
-o hello-cpp.riscv hello.o crt.o syscalls.o ${GCC_STARTFILES}
# run simulation
/root/chipyard/sims/verilator/simulator-chipyard-RocketConfig hello-cpp.riscv
Unfortunately, the simulation gets stuck without printing anything:
root#chipyard:~/smr-gemmini/dev# /root/chipyard/sims/verilator/simulator-chipyard-RocketConfig hello-cpp.riscv
This emulator compiled with JTAG Remote Bitbang client. To enable, use +jtag_rbb_enable=1.
Listening on port 43881
[UART] UART0 is here (stdin/stdout).
While the expected result would be:
root#chipyard:~/smr-gemmini/dev# /root/chipyard/sims/verilator/simulator-chipyard-RocketConfig hello-cpp.riscv
This emulator compiled with JTAG Remote Bitbang client. To enable, use +jtag_rbb_enable=1.
Listening on port 44319
[UART] UART0 is here (stdin/stdout).
Hello World!
A couple of observations:
I've noted that replacing #include <iostream> and std::cout by #include <cstdio> and printf, the script above works.
I've also tried running the simulation with GDB/OpenOCD and the simulation never reached the breakpoint placed in the main function.
I'm guessing that I'm not linking the proper entry and C++ libraries files but I was unable to find a solution for this issue.
Is there a known process for compiling C++ to Rocket chip?

Related

x86_64-w64-mingw32-g++ options -static-libgcc -static-libstdc++ seem to be broken in g++

Overview
A SSCCE illustrating that x86_64-w64-mingw32-g++ when building a shared library on OS-X for deployment on Windows fails to include libstc++-6.dll, libwinpthread-1.dll and libgcc_s_seh.dll even when the options -static-libgcc -static-libstdc++ are specified.
If this is a bug in mingw then I'd appreciate knowing how to report it.
The commands used to build the project are in the bash shell script file: doit.sh
# Clean up
rm -rf *.o *.dll Main.exe winlibs
# Cross compile for the Windows shared library
GPP=/usr/local/bin/x86_64-w64-mingw32-g++
$GPP -c MyLib.cpp -o MyLib.win.o
$GPP -shared -static-libgcc -static-libstdc++ -o MyLib.dll *.win.o
# Build Application Main.exe
$GPP -c Main.cpp -o Main.win.o
$GPP -o Main.exe MyLib.dll Main.win.o
The program builds but when exectuted on Windows 10 reports libstdc++-6.dll, libgcc_s_seh-1.dll and libwinpthread-1.dll are missing.
The -static-libgcc and -static-libstdc++ appear to make no difference to the getneralted shared library.
Copying the missing libaries from the mingw distribution into the same folder as the application allows the prgram to run as it should.
MyLib.h
extern int add (int a, int b);
MyLib.cpp
#include "MyLib.h"
extern int add (int a, int b) {
return a + b;
}
Main.cpp
#include <iostream>
#include "MyLib.h"
using namespace std;
int main()
{
cout << "add(51700, 73)=" << add(51700, 73) << endl;
return 0;
}
Tool Versions
| Tool | Version |
|----------------------------|-----------------------|
| MacBook Pro | OS-X Catalina 10.15.6 |
| x86_64-w64-mingw32-gcc/g++ | 9.3.0 (GCC) (download with brew install mingw-w64) |
| uname -a | Darwin michaels-mbp 19.6.0 Darwin Kernel Version 19.6.0: Thu Jun 18 20:49:00 PDT 2020; root:xnu-6153.141.1~1/RELEASE_X86_64 x86_64 |
GitLab URL
This project is public on GitLab at gitlab url: https://gitlab.com/Michael51773/mingwwindowssharedlibbug
With thanks to Adrian Ho who gave me the solution, it was just a matter of using the -static AND the -shared option together:
/usr/local/bin/x86_64-w64-mingw32-g++ -shared -static -o MyLib-static.dll MyLib/*.win.o
A full description can be found here: https://discourse.brew.sh/t/x86-64-w64-mingw32-g-broken-options-static-libgcc-static-libstdc/8705/22

How to cross-compile tensorflow-serving on docker build image with bazel when copts contain spaces

Background info
I would like to run tensorflow-serving on some older machine (target system) which doesn't support modern cpu instructions used in the standard tensorflow build. I used these instructions for installing tf-serving via docker. However I ran into the error Tensorflow Serving Illegal Instruction core dumpedsimilar to this one on github. The suggested solution was to use a docker build-image to compile the binary on my target system which is described here.
Since this part is relevant for the reproduction of my issue I will copy the relevant commands here:
git clone https://github.com/tensorflow/serving
cd serving
docker build --pull -t $USER/tensorflow-serving-devel -f tensorflow_serving/tools/docker/Dockerfile.devel .
This will compile the binary with the flag -march=native in my docker container on my slow target machine and works.
Target system info
However on my old machine the compilation takes forever and I would like to use my other more powerful pc to cross-compile the binary. I used the commands provided in this answer to find out the needed compilation flags of my target system to replicate the build flag -march=native which is the default flag implicitly used in the above process.
gcc -### -E - -march=native 2>&1 | sed -r '/cc1/!d;s/(")|(^.* - )//g'
gave me the following flags:
-march=core2 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-clwb -mno-mwaitx -mno-clzero -mno-pku --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=core2
Note especially the follwing flags at the end which contain spaces:
--param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048
I can provide these flags in the docker build process via the build argument TF_SERVING_BUILD_OPTIONS as described in the docs here
This string is then used to run bazel build which can be seen in the Dockerfile.devel
Thus I take all the flags from above and put --copt= in front and put the resulting string in the variable TF_SERVING_BUILD_OPTIONS. This is my total command including the copts at the end with spaces:
docker build --pull \
--build-arg TF_SERVING_BUILD_OPTIONS="--copt=-mmmx --copt=-mno-3dnow --copt=-msse --copt=-msse2 --copt=-msse3 --copt=-mssse3 --copt=-mno-sse4a --copt=-mcx16 --copt=-msahf --copt=-mno-movbe --copt=-mno-aes --copt=-mno-sha --copt=-mno-pclmul --copt=-mno-popcnt --copt=-mno-abm --copt=-mno-lwp --copt=-mno-fma --copt=-mno-fma4 --copt=-mno-xop --copt=-mno-bmi --copt=-mno-bmi2 --copt=-mno-tbm --copt=-mno-avx --copt=-mno-avx2 --copt=-mno-sse4.2 --copt=-mno-sse4.1 --copt=-mno-lzcnt --copt=-mno-rtm --copt=-mno-hle --copt=-mno-rdrnd --copt=-mno-f16c --copt=-mno-fsgsbase --copt=-mno-rdseed --copt=-mno-prfchw --copt=-mno-adx --copt=-mfxsr --copt=-mno-xsave --copt=-mno-xsaveopt --copt=-mno-avx512f --copt=-mno-avx512er --copt=-mno-avx512cd --copt=-mno-avx512pf --copt=-mno-prefetchwt1 --copt=-mno-clflushopt --copt=-mno-xsavec --copt=-mno-xsaves --copt=-mno-avx512dq --copt=-mno-avx512bw --copt=-mno-avx512vl --copt=-mno-avx512ifma --copt=-mno-avx512vbmi --copt=-mno-clwb --copt=-mno-mwaitx --copt=-mno-clzero --copt=--param l1-cache-size=32 --copt=--param l1-cache-line-size=64 --copt=--param l2-cache-size=2048 --copt=-mtune=core2" \
-t $USER/tensorflow/serving-devel \
-f tensorflow_serving/tools/docker/Dockerfile.devel .
Problem
However bazel complains as follows, which is probably due to the space inbetween --param and l1-cache-size=32 which is a option for the C-compiler provided to a bazel build call.
ERROR: Skipping 'l1-cache-line-size=64': couldn't determine target from filename 'l1-cache-line-size=64'
ERROR: couldn't determine target from filename 'l1-cache-line-size=64'
INFO: Elapsed time: 20.233s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded)
The command '/bin/sh -c bazel build --color=yes --curses=yes ${TF_SERVING_BAZEL_OPTIONS} --verbose_failures --output_filter=DONT_MATCH_ANYTHING ${TF_SERVING_BUILD_OPTIONS} tensorflow_serving/model_servers:tensorflow_model_server && cp bazel-bin/tensorflow_serving/model_servers/tensorflow_model_server /usr/local/bin/' returned a non-zero code: 1
What I tried
I tried escaping the space char in the last flags:
TF_SERVING_BUILD_OPTIONS="--copt=-mmmx ... --copt=--param\ l1-cache-size=32 --copt=--param\ l1-cache-line-size=64 --copt=--param\ l2-cache-size=2048 --copt=-mtune=core2 "
But bazel still complains with the same error message as above.
I tried enclosing the commands in double or single quotes:
TF_SERVING_BUILD_OPTIONS="--copt=-mmmx ... --copt=\"--param l1-cache-size=32\" --copt=\"--param l1-cache-line-size=64\" --copt=\"--param l2-cache-size=2048\" --copt=-mtune=core2 "
Also the same error as before appears.
I tried using inner double quotes for copts and wrap the TF_SERVING_BUILD_OPTIONS with outer single-quotes but same error.
I tried escaping the double-quotes from copts with \x22. A similar error as before apears. This time indicating that the target is malformed ERROR: Skipping 'l1-cache-size=32\x22': Bad target pattern...
I tried escaping the space char with \40:
TF_SERVING_BUILD_OPTIONS="--copt=-mmmx ... --copt=--param\40l1-cache-size=32 --copt=--param\40l1-cache-line-size=64 --copt=--param\40l2-cache-size=2048 --copt=-mtune=core2 "
This time bazel didnt complain, since the argument of copt was one string without normal spaces. However the arguments are passed incorrectly to gcc, since I get the following error:
ERROR: /root/.cache/bazel/_bazel_root/e53bbb0b0da4e26d24b415310219b953/external/grpc/BUILD:692:1: C++ compilation of rule '#grpc//:grpc_base_c' failed (Exit 1): gcc failed: error executing command
(cd /root/.cache/bazel/_bazel_root/e53bbb0b0da4e26d24b415310219b953/execroot/tf_serving && \
exec env - \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
PWD=/proc/self/cwd \
PYTHON_BIN_PATH=/usr/bin/python \
/usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections -fdata-sections '-std=c++0x' -MD -MF bazel-out/k8-opt/bin/external/grpc/_objs/grpc_base_c/endpoint_pair_uv.d '-frandom-seed=bazel-out/k8-opt/bin/external/grpc/_objs/grpc_base_c/endpoint_pair_uv.o' '-DGRPC_ARES=0' -iquote external/grpc -iquote bazel-out/k8-opt/genfiles/external/grpc -iquote bazel-out/k8-opt/bin/external/grpc -iquote external/zlib_archive -iquote bazel-out/k8-opt/genfiles/external/zlib_archive -iquote bazel-out/k8-opt/bin/external/zlib_archive -isystem external/grpc/include -isystem bazel-out/k8-opt/genfiles/external/grpc/include -isystem bazel-out/k8-opt/bin/external/grpc/include -isystem external/zlib_archive -isystem bazel-out/k8-opt/genfiles/external/zlib_archive -isystem bazel-out/k8-opt/bin/external/zlib_archive -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-clwb -mno-mwaitx -mno-clzero '--param\40l1-cache-size=32' '--param\40l1-cache-line-size=64' '--param\40l2-cache-size=2048' '-mtune=core2' '-std=c++14' '-D_GLIBCXX_USE_CXX11_ABI=0' -fno-canonical-system-headers -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c external/grpc/src/core/lib/iomgr/endpoint_pair_uv.cc -o bazel-out/k8-opt/bin/external/grpc/_objs/grpc_base_c/endpoint_pair_uv.o)
Execution platform: #bazel_tools//platforms:host_platform
gcc: error: unrecognized command line option '--param\40l1-cache-size=32'
gcc: error: unrecognized command line option '--param\40l1-cache-line-size=64'
gcc: error: unrecognized command line option '--param\40l2-cache-size=2048'
Target //tensorflow_serving/model_servers:tensorflow_model_server failed to build
It seems that this is related to the following issue on github.
I tried the compilation withou the flags which contain spaces and this finished fine which strengthens the assumption that the error is due to the space which is incorrectly handled from bazel.
How can I fix that problem?
I would like to run tensorflow-serving on some older machine (target system) which doesn't support modern cpu instructions used in the standard tensorflow build. I used these instructions for installing tf-serving via docker. However I ran into the error Tensorflow Serving Illegal Instruction core dumpedsimilar to this one on github...
Bazel and TensorFlow use -march=native by default in its build flags, if I recall properly.
You should omit the flag, or specify a more appropriate flags like -march=sse4.2.
-march=core2 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf
-mno-movbe -mno-aes -mno-sha -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma
-mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2
-mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase
-mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f
-mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec
-mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi
-mno-clwb -mno-mwaitx -mno-clzero -mno-pku --param l1-cache-size=32
--param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=core2
Your dump shows -mno-sse4.1. I believe that means you can use the following and be done with it.
-msse2 -msse3 -mssse3
x86_64 has SSE2 as part of the core instruction set, so it implies MMX and SSE.
I think you should not use -march=core2 and -mtune=core2 because Core2 means you have SSE4.1 (early iCore cpus) or SSE4.2 (later iCore cpus).
And from the GCC man page on x86_64 options this looks suspicious/wrong to me:
core2
Intel Core2 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support.
I'm fairly certain Core2's are more capable than SSSE3. I keep several Core2 machines around for testing and they have SSE4.1 and SSE4.2. (I believe one has CRC instructions, and that is SSE4.2 ISA).
I may be wrong about the GCC option page, but it looks suspicious to me.
Tensorflow Serving Illegal Instruction core dumped
What was the illegal instruction?
gcc -### -E - -march=native 2>&1 | sed -r '/cc1/!d;s/(")|(^.* - )//g'
Just another point of view, but I find something like this more useful. From a Skylake machine:
$ gcc -march=native -dM -E - </dev/null | grep -E 'SSE|CRC|AES|PCL|RDRND|RDSEED|AVX' | sort
#define __AES__ 1
#define __AVX__ 1
#define __AVX2__ 1
#define __PCLMUL__ 1
#define __RDRND__ 1
#define __RDSEED__ 1
#define __SSE__ 1
#define __SSE2__ 1
#define __SSE2_MATH__ 1
#define __SSE3__ 1
#define __SSE4_1__ 1
#define __SSE4_2__ 1
#define __SSE_MATH__ 1
#define __SSSE3__ 1
From the preprocessor dump I know I can use -msse2, -msse3, -mssse3, -msse4.1, -msse4.2, -mavx and -mavx2.
And from a Core2 machine:
$ gcc -march=native -dM -E - </dev/null | grep -E 'SSE|CRC|AES|PCL|RDRND|RDSEED|AVX' | sort
#define __SSE__ 1
#define __SSE2__ 1
#define __SSE2_MATH__ 1
#define __SSE3__ 1
#define __SSE4_1__ 1
#define __SSE_MATH__ 1
#define __SSSE3__ 1
From the preprocessor dump I know I can use -msse2, -msse3, -mssse3 and -msse4.1.
And from another Core2 machine:
$ gcc -march=native -dM -E - </dev/null | grep -E 'SSE|CRC|AES|PCL|RDRND|RDSEED|AVX' | sort
#define __SSE2_MATH__ 1
#define __SSE2__ 1
#define __SSE3__ 1
#define __SSE4_1__ 1
#define __SSE_MATH__ 1
#define __SSE__ 1
#define __SSSE3__ 1
From the preprocessor dump I know I can use -msse2, -msse3, -mssse3 and -msse4.1.
With all the rambling, this looks suspicious to me. What filename? The option is specifying a cache line size. Are you missing a -- for the option?
ERROR: Skipping 'l1-cache-line-size=64': couldn't determine target from filename 'l1-cache-line-size=64'
ERROR: couldn't determine target from filename 'l1-cache-line-size=64'

I'm trying to use XROTOR, need to use a Makefile but ifort: command not found

I am about 3 hours new to Linux/Cygwin/virtually anything even borderline computer science. I have been tasked with installing a program for rotors/propellers for research (XROTOR), but I cannot figure out how to run the program. It seems to have been developed in Fortran (maybe?), and came with a README. The README is asking me to build the file, but I have no clue what that means. I have downloaded Cygwin, and have gotten as far as the "make libPLT.a" line. I then cd'ed to the bin folder, and typed in "make xrotor" like the README states, but I keep getting the following error:
$ make
ifort -c -I../src -O -static ../src/xrotor.f
sh: ifort: command not found
make: *** [Makefile:147: xrotor.o] Error 127
I've included the README as well. I don't know what I'm doing, and I figured this was a decent place to start. Any help is GREATLY appreciated!!!
EDIT: Left the README out for whatever reason, sorry. I've written it out here:
General
XROTOR and its plot library should compile on any Unix system
with normal Fortran-77, C, and X-Windows support. So far,
XROTOR has been tested on the following systems:
DEC-5000
Alpha
SGI
* Sun
* RS/6000
* HP-9000
* Pentium/Linux
The systems marked with "*" have peculiar features which require slight
modifications to the Makefiles in the plotlib/ and bin/ directories.
Examine these Makefiles before building the plot library and Xrotor.
Build Sequence
To install, first build the plot library in ./plotlib ...
% cd plotlib
% make libPlt.a
Then build the programs in ./bin ...
% make xrotor
% make jplot
The README is missing some details, but you need to compile the program from sources,
and to do so you need to adjust some variables in the Makefile's
As prerequisite for compiling you need gcc-fortran,make and library libX11-devel
plus the X11 system for the graphic. Installing xinit is a good start.
$ tar -xf Xrotor7.55.tar.tgz
$ cd Xrotor
$ cd plotlib
than modify config.make to set PLTLIB = libPlt.a
I used my preferred editor, but other are also ok
$ vim config.make
To build:
$ make libPlt.a
gfortran -c -O2 -fdefault-real-8 plt_base.f
gfortran -c -O2 -fdefault-real-8 plt_font.f
gfortran -c -O2 -fdefault-real-8 plt_util.f
gfortran -c -O2 -fdefault-real-8 plt_color.f
gfortran -c -O2 -fdefault-real-8 set_subs.f
gfortran -c -O2 -fdefault-real-8 gw_subs.f
gfortran -c -O2 -fdefault-real-8 ps_subs.f
gcc -c -O2 -DUNDERSCORE Xwin.c
gfortran -c -O2 -fdefault-real-8 plt_old.f
gfortran -c -O2 -fdefault-real-8 plt_3D.f
ar r libPlt.a plt_base.o plt_font.o plt_util.o plt_color.o set_subs.o gw_subs.o ps_subs.o Xwin.o plt_old.o plt_3D.o
ar: creating libPlt.a
ranlib libPlt.a
Than moving to program build directory
$ cd ../bin
again modify Makefile.gfortran to set PLTOBJ = ../plotlib/libPlt.a and LIBS = -L/usr/lib -lX11
$ vim Makefile.gfortran
and build all program in one shot
$ make -f Makefile.gfortran
gfortran -c -I../src -O ../src/xrotor.f
gfortran -c -I../src -O ../src/xoper.f
gfortran -c -I../src -O ../src/xdesi.f
gfortran -c -I../src -O ../src/xmodi.f
...
gfortran -c -I../src -O ../src/plotdata.f
gfortran -o xrotor xrotor.o xoper.o xdesi.o xmodi.o xaero.o xjmap.o xio.o xnoise.o xrotpl.o xcasepl.o xbend.o xinte.o xutils.o jputil.o plutil.o modify.o srclin.o spline.o userio.o vortex.o plotdata.o ../plotlib/libPlt.a -L/usr/lib -lX11
gfortran -c -I../src -O ../src/jplot.f
../src/jplot.f:107:72:
PAUSE 'Hit return to see J values'
1
Warning: Deleted feature: PAUSE statement at (1)
../src/jplot.f:112:72:
PAUSE 'Hit return to see CP values'
1
Warning: Deleted feature: PAUSE statement at (1)
gfortran -o jplot jplot.o xutils.o jputil.o userio.o ../plotlib/libPlt.a -L/usr/lib -lX11
gfortran -c -I../src -O ../src/jplote.f
gfortran -o jplote jplote.o xutils.o jputil.o userio.o ../plotlib/libPlt.a -L/usr/lib -lX11
The Warning means that the PAUSE command does not exist anymore so the progran will
likely not pause on the expected locations.
This could explain why it is not working as expected, but probably as the code is very old some code assumptions about the Unix system are not anymore valid.
Running it after starting the Xwindow graphic system from inside a Xterm
$ ./xrotor
=========================
XROTOR Version 7.55
=========================
Note: The following floating-point exceptions are signalling: IEEE_DENORMAL
STOP COLORSPECTRUM: Non-monotonic color axis. Check COLWIDTH.
Need to edit the COLORSPECTRUMTRP subroutine xrotor/plotlib/plt_color.f. Add the following after line 508
COLWIDTH=(/1.0,1.20000005,0.5,1.4,1.0,1.20000005,1.5/)

"Exec format error" running a binary created by g++

I have a problem with my QTCreator-generated Makefile. Everything is working fine except when I try to create myself a new executable file for my tests, my terminal says: bash: ./RunTests: cannot execute binary file: Exec format error
Here is how my MakeFile rule looks like:
TESTS: ../WannaBeRPG/testes.cpp ../WannaBeRPG/hero.h ../WannaBeRPG/charinterface.h
$(CXX) -c $(CXXFLAGS) $(INCPATH) -o RunTests ../WannaBeRPG/testes.cpp
Flags are:
CXX = g++
CXXFLAGS = -pipe -g -std=gnu++0x -Wall -W -fPIC $(DEFINES)
INCPATH = -I../WannaBeRPG -I. -I/usr/lib64/qt5/mkspecs/linux-g++
DEFINES = -DQT_QML_DEBUG
If that is anyhow helpful here is my testes.cpp file:
#include <gtest/gtest.h>
#include "hero.h"
TEST(teee, HPTEST)
{
Hero myHero("Hika",150,100,0,0,0,0,0,0,0);
EXPECT_EQ(100,myHero.getHP());
}
int main_tests(int argc, char* argv[])
{
testing::InitGoogleTest(&argc,argv);
return RUN_ALL_TESTS();
}
I am using Fedora.
Any ideas why does this works this way? Primary exec from this Makefile works completely fine.
The -c argument to g++ tells it not to link your binary. Thus, your output file is an object file rather than an executable.

Swap unix compiler flags with a shorter one

I've been running ns3 sumulations in linux and every time I compiled I had to type
g++ -Wall -o simulacija simulacija.cc -DNS3_ASSERT_ENABLE -DNS3_LOG_ENABLE `pkg-config --libs --cflags
libns3.16-core-debug libns3.16-network-debug libns3.16-applications-debug libns3.16-internet-debug
libns3.16-point-to-point-debug libns3.16-point-to-point-layout-debug libns3.16-csma-debug
libns3.16-csma-layout-debug libns3.16-topology-read-debug libns3.16-wifi-debug`
Is there a way to shorten the flags to eg:
g++ -Wall simulacija.cc -o simulacija -my_params
Thank you
The GCC compiler supports the # notation to embed a sequence of arguments inside a file. Read near end of GCC overall options page.
So you could put in some file params.args the following lines
-Wall
-I /usr/local
-DNS3_ASSERT_ENABLE
-DNS3_LOG_ENABLE
-O
and just invoke
g++ #params.args simulacija.cc -o simulacija
You could have a Makefile rule to build that params.args (e.g. with pkg-config etc...)
Actually, it is time to learn how to use GNU make.
Notice that the # option is not understood by some other compilers like GCC handles it.
You can create a shell script myparams.sh that outputs your parameters:
#!/bin/sh
echo -n "-DNS3_ASSERT_ENABLE -DNS3_LOG_ENABLE"
pkg-config --libs --cflags libns3.16-core-debug [...]
Now you can run
g++ -Wall simulacija.cc -o simulacija `./myparams.sh`
(Don't forget to chmod +x myparams.sh)

Resources