unresolved symbol vec_add_ - fortran

First, my source programs are shown as follows:
call_fun.f90
program call_fun
use omp_lib
implicit none
integer, parameter :: N = 100
integer a(N), b(N), c(N)
integer i
do i = 1, N
a(i) = i
b(i) = i+1
end do
!$omp target
!$omp parallel do
do i = 1, N
call vec_add(a(i), b(i), c(i))
end do
!$omp end target
write(*,10) N, c(N)
10 format('c[', I4, ']=', I6)
end program
vec_add.f90
subroutine vec_add(a, b, c)
implicit none
integer a, b, c
c = a + b
end
Obviously, this two programs are simple, and I just for testing. Then, I use following commands to compile and link the programs:
gfortran -fopenmp -foffload=nvptx-none -c vec_add.f90 call_fun.f90
gfortran -fopenmp -foffload=nvptx-none call_fun.o vec_add.o -o call.x
finally, I received followed error reports:
unresolved symbol vec_add_
collect2: 错误:ld 返回 1
mkoffload: fatal error: x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned 1
exit status
compilation terminated.
lto-wrapper: 致命错误:/home/gjh/software/offload/install/libexec/gcc/x86_64-
pc-linux-gnu/9.0.0//accel/nvptx-none/mkoffload 以返回值 1 退出
编译中断。
/usr/bin/x86_64-linux-gnu-ld: error: lto-wrapper failed
collect2: 错误:ld 返回 1
It seems that linker can't find vec_add_, but I don't know how to fix it. My GCC version is 9.0.0(20180605), and corresponding OpenMP version is 4.5. I don't know if it doesn't support the function call in the task construct, or some others reasons. Has anyone encountered such problem?
More detailed, I used following script to configure environment:
#!/bin/sh
#
# Build GCC with support for offloading to NVIDIA GPUs
#
work_dir=$HOME/software/offload
install_dir=$work_dir/install
# Location of the installed CUDA toolkit
cuda=/usr/local/cuda
# Build assembler and linking tools
cd $work_dir
git clone https://github.com/MentorEmbedded/nvptx-tools
cd nvptx-tools
./configure \
--with-cuda-driver-include=$cuda/include \
--with-cuda-driver-lib=$cuda/lib64 \
--enable-languages="c,c++,fortran,lto" \
--prefix=$install_dir
make clean
make
make install
cd ../
# Set up the GCC source tree
git clone https://github.com/MentorEmbedded/nvptx-newlib
svn co svn://gcc.gnu.org/svn/gcc/trunk gcc
cd gcc
contrib/download_prerequistes
ln -s ../nvptx-newlib/newlib newlib
cd ..
target=$(gcc/config.guess)
# Build nvptx GCC
mkdir build-nvptx-gcc
cd build-nvptx-gcc
../gcc/configure \
--target=nvptx-none --with-build-time-tools=$install_dir/nvptx-none/bin \
--enable-as-accelerator-for=$target \
--disable-sjlj-exceptions \
--enable-newlib-io-long-long \
--enable-languages="c,c++,fortran,lto" \
--prefix=$install_dir
make clean
make -j4
make install
cd ..
# Build host GCC
mkdir build-host-gcc
cd build-host-gcc
../gcc/configure \
--enable-offload-targets=nvptx-none \
--with-cuda-driver-include=$cuda/include \
--with-cuda-driver-lib=$cuda/lib64 \
--disable-bootstrap \
--disable-multilib \
--enable-languages="c,c++,fortran,lto" \
--prefix=$install_dir
make clean
make -j4
make install
cd ..
this script was written by other people, and I referenced to it. In addition, I set environment variables as follows.
export LD_LIBRARY_PATH=/usr/local/cuda-9.2/lib64:/home/gjh/software/offload/install/lib64:$LD_LIBRARY_PATH
export PATH=/usr/local/cuda-9.2/bin:/home/gjh/software/offload/install/bin:$PATH

Related

Cannot compile Makefile using make command on Windows

