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.
Related
My main development platform is Gentoo on Linux. However, recently I tried to build my program on the fresh VM install on Debian.
My program contains of main binary and couple of dll/so/dylib libraries. One of the libraries depends on the presence of unixODBC/iODBC.
I was told by unixODBC maintainers to use odbc_config script to identify the build parameters.
When I build on Gentoo - everything works fine. There is no problems.
However, when I build on Debian - the build fails because apparently Debian does not produce odbc_config script and instead in this case rely on pkg-config.
So, I need to add a test in configure.ac to check for odbc_config script presence and pass it along to one of the so files generation (lets call it libodbc_lib project).
Could someone please help me with this?
EDIT:
Is this correct to be put in configure.ac:
AC_CHECK_PROG(ODBC,odbc_config,yes)
if test x"${ODBC}" == x"yes" ; then
ODBC_CFLAGS = `odbc_config --cflags`
ODBC_LIBS = `odbc_config --libs` -lodbcinst
else
ODBC_CFLAGS = `pkg-config odbc --cflags`
ODBC_LIBS = `pkg-config odbc --libs` -lodbcinst
fi
AC_SUBST(ODBC_CFLAGS)
AC_SUBST(ODBC_LIBS)
If it is - how do I use ODBC_FLAGS/ODBC_LIBS in my subproject?
EDIT2:
Based on this answer I used the following code:
In the main configure.ac:
AC_CHECK_PROG(ODBC,odbc_config,yes)
if test x"${ODBC}" == x"yes" ; then
ODBC_CFLAGS = `odbc_config --cflags`
ODBC_LIBS = `odbc_config --libs` -lodbcinst
else
ODBC_CFLAGS = `pkg-config odbc --cflags`
ODBC_LIBS = `pkg-config odbc --libs` -lodbcinst
fi
AC_SUBST(ODBC_CFLAGS)
AC_SUBST(ODBC_LIBS)
In the libodbc_lib/Makefile.am:
libodbc_lib_la_CXXFLAGS = -I../../dbinterface \
-DUNICODE \
-DUNIXODBC \
-I#ODBC_CFLAGS#
libodbc_lib_la_LDFLAGS = -L../dbinterface \
-ldbinterface \
#ODBC_LIB#
I regenerated configure, run it successfully and then tried running make.
I got following error:
CXXLD libodbc_lib.la
/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find #ODBC_LIB#: No such file or directory
What I did wrong?
EDIT3:
After fixing the missing S, I got following compile commands:
make[2]: Entering directory '/home/igor/dbhandler/Debug/libodbc'
/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I/home/igor/dbhandler/libodbc -I.. -I../../dbinterface -DUNICODE -DUNIXODBC -I#IODBC_CFLAGS# -g -O0 -MT libodbc_lib_la-database_odbc.lo -MD -MP -MF .deps/libodbc_lib_la-database_odbc.Tpo -c -o libodbc_lib_la-database_odbc.lo `test -f 'database_odbc.cpp' || echo '/home/igor/dbhandler/libodbc/'`database_odbc.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I/home/igor/dbhandler/libodbc -I.. -I../../dbinterface -DUNICODE -DUNIXODBC -I#IODBC_CFLAGS# -g -O0 -MT libodbc_lib_la-database_odbc.lo -MD -MP -MF .deps/libodbc_lib_la-database_odbc.Tpo -c /home/igor/dbhandler/libodbc/database_odbc.cpp -fPIC -DPIC -o .libs/libodbc_lib_la-database_odbc.o
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I/home/igor/dbhandler/libodbc -I.. -I../../dbinterface -DUNICODE -DUNIXODBC -I#IODBC_CFLAGS# -g -O0 -MT libodbc_lib_la-database_odbc.lo -MD -MP -MF .deps/libodbc_lib_la-database_odbc.Tpo -c /home/igor/dbhandler/libodbc/database_odbc.cpp -o libodbc_lib_la-database_odbc.o >/dev/null 2>&1
mv -f .deps/libodbc_lib_la-database_odbc.Tpo .deps/libodbc_lib_la-database_odbc.Plo
/bin/sh ../libtool --tag=CXX --mode=link g++ -I../../dbinterface -DUNICODE -DUNIXODBC -I#IODBC_CFLAGS# -g -O0 -L../dbinterface -ldbinterface -o libodbc_lib.la -rpath /usr/local/lib libodbc_lib_la-database_odbc.lo
libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/crtbeginS.o .libs/libodbc_lib_la-database_odbc.o -L../dbinterface -ldbinterface -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../lib64/crtn.o -g -O0 -Wl,-soname -Wl,libodbc_lib.so.0 -o .libs/libodbc_lib.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libodbc_lib.so.0" && ln -s "libodbc_lib.so.0.0.0" "libodbc_lib.so.0")
libtool: link: (cd ".libs" && rm -f "libodbc_lib.so" && ln -s "libodbc_lib.so.0.0.0" "libodbc_lib.so")
libtool: link: ar cru .libs/libodbc_lib.a libodbc_lib_la-database_odbc.o
libtool: link: ranlib .libs/libodbc_lib.a
libtool: link: ( cd ".libs" && rm -f "libodbc_lib.la" && ln -s "../libodbc_lib.la" "libodbc_lib.la" )
make[2]: Leaving directory '/home/igor/dbhandler/Debug/libodbc'
I still the variable name there and not their values.
Is it normal?
As UnixODBC upstream does ship and install *.pc files, I would expect that file to be both present and correct and therefore I would ignore any *-config scripts. The pkg-config system is quite well thought out and works even for quite weird cross compilation environments. The *.pc mechanism works well on Linux, on FreeBSD, on OSX, cross-compiling for Windows on Linux, to name a few.
A well-written _config program written in portable shell could do the same by basically reproducing much of the pkg-config logic in portable shell for each and every _config script, hopefully correctly.
However, odbc_config is not a portable shell script. It is a binary executable, i.e. it will regularly break for cross-compiling, as the system you build on will usually not be able to run programs like odbc_config which are built to run on the system you are building for.
And even if the flags from the *.pc files were unsuitable for a very unusual build environment: Using PKG_CHECK_MODULES defines appropriate _CFLAGS and _LIBS variables for the configure script, so even in a very unusual build environments one can always override whatever the *.pc file might contain by calling configure like
../configure ODBC_CFLAGS='-I/weird/stuff -DWEIRD_STRING="moo"' ODBC_LIBS='-L/very/weird/libxyz -lodbc'
So... using odbc_config has no advantages, upstream already provides a odbc.pc file so it is always present, so why not just always use odbc.pc?
So, in configure.ac (if builds without odbc.pc present should fail, otherwise you will have to do some AC_DEFINE and/or AM_CONDITIONAL to conditionally build with or without ODBC support) do
m4_pattern_forbid([PKG_CHECK_MODULES])dnl
PKG_CHECK_MODULES([ODBC], [odbc])
and in any subdirectory (what you call "subproject") Makefile.am or Makefile-files where you need to link somehting against libodbc, put, depending on whether you are building an executable
bin_PROGRAMS += foobar
[…]
foobar_CPPFLAGS += $(ODBC_CFLAGS)
foobar_LDADD += $(ODBC_LIBS)
or a (libtool) library
lib_LTLIBRARIES += libfoo.la
[…]
libfoo_la_CPPFLAGS += $(ODBC_CFLAGS)
libfoo_la_LIBADD += $(ODBC_LIBS)
That should work for all native and cross-compile builds in properly set up build environments, and people can still override odbc_CFLAGS and odbc_LIBS in case of problems.
Of course, you can always AC_CHECK_PROG or AC_PATH_PROG or AC_CHECK_TOOL or AC_PATH_TOOL together with an AC_ARG_VAR for the odbc_config program and then define and AC_SUBST an _CFLAGS and _LIBS variable set to the output of $ODBC_CONFIG --cflags and $ODBC_CONFIG --libs, respectively, and then then use the _CFLAGS and _LIBS vars in Makefile.am/Makefile-files as above.
However, that is a lot of code to write, and with a lot of special cases to consider, and if you have to ask about how to do this you will probably get a lot more wrong than if you just just use PKG_CHECK_MODULES.
You can always add something later if the PKG_CHECK_MODULES route actually does not work for a use case and which cannot be fixed within the pkg-config framework. Until that time (if it ever happens), I would recommend to just use the simple PKG_CHECK_MODULES method and probably be done.
So, I need to add a test in configure.ac to check for odbc_config script presence and pass it along to one of the so files generation
Autoconf has AC_PATH_PROG() for checking for a program in the executable search path. You would of course use AC_SUBST() to define one or more output variables by which to convey the results to the generated makefiles.
But no, coming back around to my comment on the answer to one of your previous questions, what you ought to do is not have configure forward information about the executable, but rather for it to determine the needed flags itself and forward them, via one or more output variables. If you continue to use odbc_config, at least conditionally, then that means having configure run it and capture the output. You should not inject shell command substitutions into your compilation commands.
And if you substitute a different mechanism, whether conditionally or exclusively, then similarly for that. (That's what your other answer describes with respect to pkg-config.)
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
I am quite new to cross compiling. After downloading the arm-linux-gnueabihf tool from arm. I tried to use the binary called arm-linux-gnueabihf-g++ and arm-linux-gnueabihf-gcc to compile my code. My command looks something like:
~/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc -Isrc -I/usr/include -std=c++11 -Wall -Wno-unknown-pragmas -O0 -g3 -D__DEBUG_BUILD__ -DDEVELOPMENT -MMD -c -o "Debug/src/BatteryStatus.o" "src/BatteryStatus.cpp"
I immediately run into this issue:
~/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/arm-linux-gnueabihf/libc/usr/include/stdlib.h:133:35: error: missing binary operator before token "("
#if __HAVE_FLOAT16 && __GLIBC_USE (IEC_60559_TYPES_EXT)
It's weird that the issue happens in the tool chain, I would expect some incompatibilities in the libraries I am using. The environment entails CentOS 7.2, c++ 11 and I am compiling for an ARM 32-bit target on a x86_64 host machine. Building a simple hello world program went fine, it compiled and ran successfully on the target machine.
You are pointing to your native header files directory, /usr/include, in your build command. This is very likely the cause of your problem. Try this command instead:
~/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc -Isrc -std=c++11 -Wall -Wno-unknown-pragmas -O0 -g3 -D__DEBUG_BUILD__ -DDEVELOPMENT -MMD -c -o "Debug/src/BatteryStatus.o" "src/BatteryStatus.cpp
The default directories used by the toolchain can be displayed using:
echo | /opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc -v -x c -E -
Using built-in specs.
COLLECT_GCC=/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc
Target: arm-linux-gnueabihf
Configured with: /tmp/dgboter/bbs/rhev-vm8--rhe6x86_64/buildbot/rhe6x86_64--arm-linux-gnueabihf/build/src/gcc/configure --target=arm-linux-gnueabihf --prefix= --with-sysroot=/arm-linux-gnueabihf/libc --with-build-sysroot=/tmp/dgboter/bbs/rhev-vm8--rhe6x86_64/buildbot/rhe6x86_64--arm-linux-gnueabihf/build/build-arm-linux-gnueabihf/install//arm-linux-gnueabihf/libc --with-bugurl=https://bugs.linaro.org/ --enable-gnu-indirect-function --enable-shared --disable-libssp --disable-libmudflap --enable-checking=release --enable-languages=c,c++,fortran --with-gmp=/tmp/dgboter/bbs/rhev-vm8--rhe6x86_64/buildbot/rhe6x86_64--arm-linux-gnueabihf/build/build-arm-linux-gnueabihf/host-tools --with-mpfr=/tmp/dgboter/bbs/rhev-vm8--rhe6x86_64/buildbot/rhe6x86_64--arm-linux-gnueabihf/build/build-arm-linux-gnueabihf/host-tools --with-mpc=/tmp/dgboter/bbs/rhev-vm8--rhe6x86_64/buildbot/rhe6x86_64--arm-linux-gnueabihf/build/build-arm-linux-gnueabihf/host-tools --with-isl=/tmp/dgboter/bbs/rhev-vm8--rhe6x86_64/buildbot/rhe6x86_64--arm-linux-gnueabihf/build/build-arm-linux-gnueabihf/host-tools --with-arch=armv7-a --with-fpu=neon --with-float=hard --with-arch=armv7-a --with-pkgversion='GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)'
Thread model: posix
gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))
COLLECT_GCC_OPTIONS='-v' '-E' '-mfloat-abi=hard' '-mfpu=neon' '-mtls-dialect=gnu' '-marm' '-march=armv7-a+simd'
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../libexec/gcc/arm-linux-gnueabihf/8.3.0/cc1 -E -quiet -v -iprefix /opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/ -isysroot /opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../arm-linux-gnueabihf/libc - -mfloat-abi=hard -mfpu=neon -mtls-dialect=gnu -marm -march=armv7-a+simd
ignoring duplicate directory "/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/../../lib/gcc/arm-linux-gnueabihf/8.3.0/include"
ignoring nonexistent directory "/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../arm-linux-gnueabihf/libc/usr/local/include"
ignoring duplicate directory "/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/../../lib/gcc/arm-linux-gnueabihf/8.3.0/include-fixed"
ignoring duplicate directory "/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/../../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/include
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/include-fixed
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/include
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../arm-linux-gnueabihf/libc/usr/include
End of search list.
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/arm-linux-gnueabihf/libc/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "<stdin>"
COMPILER_PATH=/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../libexec/gcc/arm-linux-gnueabihf/8.3.0/:/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../libexec/gcc/:/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/bin/
LIBRARY_PATH=/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/:/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/:/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/lib/:/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../arm-linux-gnueabihf/libc/lib/:/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../arm-linux-gnueabihf/libc/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-E' '-mfloat-abi=hard' '-mfpu=neon' '-mtls-dialect=gnu' '-marm' '-march=armv7-a+simd'
That is, on my system, the correct, default directories for the header files would be:
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/include
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/include-fixed
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/include
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../arm-linux-gnueabihf/libc/usr/include
and not /usr/include.
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 have inherited a powerpc project that built fine under a SUSE linux environment back around 2008. My goal is to build the same thing in Linux Mint (v 17). The target processor is a powerpc, which is set in the environment variables, I believe. During the build on Mint linux, it produces the following error:
developer#Will-test-Mint-VM ~/temp/linux.apps $ make -f Makefile.runme
make DESTDIR=`pwd`/tmp install
make[1]: Entering directory `/home/developer/temp/linux.apps'
Making install in libStreamerControl
make[2]: Entering directory `/home/developer/temp/linux.apps/libStreamerControl'
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -ffixed-r14 -meabi -fno-builtin -std=gnu99 -Wall -g -O2 -MT streamerControl.lo -MD -MP -MF .deps/streamerControl.Tpo -c -o streamerControl.lo streamerControl.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -ffixed-r14 -meabi -fno-builtin -std=gnu99 -Wall -g -O2 -MT streamerControl.lo -MD -MP -MF .deps/streamerControl.Tpo -c streamerControl.c -o streamerControl.o
gcc: error: unrecognized command line option '-meabi'
make[2]: *** [streamerControl.lo] Error 1
...
It is complaining about the -meabi option. I have installed/updated some packages that may be relevant (updated versions of eldk-5.6, automake, libtool, and powerpc-linux-gnu-gcc 4.8.2).
Specifically, I would like to know about the -meabi option. I didn't find a lot about it. What could be causing the compiler to not know what it is? I saw the output build from the SUSE setup, and it handled the -meabi option fine. Any suggestions?
Thanks,
Will
From your comment, it sounds like you're cross compiling here (ie., your build architecture is not the same as your host architecture). In this case, your (build) gcc won't recognise -meabi, as it's only valid for the host gcc.
So, you'll need to get your project building with the correct compiler for this to work. The method to do this will depend on the makefiles in your project. You've mentioned ARCH and CROSS_COMPILE, but these variables are specific to the Linux kernel's build system.
At a guess, your makefiles probably use some fairly standard variables to control the choice of compiler & toolchain, like CC, LD, etc. Try something like:
make -f Makefile.runme CC=powerpc-linux-gnu-gcc LD=powerpc-linux-gnu-ld
If your compile still fails, you may need to provide sources (or links to) your Makefiles.