I want to use riscv-gcc to implement an Ibex (RISCV core) example on an Arty-A7 but I haven't been able to build it properly.
It's been failing after the 'make' phase. It seems to have something to do with zlib however I'm not so sure since this is the first time I'm building anything from source. I got the source from https://github.com/riscv/riscv-gcc
I've configure it executed make as
../riscv-gcc/configure --enable-multilib
make
it then exits with the following error
checking whether the gcc -m32 linker (ld -m elf_x86_64 -m elf_i386) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
make[2]: *** [configure-stage1-zlib] Error 1
make[2]: Leaving directory `/home/alfred/Desktop/Work/riscv_gcc_install'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/alfred/Desktop/Work/riscv_gcc_install'
make: *** [all] Error 2
I've also tried running make (same configuration) with
make all-gcc
but it produces this error instead
checking if gcc -m32 supports -fno-rtti -fno-exceptions... no
checking for gcc -m32 option to produce PIC... -fPIC -DPIC
checking if gcc -m32 PIC flag -fPIC -DPIC works... yes
checking if gcc -m32 static flag -static works... no
checking if gcc -m32 supports -c -o file.o... yes
checking if gcc -m32 supports -c -o file.o... (cached) yes
checking whether the gcc -m32 linker (ld -m elf_x86_64 -m elf_i386) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
make: *** [configure-zlib] Error 1
I'm not sure what to do so far besides check prerequisite libraries as suggested by https://gcc.gnu.org/install/prerequisites.html . Can Anyone help me out?
[UPDATE 27/11/19]
I tried to install the complete riscv-gnu-toolchain from < https://github.com/riscv/riscv-gnu-toolchain> to avoid missing dependencies however I still had an error. I did run the suggested apt-get command to install the prerequisites.
I ran the configuration suggested to target riscv32 and proceeded with make as follows
./configure --prefix=/opt/riscv --with-arch=rv32gc --with-abi=ilp32d
make linux
I then got this error
make[3]: Entering directory `/home/alfred/Desktop/Work/riscv-gnu-toolchain/build-binutils-linux/binutils'
/bin/bash /home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/../ylwrap /home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/arparse.y y.tab.c arparse.c y.tab.h `echo arparse.c | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e s/c++$/h++/ -e s/c$/h/` y.output arparse.output -- bison -y -d
m4: unrecognized option '--gnu'
Try `m4 --help' for more information.
make[4]: Entering directory `/home/alfred/Desktop/Work/riscv-gnu-toolchain/build-binutils-linux/binutils'
/bin/bash /home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/../ylwrap /home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/arparse.y y.tab.c arparse.c y.tab.h `echo arparse.c | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e s/c++$/h++/ -e s/c$/h/` y.output arparse.output -- bison -y -d
m4: unrecognized option '--gnu'
Try `m4 --help' for more information.
make[4]: Leaving directory `/home/alfred/Desktop/Work/riscv-gnu-toolchain/build-binutils-linux/binutils'
/bin/bash /home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/../ylwrap /home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/sysinfo.y y.tab.c sysinfo.c y.tab.h `echo sysinfo.c | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e s/c++$/h++/ -e s/c$/h/` y.output sysinfo.output -- bison -y -d
/home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/sysinfo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
m4: unrecognized option '--gnu'
Try `m4 --help' for more information.
if [ -r sysinfo.c ]; then \
gcc -c -I. -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -I/home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/../zlib -g -O2 sysinfo.c ; \
else \
gcc -c -I. -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -I/home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/../zlib -g -O2 /home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/sysinfo.c ; \
fi
gcc: error: /home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/sysinfo.c: No such file or directory
gcc: fatal error: no input files
compilation terminated.
make[3]: *** [sysinfo.o] Error 4
make[3]: Leaving directory `/home/alfred/Desktop/Work/riscv-gnu-toolchain/build-binutils-linux/binutils'
make[2]: *** [all-binutils] Error 2
make[2]: Leaving directory `/home/alfred/Desktop/Work/riscv-gnu-toolchain/build-binutils-linux'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/alfred/Desktop/Work/riscv-gnu-toolchain/build-binutils-linux'
make: *** [stamps/build-binutils-linux] Error 2
I noticed that m4 did not recognize a certain argument
--gnu
should I be concerned with this?
[UPDATE 16/12/2019]
As recommended, I tried to build the tool-chain in Ubuntu 18.04.03 (originally I was on 14.04) and it seems to have solved the problem quite well! Turns out that the tool-chain is indeed "fragile" when it comes to OS dependencies. Thanks so much for the help!
The error "Link tests are not allowed" is something connected to incomplete toolchain (like ld, binutils, libc), similar to report inhttps://gcc.gnu.org/ml/gcc-help/2012-07/msg00018.html.
It is unclear from your question which instruction did you use to build gcc. I think you should search not for gcc only build, but for complete toolchain instruction like https://github.com/riscv/riscv-gnu-toolchain or something from Ibex authors web-site.
Ibex documentation in page https://ibex-core.readthedocs.io/en/latest/verification.html#getting-started has some link to "GCC setup", but it is for verification and without complete instruction.
In issue https://github.com/riscv/riscv-gcc/issues/143 there is information that "You can't build gcc without binutils." and "You can't build a useful gcc without a C library.", so try to build complete toolchain, not the gcc only.
In earlier project by lowrisc there was instruction to build toolchain (combined gcc + binutils + newlib): https://www.lowrisc.org/blog/2017/09/building-upstream-risc-v-gccbinutilsnewlib-the-quick-and-dirty-way/ - you may want to modify the instruction with another git (riscv-gcc). Or just try https://github.com/riscv/riscv-gnu-toolchain
I have found that the RISC-V toolchain is very fragile with respect to OS dependencies. The toolchain team uses Ubuntu 16, and a lot of errors folks see arise from the changes to the Linux ecosystem since that version.
I got around this issue by creating a Vagrantfile that is configured to use Ubuntu 16, and goes through the official steps, and at least for me, it builds the tools just fine. If you're interested, it's posted inside the stackoverflow question I asked along these lines. If you need to configure the tools differently, it's straightforward to do in the Vagrantfile.
Try this version for integer riscv. I tried it already and passed.
git clone https://github.com/riscv/riscv-gnu-toolchain
git checkout 411d134
git submodule update --init --recursive
mkdir build
cd build
../configure --prefix=/opt/riscv32i --with-arch=rv32i --with-abi=ilp32
make -j8
If your riscv has mul/div module, add M standard extension.
../configure --prefix=/opt/riscv32im --with-arch=rv32im --with-abi=ilp32
If your riscv is 64-bit integer core:
../configure --prefix=/opt/riscv64i --with-arch=riscv64i --with-abi=lp64
select option that you want to build:
"M" Standard Extension for Integer Multiplication and Divison
"A" Standard Extension for Atomic Instructions
"F" Standard Extension for Single-Precision Floating-Point
"D" Standard Extension for Double-Precision Floating-Point
"Q" Standard Extension for Quard-Precision Floating-point
"C" Standard Extension for Compressed Instruction
"G" combination of I, M, A, F and D.
ilp32/ilp32f/ilp32d int-32bits long-32bits pointer-32bits
lp64/lp64f/lp64d int-32bits long-64bits pointer-64bits
The vexrisc full project implement riscv on arty a7 35t, includes toolchain compile and using IntelliJ IDE build riscv project and internal USB jtag debugging may help you.
https://fatalfeel.blogspot.com/2013/12/risc-v-on-arty-a7-35t.html
Maybe you want to try Linux on riscv. It's based on vexrisc
https://github.com/SpinalHDL/SaxonSoc
Related
This is a curiosity question: why?
Why does it have a different behavior for the exact same code?
I often have the issue that I can compile something in one distribution but not in another. So today I bumped into one of those issue again where when I build in the same way PostgreSQL's pg_dump with ArchLinux it works, but when I do it on Alpine it fails with this error:
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -static -fPIC -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fPIC -shared -Wl,-soname,libpq.so.5 -Wl,--version-script=exports.list -o libpq.so.5.11 fe-auth.o fe-auth-scram.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o fe-secure.o libpq-events.o chklocale.o inet_net_ntop.o noblock.o pgstrcasecmp.o pqsignal.o thread.o getpeereid.o pg_strong_random.o encnames.o wchar.o base64.o ip.o md5.o scram-common.o saslprep.o unicode_norm.o sha2.o -L../../../src/port -L../../../src/common -Wl,--as-needed -Wl,-rpath,'/usr/local/pgsql/lib',--enable-new-dtags
/lib/gcc/x86_64-linux-musl/8.2.0/../../../../x86_64-linux-musl/bin/ld: /lib/gcc/x86_64-linux-musl/8.2.0/crtbeginT.o: relocation R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when making a shared object
/lib/gcc/x86_64-linux-musl/8.2.0/../../../../x86_64-linux-musl/bin/ld: /lib/gcc/x86_64-linux-musl/8.2.0/crtend.o: relocation R_X86_64_32 against `.ctors' can not be used when making a shared object; recompile with -fPIC
/lib/gcc/x86_64-linux-musl/8.2.0/../../../../x86_64-linux-musl/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[1]: Leaving directory '/src/src/interfaces/libpq'
make[1]: *** [../../../src/Makefile.shlib:309: libpq.so.5.11] Error 1
make: *** [../../../src/Makefile.global:580: submake-libpq] Error 2
Here is the Dockerfile for Alpine:
FROM muslcc/x86_64:x86_64-linux-musl
RUN apk update && apk add make
ENV DOWNLOAD_URL https://ftp.postgresql.org/pub/source/v11.2/postgresql-11.2.tar.bz2
WORKDIR /src
RUN wget "$DOWNLOAD_URL" && \
tar xvjf "${DOWNLOAD_URL##*/}" --strip-components=1 && \
rm -fv "${DOWNLOAD_URL##*/}"
# NOTE: I left the -fPIC here for clarity sake but it fails with
# the same error with or without it
RUN ./configure --without-readline --without-zlib CFLAGS="-static -fPIC"
RUN cd src/bin/pg_dump && make pg_dump
Here is the Dockerfile for ArchLinux:
FROM archlinux/base
RUN pacman -Syu --noconfirm --needed base-devel musl
ENV DOWNLOAD_URL https://ftp.postgresql.org/pub/source/v11.2/postgresql-11.2.tar.bz2
WORKDIR /src
RUN curl -o "${DOWNLOAD_URL##*/}" "$DOWNLOAD_URL" && \
tar xvjf "${DOWNLOAD_URL##*/}" --strip-components=1 && \
rm -fv "${DOWNLOAD_URL##*/}"
RUN ./configure --without-readline --without-zlib CC="musl-gcc" CFLAGS="-static"
RUN cd src/bin/pg_dump && make pg_dump
I don't even know where to look at. Could it be a difference of version of musl? Another compiling tool? I don't really want the solution, I want to understand why.
I don't have that much experience with Alpine Linux and I would need to play with it myself, but it seems some pretty basic standard C libraries are built as non-platform-independent-code (PIC), which means you aren't allowed to link a dynamic library with it.
I'd start chasing Alpine Linux developers about this, because there are probably configuration flags for PostgreSQL which would allow you to build what you want.
Now, I've notices one thing. You pass CFLAGS=-static to the compilation, but it's pointless as ./configure already set it up as shared - look carefully at the compiler invocation you quote. If you want static build, you need to find a proper configuration flag and use it with ./configure. I your case --disable-shared should work.
CFLAGS="-static" CXXFLAGS="-static" LDFLAGS="-Wl,-Bstatic" ./configure --without-readline --without-zlib
seem to enable -static without leaving -shared.
I'm trying to use mpi-ikl-simplemkl-1.0 (http://www.mloss.org/software/view/174/)
I'm using Windows 8.1 and I've installed cgywin64. When I type (on cgywin bash screen):
make -f Makefile
The result is:
gcc-4.2 -03 -ffast-math -fomit-frame-pointer -fPIC -c -o svm.o svm.cpp
gcc-4.2: error: spawn: No such file or directory
makefile:32: recipe for target 'svm.o' failed
make: *** [svm.o] Error 1
What should I do?
The internet wisdom seems to be that you should do one of:
Remove /bin from PATH
Remove /usr/bin from PATH
Reinstall gcc (possibly remove all versions of gcc first)
I installed the protobuf complier following:
Download Protocol Buffers full source from here: http://code.google.com/p/protobuf/downloads/list
Extract it and go to the extraction directory from terminal
1.Run ./configure
2.Run make
3.Run sudo make install
After I run make, the error shows. someone know how to fix it?
Thanks in advance!!
/Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive
Making all in .
Making all in src
/bin/sh ../libtool --tag=CXX --mode=link g++ -D_THREAD_SAFE -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -O2 -g -DNDEBUG -D_THREAD_SAFE -o protoc main.o libprotobuf.la libprotoc.la -lz
libtool: link: cannot find the library 2/src/libprotobuf.la' or unhandled argument2/src/libprotobuf.la'
make[2]: * [protoc] Error 1
make[1]: * [all-recursive] Error 1
make: * [all] Error 2
I'm seeing this too - and I diagnosed the problem. It's simple enough - the download directory path contains a space character. Simply move or rename the download directory so it no longer contains a space character and everything works.
Please see my bug report here.
I'm trying to install openssl in cygwin by following these instructions:
I dowloaded the latest tarball from this site http://www.openssl.org/source/, and put it in C:\cygwin64\home, then I run these commands from cygwin
tar zxvf openssl-1.0.1e.tar.gz
cd openssl-1.0.1e
./config
make
make test
make install
(Instructions from here :http://www.slideshare.net/ganaaturuu/cygwinandopen-sslinstallguide)
Up to the 3rd step ./config it works fine I believe, at least there are no errors reported, and it gives the message "Configured for Cygwin." in the end. When I run make though it gives me this output:
making all in crypto...
make[1]: Entering directory '/home/openssl-1.0.1e/crypto'
( echo "#ifndef MK1MF_BUILD"; \
echo ' /* auto-generated by crypto/Makefile for crypto/cversion.c */'; \
echo ' #define CFLAGS "gcc -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DTERM IOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_ WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLP OOL_ASM -DGHASH_ASM"'; \
echo ' #define PLATFORM "Cygwin"'; \
echo " #define DATE \"`LC_ALL=C LC_TIME=C date`\""; \
echo '#endif' ) >buildinf.h
gcc -I. -I.. -I../include -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMI OS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_W ORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPO OL_ASM -DGHASH_ASM -c -o cryptlib.o cryptlib.c
cryptlib.c:1:0: error: CPU you selected does not support x86-64 instruction set
/* crypto/cryptlib.c */
^
cryptlib.c:1:0: error: CPU you selected does not support x86-64 instruction set
<builtin>: recipe for target 'cryptlib.o' failed
make[1]: *** [cryptlib.o] Error 1
make[1]: Leaving directory '/home/openssl-1.0.1e/crypto'
Makefile:278: recipe for target 'build_crypto' failed
make: *** [build_crypto] Error 1
I searched about the "CPU you selected does not support x86-64 instruction set" and I think it has to do with CFLAGS and -march=i486 option, but I'm not at all sure as into what it should be changed.
In this How to compile a C++ program as 64-bit on 64-bit machine? question there are some solutions suggested, but in my case there are nowhere in the makefile options like -m32 and -march=i686 to remove.
If you could please show me the right direction to search this, if not the solution, I would be grateful.
I'm working on Windows 7 64-bit, with cygwin and gcc version 4.8.2.
Here's a "mee too" answer because things have changed a bit. Cygwin-x64 support was cut-in in May 2015 under Issue 3110: Adding support for x86_64 Cygwin.
However, config still selects the i686 version of the library to build. Also see Issue #4326: Failed to configure for Cygwin-x64 in the OpenSSL bug tracker.
To build OpenSSL 1.0.2 on Cygwin-x64, you have to use Configure and select the triplet. Below is the soup-to-nuts recipe.
$ curl https://www.openssl.org/source/openssl-1.0.2f.tar.gz -o openssl-1.0.2f.tar.gz
...
$ tar -xzf openssl-1.0.2f.tar.gz
...
$ cd openssl-1.0.2f
Then:
$ ./Configure Cygwin-x86_64 shared no-ssl2 no-ssl3 --openssldir="$HOME/ssl"
...
$ make depend
...
$ make
...
$ make install_sw
install_sw installs the headers in $OPENSSLDIR/include, and the libraries in $OPENSSLDIR/lib. It does not install the man pages.
You then compile and link with:
$ gcc -I "$HOME/ssl/include" test.c -o test.exe "$HOME/ssl/lib/libcrypto.a" "$HOME/ssl/lib/libssl.a"
Linking against libcrypto.a and libssl.a means you avoid library path problems. Things will "just work" for you.
Also, if you need this for OpenSSL 1.0.1, then you can copy/paste the triplet's settings from 1.0.2's Configure (from line 613):
$ grep "Cygwin-x86_64" Configure
"Cygwin-x86_64", "gcc:-DTERMIOS -DL_ENDIAN -O3 -Wall:::CYGWIN::SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:${x86_64_asm}:mingw64:dlfcn:cygwin-shared:-D_WINDLL:-shared:.dll.a",
If you want config to "just work" for 1.0.1, then add the following. Be sure the line for Cygwin-x86_64 was added to Configure.
x86_64-*-cygwin) OUT="Cygwin-x86_64" ;; <== Add this in front of the ones below
*-*-cygwin_pre1.3) OUT="Cygwin-pre1.3" ;;
*-*-cygwin) OUT="Cygwin" ;;
It would seem that 1.0.1 does not have support for Cygwin/x64.
This thread indicates that the necessary patches have been pulled into the 1.0.2 branch.
here is one post you can refer to. the basic idea is that specifying -march=x86-64 and avoid using assembly language. assembly language is not as portable as c language.
I'm trying to compile a program using a third party library, Omnet++ in my case. Apparently "make" does not find a library, but the path it uses is correct as you can see (in the sense that I can see the library under omnet++ source tree)
pv135168:basic Bob$ opp_makemake
Creating Makefile in /Users/Bob/Code/network_sim/basic... Makefile created, running "make depend" to add dependencies... opp_makedep -Y --objdirtree -I. -f Makefile -P\$O/ -- ./*.cc
pv135168:basic Bob$ make
g++ -c -g -Wall
-fno-stack-protector -m32 -DHAVE_PCAP -DXMLPARSER=libxml
-DWITH_PARSIM -DWITH_NETBUILDER -I.
-I/Users/Bob/Code/omnetpp-4.1/include -o out/gcc-debug//txc1.o txc1.cc g++ -m32 -Wl,-rpath,/Users/Bob/Code/omnetpp-4.1/lib -Wl,-rpath,. -o out/gcc-debug//basic out/gcc-debug//txc1.o -Wl,-all_load
-L"/Users/Bob/Code/omnetpp-4.1/lib/gcc"
-L"/Users/Bob/Code/omnetpp-4.1/lib" -u _tkenv_lib -lopptkenvd
-loppenvird -lopplayoutd -u _cmdenv_lib -loppcmdenvd -loppenvird
-loppsimd -lstdc++
ld: library not found for -lopptkenvd
collect2: ld returned 1 exit status make: *** [out/gcc-debug//basic]
Error 1 pv135168:basic Bob$
It's looking in the following directories for a file called libopptkenvd.dylib or libopptkenvd.a:
/Users/Bob/Code/omnetpp-4.1/lib/gcc
/Users/Bob/Code/omnetpp-4.1/lib
Is that file in one of those directories (or in the standard directories like /usr/lib)? I don't see an indication of that in your output.