Problem summary
I am trying to install an open-source parallel finite-element code called TACS and available at this github repository. To comply with the indicated prerequisites, I followed the instructions at this github repository, which allowed me to install SuiteSparse and METIS on Windows with precompiled BLAS/LAPACK DLLs. For the MPI, I installed both the Intel MPI Library and Open MPI through Cygwin. The final step should be to compile running make, however this command is not directly available in Windows 10. As a consequence, I explored the options suggested in this question, unfortunately without success. I feel at a dead end, any help will be appreciated.
What I've tried
Please have a look below at my attempts. I am mainly a Windows user and I don't know much of compiling programs using Makefile. My current understanding is that the Makefile that I am trying to compile is written for Linux and whatever GNU compiler for Windows I use will not work because of the different syntax needed. Please correct me if I am wrong. What I can't understand is why I get errors also when I try to compile with Ubuntu Bash for Windows 10 (last attempt of the list below).
Visual Studio nmake
Running the Developer Command Prompt for VS 2019 as administrator, I typed nmake -f Makefile in TACS base directory and I got Makefile.in(28) : fatal error U1001: syntax error : illegal character '{' in macro Stop.
Chocolatey make
Running Windows Command Prompt as administrator with C:\ProgramData\chocolatey\bin at the top of PATH environment variable, I typed make in TACS base directory and I got
"" was unexpected at this time.
make: *** [Makefile:23: default] Error 255
Cygwin make
Running Windows Command Prompt as administrator with C:\cygwin64\bin at the top of PATH environment variables, I typed make in TACS base directory and I got three types of error:
error: expected ',' or '...' before numeric constant
error: cannot convert 'int*' to 'idx_t*' {aka 'long int*'}
error: no matching function for call to 'TACSSchurMat::getBCSRMat(BCSRMat**, NULL, NULL, NULL)'
I tried to change some variable names in the affected scripts (like N_ in place of _N) and I got rid of the first and the third type of error, but not of the second one.
GnuWin make
Running Windows Command Prompt as administrator with C:\Program Files (x86)\GnuWin32\bin at the top of PATH environment variables, I typed make in TACS base directory and I got
"" was unexpected at this time.
make: *** [Makefile:23: default] Error 255
MinGW mingw32-make
Running Windows Command Prompt as administrator with C:\MinGW\bin at the top of PATH environment variables, I typed mingw32-make in TACS base directory and I got
"" was unexpected at this time.
Makefile:23: recipe for target 'default' failed
mingw32-make: *** [default] Error 255
MSYS MinGW 64-bit make
Running Windows Command Prompt as administrator with C:\msys64\usr\bin at the top of PATH environment variables, I typed make in TACS base directory and I got
make[1]: mpicxx: No such file or directory
make[1]: *** [../TACS_Common.mk:28: C:/Users/qa21944/git/tacs/src/TACSAssembler.o] Error 127
make[1]: *** Waiting for unfinished jobs....
make[1]: mpicxx: No such file or directory
make[1]: *** [../TACS_Common.mk:28: C:/Users/qa21944/git/tacs/src/TACSCreator.o] Error 127
make[1]: Leaving directory '/c/Users/qa21944/git/tacs/src'
make: *** [Makefile:23: default] Error 1
This is quite difficult for me to understand, as the mpicxx file is C:\Program Files (x86)\Intel\oneAPI\mpi\latest\bin, which in turn is in the PATH environment variable. When I tried to add C:\cygwin64\bin to PATH (below C:\msys64\usr\bin) and to rerun make, I got
0 [main] opal_wrapper (14432) C:\cygwin64\bin\opal_wrapper.exe: *** fatal error - cygheap base mismatch detected - 0x180352408/0x180357408.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version. The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution. Rebooting is also suggested if you
are unable to find another cygwin DLL.
I tried to follow these instructions and then rebooted my computer, but nothing changed.
Ubuntu Bash for Windows 10 make
This attempt was inspired by this answer. I downloaded Ubuntu from Microsoft Store and installed make. From the Ubuntu Bash I typed make in TACS base directory and I got
make[1]: Entering directory '/mnt/c/Users/qa21944/git/tacs/src'
Makefile:26: *** target pattern contains no '%'. Stop.
make[1]: Leaving directory '/mnt/c/Users/qa21944/git/tacs/src'
make: *** [Makefile:23: default] Error 1
I do not understand why I should get this error. I also made sure that all lines started with a tab rather than white spaces, but nothing changed.
Codes
Below you can find the Makefile.in and Makefile that I am using.
Makefile.in
# Do not modify this file. Copy this file to Makefile.in and then modify it.
# In order to get TACS to compile, you'll need to fill in the
# following path information. Some of the items below are required
# only if you're going to use the python interface.
# the full path to the root TACS directory
TACS_DIR = C:/Users/qa21944/git/tacs
CXX = mpicxx
RM = rm -f
PYTHON = python
PYTHON_CONFIG = python-config
# Set up for parallel make
MAKE = make -j 8
# Set the ar flags
AR_FLAGS = rcs
# Flags for debugging and regular compilation versions
EXTRA_DEBUG_CC_FLAGS = -fPIC -g
EXTRA_CC_FLAGS = -fPIC -O3
# Use this if you have problems with mpich
# TACS_DEF = -DMPICH_IGNORE_CXX_SEEK
# Defines whether to use static or dynamic linking
# TACS_LD_CMD=${TACS_DIR}/lib/libtacs.a
TACS_LD_CMD=-L${TACS_DIR}/lib/ -Wl,-rpath,${TACS_DIR}/lib -ltacs
# For linux systems, use the following settings:
SO_EXT=so
SO_LINK_FLAGS=-fPIC -shared
# For MAC OS X, use the following settings:
# SO_EXT=so
# SO_LINK_FLAGS=-fPIC -dynamiclib
# This uses the default installation of LAPACK.
# Use an optimized version of LAPACK if available.
# You may also have to include -lblas as well.
LAPACK_LIBS = -LC:/SP_ROOT/lapack_windows/x64 -llapack -lpthread -lblas
# For MAC OSX use the accelerate framework
# LAPACK_LIBS=-framework accelerate
# METIS is handy for partitioning graphs, but can be problematic for
# compilation. If you compile METIS using a C++ compiler you must add
# -DTACS_CPLUSPLUS_METIS to the TACS_DEF arguments below. If you
# compile METIS using a C compiler, there should be no issues.
METIS_INCLUDE = -IC:/SP_ROOT/build/install/include
METIS_LIB = -LC:/SP_ROOT/build/install/lib -lmetis
# AMD is a set of routines for ordering matrices. It is not required by default.
AMD_INCLUDE = -IC:/SP_ROOT/build/install/include/suitesparse
AMD_LIBS = -LC:/SP_ROOT/build/install/lib -llibamd
Makefile
# ============================================
#
# Make file for TACS_DIR/
#
# ============================================
include Makefile.in
include TACS_Common.mk
TACS_SUBDIRS = src \
src/bpmat \
src/elements \
src/elements/dynamics \
src/elements/basis \
src/elements/shell \
src/constitutive \
src/functions \
src/io
TACS_OBJS := $(addsuffix /*.o, ${TACS_SUBDIRS})
default:
#if [ "${TACS_IS_COMPLEX}" = "true" ]; then \
echo "Building Complex TACS"; \
for subdir in $(TACS_SUBDIRS) ; do \
echo "making $# in $$subdir"; \
echo; (cd $$subdir && $(MAKE) TACS_DIR=${TACS_DIR} TACS_DEF="${TACS_DEF} -DTACS_USE_COMPLEX") || exit 1; \
done \
else \
echo "Building Real TACS"; \
for subdir in $(TACS_SUBDIRS) ; do \
echo "making $# in $$subdir"; \
echo; (cd $$subdir && $(MAKE) TACS_DIR=${TACS_DIR}) || exit 1; \
done \
fi
${CXX} ${SO_LINK_FLAGS} ${TACS_OBJS} ${TACS_EXTERN_LIBS} -o ${TACS_DIR}/lib/libtacs.${SO_EXT}
#if [ "${TACS_IS_COMPLEX}" = "true" ]; then \
echo "ctypedef complex TacsScalar" > tacs/TacsTypedefs.pxi; \
echo "TACS_NPY_SCALAR = np.NPY_CDOUBLE" > tacs/TacsDefs.pxi; \
echo "dtype = complex" >> tacs/TacsDefs.pxi; \
else \
echo "ctypedef double TacsScalar" > tacs/TacsTypedefs.pxi; \
echo "TACS_NPY_SCALAR = np.NPY_DOUBLE" > tacs/TacsDefs.pxi; \
echo "dtype = np.double" >> tacs/TacsDefs.pxi; \
fi
debug:
#if [ "${TACS_IS_COMPLEX}" = "true" ]; then \
echo "Building Complex TACS"; \
for subdir in $(TACS_SUBDIRS) ; do \
echo "making $# in $$subdir"; \
echo; (cd $$subdir && $(MAKE) debug TACS_DIR=${TACS_DIR} TACS_DEF="${TACS_DEF} -DTACS_USE_COMPLEX") || exit 1; \
done \
else \
echo "Building Real TACS"; \
for subdir in $(TACS_SUBDIRS) ; do \
echo "making $# in $$subdir"; \
echo; (cd $$subdir && $(MAKE) debug TACS_DIR=${TACS_DIR}) || exit 1; \
done \
fi
${CXX} ${SO_LINK_FLAGS} ${TACS_OBJS} ${TACS_EXTERN_LIBS} -o ${TACS_DIR}/lib/libtacs.${SO_EXT}
#if [ "${TACS_IS_COMPLEX}" = "true" ]; then \
echo "ctypedef complex TacsScalar" > tacs/TacsTypedefs.pxi; \
echo "TACS_NPY_SCALAR = np.NPY_CDOUBLE" > tacs/TacsDefs.pxi; \
echo "dtype = complex" >> tacs/TacsDefs.pxi; \
else \
echo "ctypedef double TacsScalar" > tacs/TacsTypedefs.pxi; \
echo "TACS_NPY_SCALAR = np.NPY_DOUBLE" > tacs/TacsDefs.pxi; \
echo "dtype = np.double" >> tacs/TacsDefs.pxi; \
fi
interface:
${PYTHON} setup.py build_ext --inplace
complex_interface:
${PYTHON} setup.py build_ext --inplace --define TACS_USE_COMPLEX
complex: TACS_IS_COMPLEX=true
complex: default
complex_debug: TACS_IS_COMPLEX=true
complex_debug: debug
clean:
${RM} lib/libtacs.a lib/libtacs.so
${RM} tacs/*.so tacs/*.cpp
#for subdir in $(TACS_SUBDIRS) ; do \
echo "making $# in $$subdir"; \
echo; \
(cd $$subdir && $(MAKE) $# TACS_DIR=${TACS_DIR}) || exit 1; \
done
Edit: I am adding a snippet of TACS_Common.mk as requested in the comments.
TACS_Common.mk
TACS_LIB = ${TACS_DIR}/lib/libtacs.a
TACS_INCLUDE = -I${TACS_DIR}/src \
-I${TACS_DIR}/src/bpmat \
-I${TACS_DIR}/src/elements \
-I${TACS_DIR}/src/elements/dynamics \
-I${TACS_DIR}/src/elements/basis \
-I${TACS_DIR}/src/elements/shell \
-I${TACS_DIR}/src/constitutive \
-I${TACS_DIR}/src/functions \
-I${TACS_DIR}/src/io
# Set the command line flags to use for compilation
TACS_OPT_CC_FLAGS = ${TACS_DEF} ${EXTRA_CC_FLAGS} ${METIS_INCLUDE} ${AMD_INCLUDE} ${TACS_INCLUDE}
TACS_DEBUG_CC_FLAGS = ${TACS_DEF} ${EXTRA_DEBUG_CC_FLAGS} ${METIS_INCLUDE} ${AMD_INCLUDE} ${TACS_INCLUDE}
# By default, use the optimized flags
TACS_CC_FLAGS = ${TACS_OPT_CC_FLAGS}
# Set the linking flags to use
TACS_EXTERN_LIBS = ${AMD_LIBS} ${METIS_LIB} ${LAPACK_LIBS}
TACS_LD_FLAGS = ${EXTRA_LD_FLAGS} ${TACS_LD_CMD} ${TACS_EXTERN_LIBS}
# This is the one rule that is used to compile all the
# source code in TACS
%.o: %.cpp
${CXX} ${TACS_CC_FLAGS} -c $< -o $*.o
#echo
#echo " --- Compiled $*.cpp successfully ---"
#echo
I can't answer but maybe I can orient you.
First nmake is not make. It will not work with any makefile not written specifically as an nmake makefile. And it's only available on Windows. So, best to just forget it exists.
Second, it's important to understand how make works: rules in makefiles are a combination of targets/prerequisites, and a recipe. The recipe is not in "makefile" syntax, it's a shell script (batch file). So make works in tandem with the shell, to run commands. Which shell? On POSIX systems like GNU/Linux and MacOS it's very simple: a POSIX shell; by default /bin/sh.
On Windows systems it's much less simple: there are a lot of options. It could be cmd.exe. It could be PowerShell. It could be a POSIX shell, that was installed by the user. Which one is chosen by default, depends on how your version of make was compiled. That's why you see different behaviors for different "ports" of make to Windows.
So, if you look at the makefiles you are trying to use you can see they are unquestionably written specifically for a POSIX system and expect a POSIX shell and a POSIX environment. Any attempt to use a version of make that invokes cmd.exe as its default shell will fail immediately with syntax errors ("" was unexpected at this time.).
OK, so you find a version of make that invokes a POSIX shell, and you don't get that error anymore.
But then you have to contend with another difference: directory separators. In Windows they use backslash. In POSIX systems, they use forward slash and backslash is an escape character (so it's not just passed through the shell untouched). If you are going to use paths in a POSIX shell, you need to make sure your paths use forward slashes else the shell will remove them as escape characters. Luckily, most Windows programs accept forward slashes as well as backslashes as directory separators (but not all: for example cmd.exe built-in tools do not).
Then you have to contend with the Windows abomination known as drive letters. This is highly problematic for make because to make, the : character is special in various places. So when make sees a line like C:/foo:C:/bar its parser will get confused, and you get errors. Some versions of make compiled for Windows enable a heuristic which tries to see if a path looks like a drive letter or not. Some just assume POSIX-style paths. They can also be a problem for the POSIX shell: many POSIX environments on Windows map drive letters to standard POSIX paths, so C:\foo is written as /c/foo or /mnt/c/foo or something else. If you are adding paths to your makefile you need to figure out what the right mapping, if any, is and use that.
That's not even to start discussing the other differences between POSIX and Windows... there are so many.
From what you've shown above, this project was not written with any sort of portability to Windows in mind. Given the complexity of this, that's not surprising: it takes a huge amount of work. So you have these options that I can see:
Port it yourself to be Windows-compatible
Try to get it working inside cygwin (cygwin is intended to be a POSIX-style environment that runs on Windows)
Try to get it working in WSL
Install a virtual machine using VMWare, VirtualBox, etc. running a Linux distribution and build and run it there
Unfortunately I don't know much about the pros and cons of these approaches so I can't advise you as to the best course.
The route I chose, long long ago, was to get rid of Windows entirely and just use GNU/Linux. But of course that won't be possible for everyone :).
You need a real answer: you can't compile using the Windows Command Prompt.
Get yourself MSYS2 -- which will also install MinGW-w64 -- and follow the setup instructions. Then launch the MSYS shell to get a unix-y terminal prompt (zsh, IIRC), and change directory to the head of the project folder.
To access the Windows filesystem the root directory will be either /c or /mnt/c (sorry, on my mobile ATM, I can improve this in a day or two). For example,
C:\Users\qa21944\git\tacs
becomes
/c/Users/qa21944/git/tacs
From there the GNU/Windows make command should work:
mingw32-make
There is also this post to use more modern *nix environments under Windows:
How to install and use "make" in Windows?
Thanks may be overkill for what you need, though.
When I finish traveling and can sit down to look at this properly I can improve this answer's details, but getting a Linux shell terminal is what you need.

Cannot make gnat-llvm : Ada.Strings.Text_Output" is not a predefined library unit

I do a make for gnat-llvm on ubuntu. (https://github.com/AdaCore/gnat-llvm)
I have ggc-9 installed, I tried also with gcc-10.
failure just at the beginning of the build:
make -C llvm-interface build gnatlib-automated
make[1] : on entre dans le répertoire « /home/gcalliet/sda3/gnat-llvm/llvm-interface »
mkdir -p obj obj-tools/libgnat bin gnat_src/vast
for f in `cd /home/gcalliet/sda3/gnat-llvm/llvm-interface/gnat_src; ls gen_il*.ad? xutil.ad? *-tmpl xoscons.adb xsnamest.adb`; \
do \
cp -p /home/gcalliet/sda3/gnat-llvm/llvm-interface/gnat_src/$f obj-tools; \
done
cd obj-tools && gnatmake -q -j0 xoscons xsnamest && ./xsnamest && \
mv -f snames.ns ../obj/snames.ads && mv -f snames.nb ../obj/snames.adb && \
gnatmake -g -q -j0 gen_il-main.adb -I../obj -Ilibgnat && ./gen_il-main && \
mv -f nmake.adb nmake.ads seinfo.ads sinfo-nodes.ads sinfo-nodes.adb einfo-entities.ads einfo-entities.adb
../obj
gen_il-main.adb:26:06: "Ada.Strings.Text_Output" is not a predefined library unit
gen_il-main.adb:26:06: "Gen_Il.Main (body)" depends on "Gen_Il (spec)"
gen_il-main.adb:26:06: "Gen_Il (spec)" depends on "Ada.Strings.Text_Output (spec)"
gnatmake: "gen_il-main.adb" compilation error`
What did I missed?
It seems that the current master branch of gnat-llvm cannot be build with the current master branch of gcc (gnat). Both are under heavy development and are apparently out-of-sync at the time of writing. You could try to build gnat-llvm using branch 21.2 (or some later commit between 21.2 and master) together with gcc branch releases/gcc-11 (although I have to admit that I didn't try it myself).
Note that gnat-llvm branch 21.2 still depends on LLVM 10. It seems that gnat-llvm switched to LLVM 11 in January (see this commit). You could also try to use this commit along with gcc branch releases/gcc-11 to build gnat-llvm if LLVM 10 is not available in your Linux distro.

Cross-compile wxGtk

I have to cross-compile wxGtk (an old version: 2.8.11) and managed to setup the environment so that configure runs successfully.
$ export CC=/opt/my_toolchain/toolchain_base/bin/i686-pc-linux-gnu-gcc
$ export CXX=/opt/my_toolchain/toolchain_base/bin/i686-pc-linux-gnu-g++
$ export CPPFLAGS=-I/opt/my_toolchain/additional_libs/usr/include/
$ export PKG_CONFIG_SYSROOT_DIR=/opt/my_toolchain/additional_libs/
$ export PKG_CONFIG_PATH=/opt/my_toolchain/additional_libs/usr/lib/pkgconfig
$ export PKG_CONFIG_DIR=/opt/my_toolchain/additional_libs/usr/lib/pkgconfig
$ export PKG_CONFIG_LIBDIR=/opt/my_toolchain/additional_libs/sysroot/usr/lib/
// LDFLAGS evtl falsch?? nicht ueberschreiben!?
$ export LDFLAGS="-L/opt/my_toolchain/additional_libs/lib/ -L/opt/my_toolchain/additional_libs/usr/lib/"
$ export CFLAGS="-Wl,-rpath-link=/opt/my_toolchain/additional_libs/lib/ -Wl,-rpath-link=/opt/my_toolchain/additional_libs/usr/lib/"
$ export CXXFLAGS="-Wl,-rpath-link=/opt/my_toolchain/additional_libs/lib/ -Wl,-rpath-link=/opt/my_toolchain/additional_libs/usr/lib/"
$ export LD_LIBRARY_PATH=/opt/my_toolchain/additional_libs/lib/:/opt/my_toolchain/additional_libs/usr/lib/:/opt/my_toolchain/additional_libs/usr/lib/:/opt/my_toolchain/additional_libs/lib/
$ pkg-config --define-variable=pc_path=/opt/my_toolchain/additional_libs/usr/lib/pkgconfig pkg-config
wxGTK-2.8.11 $ ./configure --enable-unicode --disable-shared --prefix=/usr/local/<targetname>
[...]
Configured wxWidgets 2.8.11 for `x86_64-unknown-linux-gnu'
Which GUI toolkit should wxWidgets use? GTK+ 2
Should wxWidgets be compiled into single library? no
Should wxWidgets be compiled in debug mode? no
Should wxWidgets be linked as a shared library? no
Should wxWidgets be compiled in Unicode mode? yes
What level of wxWidgets compatibility should be enabled?
wxWidgets 2.4 no
wxWidgets 2.6 yes
Which libraries should wxWidgets use?
jpeg sys
png sys
regex builtin
tiff sys
zlib sys
odbc no
expat sys
libmspack no
sdl no
However the subsequent make reports an error:
wxGTK-2.8.11 $ make
[...]
bk-make-pch ./.pch/wxprec_netlib/wx/wxprec.h.gch wx/wxprec.h /opt/my_toolchain/toolchain_base/bin/i686-pc-linux-gnu-g++ -I./.pch/wxprec_netlib -D__WXGTK__ -DWXBUILDING -I./src/regex -DwxUSE_GUI=0 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/mnt/cifs/osb_m/10_Competence_Centers/21_CC_IE/22_Kunden_Technik_Aktiv/Holmer/Software/Holmer_VT-Server/wxGTK-2.8.11/lib/wx/include/gtk2-unicode-release-static-2.8 -I./include -pthread -I/opt/my_toolchain/additional_libs//usr/include/gtk-2.0 -I/opt/my_toolchain/additional_libs//usr/lib/gtk-2.0/include -I/opt/my_toolchain/additional_libs//usr/include/pango-1.0 -I/opt/my_toolchain/additional_libs//usr/include/atk-1.0 -I/opt/my_toolchain/additional_libs//usr/include/cairo -I/opt/my_toolchain/additional_libs//usr/include/pixman-1 -I/opt/my_toolchain/additional_libs//usr/include/libpng16 -I/opt/my_toolchain/additional_libs//usr/include/gdk-pixbuf-2.0 -I/opt/my_toolchain/additional_libs//usr/include/libpng16 -I/opt/my_toolchain/additional_libs//usr/include/pango-1.0 -I/opt/my_toolchain/additional_libs//usr/include/harfbuzz -I/opt/my_toolchain/additional_libs//usr/include/pango-1.0 -I/opt/my_toolchain/additional_libs//usr/include/freetype2 -I/opt/my_toolchain/additional_libs//usr/include/glib-2.0 -I/opt/my_toolchain/additional_libs//usr/lib/glib-2.0/include -I/opt/my_toolchain/additional_libs/usr/include/ -DWX_PRECOMP -pthread -Wall -Wundef -Wno-ctor-dtor-privacy -O2 -fno-strict-aliasing -Wl,-rpath-link=/opt/my_toolchain/additional_libs/lib/ -Wl,-rpath-link=/opt/my_toolchain/additional_libs/usr/lib/
In file included from /opt/my_toolchain/additional_libs/usr/include/math.h:46:0,
from ./include/wx/math.h:19,
from ./include/wx/wx.h:30,
from ./include/wx/wxprec.h:68:
/opt/my_toolchain/additional_libs/usr/include/bits/mathdef.h:47:6: warning: "__FP_FAST_FMA" is not defined [-Wundef]
/opt/my_toolchain/additional_libs/usr/include/bits/mathdef.h:51:6: warning: "__FP_FAST_FMAF" is not defined [-Wundef]
/opt/my_toolchain/additional_libs/usr/include/bits/mathdef.h:55:6: warning: "__FP_FAST_FMAL" is not defined [-Wundef]
/opt/my_toolchain/toolchain_base/bin/../i686-pc-linux-gnu/libc/usr/lib/crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
collect2: error: ld returned 1 exit status
Makefile:12022: recipe for target '.pch/wxprec_netlib/wx/wxprec.h.gch' failed
make: *** [.pch/wxprec_netlib/wx/wxprec.h.gch] Error 1
I've printed the compiler command which reports the issue:
/opt/my_toolchain/toolchain_base/bin/i686-pc-linux-gnu-g++ \
-I./.pch/wxprec_baselib -D__WXGTK__ -DWXBUILDING \
-I./src/regex \
-DwxUSE_GUI=0 -DwxUSE_BASE=1 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES \
-I/path/to/wxGTK-2.8.11/lib/wx/include/gtk2-unicode-release-static-2.8 \
-I./include \
-pthread \
-I/opt/my_toolchain/additional_libs//usr/include/gtk-2.0 \
-I/opt/my_toolchain/additional_libs//usr/lib/gtk-2.0/include \
-I/opt/my_toolchain/additional_libs//usr/include/pango-1.0 \
-I/opt/my_toolchain/additional_libs//usr/include/atk-1.0 \
-I/opt/my_toolchain/additional_libs//usr/include/cairo \
-I/opt/my_toolchain/additional_libs//usr/include/pixman-1 \
-I/opt/my_toolchain/additional_libs//usr/include/libpng16 \
-I/opt/my_toolchain/additional_libs//usr/include/gdk-pixbuf-2.0 \
-I/opt/my_toolchain/additional_libs//usr/include/libpng16 \
-I/opt/my_toolchain/additional_libs//usr/include/pango-1.0 \
-I/opt/my_toolchain/additional_libs//usr/include/harfbuzz \
-I/opt/my_toolchain/additional_libs//usr/include/pango-1.0 \
-I/opt/my_toolchain/additional_libs//usr/include/freetype2 \
-I/opt/my_toolchain/additional_libs//usr/include/glib-2.0 \
-I/opt/my_toolchain/additional_libs//usr/lib/glib-2.0/include \
-I/opt/my_toolchain/additional_libs/usr/include/ \
-DWX_PRECOMP -pthread -Wall -Wundef -Wno-ctor-dtor-privacy -O2 -fno-strict-aliasing \
-Wl,-rpath-link=/opt/my_toolchain/additional_libs/lib/ \
-Wl,-rpath-link=/opt/my_toolchain/additional_libs/usr/lib/ \
-o ./.pch/wxprec_baselib/wx/wxprec.h.gch \
-MMD -MF \
./.deps/___pch_wxprec_baselib_wx_wxprec_h_gch.d \
./include/wx/wxprec.h
If I remove the two the -Wl,-rpath-link= statements from this compiler command and invoke it manually, the command succeeds.
It seems the additional -Wl statements make the compiler miss the source file with the main()-function (which seems to be provided via ./include/wx/wxprec.h), but I don't really see how that could happen.
I'd be grateful about any advice how I can address this problem.
Update
The configure-Script has the usual options (no --source)
--build=BUILD configure for building on BUILD [guessed]
--host=HOST cross-compile to build programs to run on HOST [BUILD]
--target=TARGET configure for building compilers for TARGET [HOST]
where --target is of no interest. The other options I'll have to check. As I mentioned in the comments, I've so far only seen them being used with prefixes e.g. aarch64-linux-gnu for toolchains from package repositories which are in the $PATH, and with according libraries etc.
So I've added the folder for toolchain binaries to path and configured with
./configure --enable-unicode --disable-shared --prefix=/usr/local/<target> --host=i686-pc-linux-gnu
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
checking build system type... x86_64-unknown-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
That looks correct. I want to build on my local machine for another target.
But:
checking for GTK+ - version >= 2.0.0... no
*** Could not run GTK+ test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means GTK+ is incorrectly installed.
configure: error:
The development files for GTK+ were not found. For GTK+ 2, please
ensure that pkg-config is in the path and that gtk+-2.0.pc is
installed. For GTK+ 1.2 please check that gtk-config is in the path,
and that the version is 1.2.3 or above. Also check that the
libraries returned by 'pkg-config gtk+-2.0 --libs' or 'gtk-config
--libs' are in the LD_LIBRARY_PATH or equivalent.
Unfortunately that makes sense. The toolchain itself only has some libraries, but does not have the GTK-libraries.
/opt/my_toolchain/toolchain_base/
The GTK libraries and other libraries are in a separate folder:
/opt/my_toolchain/additional_libs/
And the toolchain's binaries don't know about this folder.
I think the whole issue arises because wxGtk builds libraries for the host = i686-pc-linux-gnu, but also builds executables (e.g. wx-config) for the build-system = x86_64-unknown-linux-gnu.
The wxGtk 2.8.11 cross-build is finally working with the following setup:
export PATH=/opt/my_toolchain/toolchain_base/bin/:${PATH}
export PKG_CONFIG_SYSROOT_DIR=/opt/my_toolchain/additional_libs
export PKG_CONFIG_PATH=/opt/my_toolchain/additional_libs/usr/lib/pkgconfig
export PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1
# make sure those env vars are not left from previous setup
unset CC
unset CXX
unset CPPFLAGS
unset CFLAGS
unset CXXFLAGS
unset LD_LIBRARY_PATH
unset LDFLAGS
unset PKG_CONFIG_DIR
unset PKG_CONFIG_LIBDIR
./configure --enable-unicode --disable-shared --prefix=/usr/local/<target> --host=i686-pc-linux-gnu --build=x86_64-linux-gnu
make
sudo make install

Travis-CI Complex Makefile fails

I am new to using Travis-CI, and the C++ project that I am starting with uses a GNU Makefile, The makefile contains many functions, one of which calls other functions. I noticed that in the Travis-CI log, this function does not successfully call the other functions, instead, it leaves a blank space, which causes the build to fail. Despite it working on any computer.
The function is:
define Compile
mkdir -p $(#D)
if [[ $(2) == Linking ]]; then \
$(call Print,$(2) $(#F),$(WIDTH)); \
else \
$(call PrintCpp,$(2) $(#F),$(WIDTH)); \
fi
$(1) 2> $#.log; \
RESULT=$$?; \
if [ $$RESULT -ne 0 ]; then \
$(cross); \
else \
$(check); \
fi; \
cat $#.log; \
rm -f $#.log
endef
The functions called are:
define Line =
$(shell printf '%0.1s' "$(2)"{1..$(1)})
endef
define Print
var="$(1)"; \
width="$(2)";\
printf '%s%*.*s' "$$var" 0 $$(($$width - $${#var} - 1)) "$(call
Line,$(2),.)"
endef
define PrintCpp
var="$(1)"; \
var=$${var%.*}.cpp; \
width="$(2)";\
printf '%s%*.*s' "$$var" 0 $$(($$width - $${#var} - 1)) "$(call
Line,$(2),.)"
endef
define check =
printf "%b\n" "$(OK_COLOR)\xE2\x9C\x94 $(NO_COLOR)"
endef
define cross =
printf "%b\n" "$(ERR_COLOR)\xE2\x9D\x8C $(NO_COLOR)"
endef
The GitHub for the project can be found here:
https://github.com/LuxAtrumStudio/Pessum
And the Travis-CI log here:
https://travis-ci.org/LuxAtrumStudio/Pessum/builds/256427744
I had a very similar problem, which turned out to be because Travis by default still uses the deprecated Ubuntu Trusty release. Trusty only has GNU Make version 3, while we require GNU Make > 4.
My problem was fixed when I switched Travis to Ubuntu Xenial by adding the following to my .travis.yml:
dist: xenial
Before the switch from Trusty to Xenial, make -v was at GNU Make 3.81. After the switch, make -v is now at GNU Make 4.1
Switching to Xenial might require you to make some additional changes. I had to bump my Python version from 3.4 to 3.7, for example.

Can I build gcc for ARM with an X64 one?

I need a definitive answer because this is still unclear to me and I can't find an explicit answer anywhere in the docs.
Assuming that I have a working gcc toolchain where
host x86_64-linux-gnu
target x86_64-linux-gnu
, the question is can I possibly configure and build gcc from sources with ?
host x86_64-linux-gnu
build x86_64-linux-gnu
target arm-gnu-eabi
The reason why I would like an answer on this is about whether or not I should spend time trying different configurations for my libraries and whether or whether or not the scripts used to build gcc are capable of some implicit stage 1 build that can potentially bootstrap an ARM compiler for me temporarily on this x64, so I can generate the toolchain that I need for the target that I want .
"Can I build gcc for ARM with an X64 one?"
Yes, you can. I have described this process for a suse linux host development system in a blog post of mine.
==================================================================================
I'm going to replicate the steps here:
1. Ensure to have the necessary headers & libraries installed
I have used YAST's 'Install Software' feature, to install the following packages that will be necessary to complete all the build steps (just search for the package names, select and accept):
gmp-devel
mpfr-devel
mpc-devel
texinfo
ncurses-devel
termcap
2. Create a directory skeleton
cd ~
mkdir arm-none-eabi arm-none-eabi-src
cd arm-none-eabi
mkdir src build
cd ~/arm-none-eabi-src
mkdir src build
3. Download the the source packages and extract them
I'm using gcc-4.7.1 here, but the same process will of course apply for newer versions of GCC.
cd ~/arm-none-eabi-src/src
wget ftp://ftp.gnu.org/gnu/gcc/gcc-4.7.1/gcc-4.7.1.tar.bz2
wget ftp://ftp.gnu.org/gnu/binutils/binutils-2.22.tar.bz2
wget ftp://ftp.gnu.org/gnu/gdb/gdb-7.4.tar.bz2
wget ftp://sources.redhat.com/pub/newlib/newlib-1.20.0.tar.gz
tar -xf gcc-4.7.1.tar.bz2
tar -xf binutils-2.22.tar.bz2
tar -xf gdb-7.4.tar.bz2
tar -xf newlib-1.20.0.tar.gz
4. Build the binutils
cd ~/arm-none-eabi-src/build
mkdir binutils-2.22
cd binutils-2.22
../../src/binutils-2.22/configure \
--target=arm-none-eabi \
--prefix=$HOME/arm-none-eabi \
--with-cpu=cortex-m3 \
--with-no-thumb-interwork \
--with-mode=thumb
make all install
export PATH="$PATH:$HOME/arm-none-eabi/bin"
5. Build GCC (Part1)
cd ~/arm-none-eabi-src/build
mkdir gcc-4.7.1
cd gcc-4.7.1
../../src/gcc-4.7.1/configure --target=arm-none-eabi \
--prefix=$HOME/arm-none-eabi --with-cpu=cortex-m3 \
--with-mode=thumb --disable-multilib \
--with-no-thumb-interwork \
--enable-languages="c,c++" --with-newlib \
--with-headers=../../src/newlib-1.20.0/newlib/libc/include
make all-gcc install-gcc
The --enable-cxx-flags configure option might be additionally used to control the build flags of the libstdc++ (included in this step):
--enable-cxx-flags='-fno-exceptions \
-ffunction-sections -fno-omit-frame-pointer'
In general the same C++ compile flags should be used as they'll appear when building the intended target code.
6. Build GCC newlib with the cross compiler (Part2)
cd ~/arm-none-eabi-src/build
mkdir newlib-1.20.0
cd newlib-1.20.0
../../src/newlib-1.20.0/configure --target=arm-none-eabi \
--prefix=$HOME/arm-none-eabi --disable-multilib \
--disable-newlib-supplied-syscalls
make all install
A note about the --disable-newlib-supplied-syscalls option:
Disabling the default newlib syscall stub implementation is generally a good idea when you intend to compile for targets without using a linux like operating system, or no OS at all. It will leave you with linker errors on unimplemented stub functions you'll need to provide for newlib.
Removing the option will still enable you to override the newlib provided stubs with your own implementations.
Though, when you plan to use the cross-toolchain in conjunction with CMake, you should omit this option. CMake does some basic tests using the specified compiler definitions (e.g. from a toolchain.cmake file), that'll fail without the default stub implementations supplied.
7. Complete installing GCC
cd ~/arm-none-eabi-src/build/gcc-4.7.1
make all install
8. Build GDB
cd ~/arm-none-eabi-src/build
mkdir gdb-7.4
cd gdb-7.4
../../src/gdb-7.4/configure --target=arm-none-eabi \
--prefix=$HOME/arm-none-eabi
make all install
UPDATE
The same works pretty well for GCC 4.8.2 also.