Blockquote
Hello, I am trying to compile the latest source of The Powder Toy but my compiler (G++ with scons) is crashing every time it hits a command with --m in it.
Crash log:
scons --lin --release --sse2
scons: Reading SConscript files ...
Checking for C library fftw3f... (cached) yes
Checking for C library bz2... (cached) yes
Checking for C library z... (cached) yes
Checking for C header file bzlib.h... (cached) yes
Checking for C library lua... (cached) no
Checking for C library lua5.1... (cached) yes
scons: done reading SConscript files.
scons: Building targets ...
^[[Ag++ -o build/src/Format.o -c -w -std=c++98 -fkeep-inline-functions -sse2 -O3 -ftree-vectorize -funsafe-math-optimizations -ffast-math -fomit-frame-pointer -funsafe-loop-optimizations -Wunsafe-loop-optimizations -D_GNU_SOURCE=1 -D_REENTRANT -DLUACONSOLE -DGRAVFFT -D_GNU_SOURCE -DUSE_STDINT -D_POSIX_C_SOURCE=200112L -DUSE_SDL -DLIN -DX86 -DX86_SSE2 -I/usr/include/SDL -I/usr/include/lua5.1 -Ibuild/src -Ibuild/data -Ibuild/generated build/src/Format.cpp
g++: error: unrecognized option â-msse2â
scons: *** [build/src/Format.o] Error 1
scons: building terminated because of errors.
Why would this be happening? I've had to delete the -m32 command also to get it to compile.
I strongly suspect that it's because the -sse2 option is telling g++ to generate SSE2, which are SIMD instructions for Intel's x86 architecture. The Raspberry Pi board is a completely different computer architecture (ARM) and does not support SSE2. The ARM equivalent of SSE2 is NEON, but NEON is available for the ARM used in RPi.
I think that for options that g++ doesn't recognize, it tries prefixing with another flag (in this case -m, but I've seen -f before) to see if it's a synonym.
In your case sse2 makes no sense on the Raspberry Pi, and for the above example, is the problem.
What is ^[[A ? Do you have unprintable chars in your makefile? Can you echo all parameters one by one to identify which contains these strange characters?
Related
I have been trying to understand what is going wrong in executing a cross-built eclipse file for Beaglebone black, which takes the ADC values, converts the read value and outputs the converted temperature values (uses 'log' function, so math lib 'm' was also added to the cross-linker settings to the project) onto the terminal screen.
I can successfully compile and build the eclipse file and transfer it to the Beaglebone black, but when i try to execute (the file name is thermADC), i get the following error:
debian#beaglebone:~$ ./thermADC
./thermADC: /lib/arm-linux-gnueabihf/libm.so.6: version `GLIBC_2.29' not found (required by ./thermADC)
I tried searching up the error on the web, and found similar issues faced by others, but none of the answers or approaches helped solve the issue (or didn't have a solution at all in the first place).
Since the error pointed out to a GLIBC version 2.29 not found, i checked the glibc version on my BBB and the result:
debian#beaglebone:~$ ldd --version ldd
ldd (Debian GLIBC 2.28-10+deb10u1) 2.28
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
The above shows that the GLIBC currently available on the BBB is of version 2.28 and not '2.29' as required which would explain the error.
Then i searched for how to upgrade or install glibc with version 2.29 and came across this blogpost and tried as instructed as follows:
Downloaded the glibc-2.29 package tar from gnu.org ( sudo wget http://ftp.gnu.org/gnu/glibc/glibc-2.29.tar.gz ) into /usr/local/.
Unzipped the package to a glibc-2.29 folder.
Executed the ./configure command -- ( sudo ./glibc-2.29/configure --prefix=/usr --disable-profile --enable-add-ons --with-headers=/usr/include --with-binutils=/usr/bin ) and the result is as follows:
checking build system type... armv7l-unknown-linux-gnueabihf
checking host system type... armv7l-unknown-linux-gnueabihf
checking for gcc... gcc
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for readelf... readelf
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking whether g++ can link programs... yes
checking for sysdeps preconfigure fragments... aarch64 alpha arm configure: Found compiler is configured for armv7
csky hppa i386 m68k microblaze mips nios2 powerpc riscv s390 sh sparc x86_64
checking for use of fpu sysdeps directories... yes
checking for -fstack-protector... yes
checking for -fstack-protector-strong... yes
checking for -fstack-protector-all... yes
checking for assembler and linker STT_GNU_IFUNC support... yes
checking for gcc attribute ifunc support... yes
checking whether the linker supports textrels along with ifunc... yes
checking if compiler warns about alias for function with incompatible types... yes
checking sysdep dirs... sysdeps/unix/sysv/linux/arm sysdeps/arm/nptl sysdeps/unix/sysv/linux sysdeps/nptl sysdeps/pthread sysdeps/gnu sysdeps/unix/inet sysdeps/unix/sysv sysdeps/unix/arm sysdeps/unix sysdeps/posix sysdeps/arm/armv7/multiarch sysdeps/arm/armv7 sysdeps/arm/armv6t2 sysdeps/arm/armv6 sysdeps/arm sysdeps/wordsize-32 sysdeps/ieee754/flt-32 sysdeps/ieee754/dbl-64 sysdeps/ieee754 sysdeps/generic
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether /usr/bin/as is GNU as... yes
checking whether /usr/bin/ld is GNU ld... yes
checking for /usr/bin/as... /usr/bin/as
checking version of /usr/bin/as... 2.31.1, ok
checking for /usr/bin/ld... /usr/bin/ld
checking version of /usr/bin/ld... 2.31.1, ok
checking for gnumake... no
checking for gmake... no
checking for make... make
checking version of make... 4.2.1, ok
checking for gnumsgfmt... no
checking for gmsgfmt... no
checking for msgfmt... msgfmt
checking version of msgfmt... 0.19.8.1, ok
checking for makeinfo... makeinfo
checking version of makeinfo... 6.5, ok
checking for sed... sed
checking version of sed... 4.7, ok
checking for gawk... gawk
checking version of gawk... 4.2.1, ok
checking for bison... bison
checking version of bison... 3.3.2, ok
checking if gcc -B/usr/bin/ is sufficient to build libc... yes
checking for nm... nm
checking for python3... python3
checking version of python3... 3.7.3, ok
checking LD_LIBRARY_PATH variable... ok
checking for bash... /bin/bash
checking for perl... /usr/bin/perl
checking for install-info... no
checking for .set assembler directive... yes
checking linker support for protected data symbol... yes
checking linker support for INSERT in linker script... yes
checking for broken __attribute__((alias()))... no
checking whether to put _rtld_local into .sdata section... no
checking whether to use .ctors/.dtors header and trailer... no
checking for libunwind-support in compiler... no
checking whether --noexecstack is desirable for .S files... yes
checking for -z combreloc... yes
checking for linker that supports -z execstack... yes
checking for linker that supports --no-dynamic-linker... yes
checking for -static-pie... yes
checking for -fpie... yes
checking for --hash-style option... yes
checking for sufficient default -shared layout... no
checking for GLOB_DAT reloc... yes
checking linker output format... elf32-littlearm
checking for -fno-toplevel-reorder -fno-section-anchors... yes
checking for -mtls-dialect=gnu2... yes
checking whether cc puts quotes around section names... no
checking for __builtin_memset... no
checking for redirection of built-in functions... yes
checking for compiler option to disable generation of FMA instructions... -ffp-contract=off
checking if gcc -B/usr/bin/ accepts -fno-tree-loop-distribute-patterns with __attribute__ ((__optimize__))... yes
checking for libgd... no
checking for is_selinux_enabled in -lselinux... no
checking for _FORTIFY_SOURCE predefine... no
checking whether the linker provides working __ehdr_start... yes
checking for __builtin_trap with no external dependencies... yes
checking whether the C++ compiler supports thread_local... yes
running configure fragment for sysdeps/unix/sysv/linux
checking installed Linux kernel header files... 3.2.0 or later
checking for kernel header at least 3.2.0... ok
checking for symlinks in /usr/include... ok
running configure fragment for sysdeps/gnu
running configure fragment for sysdeps/arm
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking whether the compiler is using the ARM hard-float ABI... yes
checking whether PC-relative relocs in movw/movt work properly... yes
checking whether TPOFF relocs with addends are assembled correctly... yes
checking whether -fPIC is default... yes
checking whether -fPIE is default... yes
configure: creating ./config.status
config.status: creating config.make
config.status: creating Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing default commands
which makes me believe that the configure step is done without any errors (there were few warnings of some of the packages not being installed on the system in a previous try to configure, so installed those said packages on BBB before performing a clean build).
4. Next step is to execute the "make" command in the /usr/local/ directory and this is where i am facing the issue as follows:
../sysdeps/unix/sysv/linux/sys/syscall.h:24:10: **fatal error:** asm/unistd.h: No such file or directory
#include <asm/unistd.h>
^~~~~~~~~~~~~~
compilation terminated.
Traceback (most recent call last):
File "../scripts/gen-as-const.py", line 120, in <module>
main()
File "../scripts/gen-as-const.py", line 116, in main
consts = glibcextract.compute_c_consts(sym_data, args.cc)
File "/usr/local/glibc-2.29/scripts/glibcextract.py", line 62, in compute_c_consts
subprocess.check_call(cmd, shell=True)
File "/usr/lib/python3.7/subprocess.py", line 347, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command 'gcc -B/usr/bin/ -std=gnu11 -fgnu89-inline -g -O2 -Wall -Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math -fno-stack-protector -Wstrict-prototypes -Wold-style-definition -fmath-errno -ftls-model=initial-exec -I../include -I/usr/local/csu -I/usr/local/include -I/usr/local -I../sysdeps/unix/sysv/linux/arm -I../sysdeps/arm/nptl -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/arm -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/arm/armv7/multiarch -I../sysdeps/arm/armv7 -I../sysdeps/arm/armv6t2 -I../sysdeps/arm/armv6 -I../sysdeps/arm/include -I../sysdeps/arm -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabihf/8/include -isystem /usr/lib/gcc/arm-linux-gnueabihf/8/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include /usr/local/libc-modules.h -DMODULE_NAME=libc -include ../include/libc-symbols.h -DTOP_NAMESPACE=glibc -DGEN_AS_CONST_HEADERS -MD -MP -MF /usr/local/rtld-global-offsets.h.dT -MT '/usr/local/rtld-global-offsets.h.d /usr/local/rtld-global-offsets.h' -S -o /tmp/tmpqm_0ze7l/test.s -x c - < /tmp/tmpqm_0ze7l/test.c' returned non-zero exit status 1.
make[2]: *** [../Makerules:271: /usr/local/rtld-global-offsets.h] Error 1
make[2]: Leaving directory '/usr/local/glibc-2.29/csu'
make[1]: *** [Makefile:258: csu/subdir_lib] Error 2
make[1]: Leaving directory '/usr/local/glibc-2.29'
make: *** [Makefile:9: all] Error 2
Can someone please help with what might be causing this issue?
Thanks and Regards,
Yash
I figured out the issue with the help of the beaglebone forum, and it is mainly caused by the mismatch of the versions of GLIBC (or any other lib for that matter) between the host and target.
This particular was solved by using the latest Debian Bullseye (GLIBC_2.31) distro instead of the Debian Buster (GLIBC_2.28) distro or the alternate was to use a host machine with GLIBC higher than the target GLIBC version.
For a better understanding of the problem, the link to the solution is: https://forum.beagleboard.org/t/lib-arm-linux-gnueabihf-libm-so-6-version-glibc-2-29-not-found-required-by-thermadc/32341
If I run
../configure CC=icc CXX=icpc F77=ifort FC=ifort
the configuring stops with
============================================================================
== Compiler and preprocessor tests
============================================================================
*** C compiler and preprocessor
checking for gcc... (cached) icc
checking whether we are using the GNU C compiler... (cached) yes
checking whether icc accepts -g... (cached) yes
checking for icc option to accept ISO C89... (cached) none needed
checking whether icc understands -c and -o together... (cached) yes
checking for icc option to accept ISO C99... unsupported
configure: WARNING: Open MPI requires a C99 compiler
configure: error: Aborting.
I'm trying to build Open MPI 3.0.0 from source. I'm using the Intel compilers version 18.0.0 20170811. The environment is Arch Linux.
Why is Open MPI having a problem with icc not being C99 compliant?
There seems to be a problem with the latest ICC if used in combination with glibc 2.26. The problem is still present with version 18.0.0. For now, the fix is to include the flag -D_Float128=__float128:
../configure CC=icc CXX=icpc FC=ifort CFLAGS="-D_Float128=__float128"
If you don't need to use the classic C++ you can choose to compile with C99
../configure C99=icc CXX=icpc FC=ifort
I'm trying to cross-compile libcurl (version 7.54.0) for arm-linux-gnueabihf, I have the toolkit installed in my $PATH. I'm running the command to configure libcurl:
./configure --enable-static --disable-shared --prefix=/usr/arm-linux-gnueabihf --host=arm-linux-gnueabi --build=i686-pc-linux-gnu CC=arm-linux-gnueabihf-gcc
It starts configuring but then outputs: checking if sig_atomic_t is
already defined as volatile... yes checking return type of signal
handlers... void checking for sys/select.h... (cached) yes checking
for sys/socket.h... (cached) yes checking for select... no checking
for sys/types.h... (cached) yes checking for sys/socket.h... (cached)
yes checking for recv... no configure: error: Unable to link function
recv
I believe it may have something to do with the shared libraries, I installed arm-linux-gnueabihf-gcc via sudo apt-get install arm-linux-gnueabihf-gcc
The function recv is the first to be check in terms of execution and linking by autotools. The standard flags for the test comprehend also -lz , which is the flag to link the zlib ( see the file config.log below ) :
configure:21072: arm-linux-gnueabihf-gcc-4.9 -o conftest -O2 -Wno-error -Werror-implicit-function-declaration -Wno-system-headers -O2 -Wno-error conftest.c -lbrotlidec -lz >&5
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lbrotlidec
/lib/../lib/libz.so: file not recognized: File format not recognized
If you are cross compiling, the system location - generally /lib/libz.so - is not good. Please ensure to place the correct location of zlib using --with-zlib .
[
i used, sudo ./configure ....
to pass the error point - Unable to link function recv
and need to use, sudo make
] ==> sorry , this sould be wrong answer.
you shud
export CPPFLAGS="-I...../include" ==> this is refer to ur target tool chain's include path.
refer to https://curl.haxx.se/docs/install.html
I'm trying to install R3.1.1 from sources on CentOS 6.5.
The .configure raises the following error
(...)
checking whether we can compute C Make dependencies... yes, using $(CC) -MM
checking whether gcc -std=gnu99 supports -c -o FILE.lo... yes
checking for gcc -std=gnu99 option to support OpenMP... -fopenmp
checking how to get verbose linking output from gfortran... -v
checking for Fortran 77 libraries of gfortran... -L/usr/local/lib64 -L/cm/shared/apps/slurm/14.03.0/lib64/../lib64 -L/cm/shared/apps/gcc/4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2 -L/cm/shared/apps/gcc/4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/cm/shared/apps/slurm/14.03.0/lib64/slurm -L/cm/shared/apps/slurm/14.03.0/lib64 -L/cm/shared/apps/gcc/4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../.. -lgfortran -lm -lquadmath
checking how to get verbose linking output from gcc -std=gnu99... -v
checking for C libraries of gcc -std=gnu99... -L/usr/local/lib64 -L/cm/shared/apps/slurm/14.03.0/lib64/../lib64 -L/cm/shared/apps/gcc/4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2 -L/cm/shared/apps/gcc/4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/cm/shared/apps/slurm/14.03.0/lib64/slurm -L/cm/shared/apps/slurm/14.03.0/lib64 -L/cm/shared/apps/gcc/4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../.. -lgcc_s
checking for dummy main to link with Fortran 77 libraries... none
checking for Fortran 77 name-mangling scheme... lower case, underscore, no extra underscore
checking whether gfortran appends underscores to external names... yes
checking whether gfortran appends extra underscores to external names... no
checking whether mixed C/Fortran code can be run... configure: WARNING: cannot run mixed C/Fortran code
configure: error: Maybe check LDFLAGS for paths to Fortran libraries?
gfortran was installed using yum
gfortran --version
GNU Fortran (GCC) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
I've no idea what I should put in LDFLAGS to fix that error.
UDPATE:
# find / -name "libgfor*.so"
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgfortran.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgfortran.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgfortran.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgfortran.so
/cm/shared/apps/gcc/4.8.2/lib64/libgfortran.so
/cm/shared/apps/gcc/4.8.2/lib/libgfortran.so
/cm/images/default-image/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgfortran.so
/cm/images/default-image/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgfortran.so
.
# tail config.log
#define SIZEOF_LONG_LONG 8
#define SIZEOF_DOUBLE 8
#define SIZEOF_SIZE_T 8
#define HAVE_LONG_DOUBLE 1
#define SIZEOF_LONG_DOUBLE 16
#define F77_FUNC(name,NAME) name ## _
#define F77_FUNC_(name,NAME) name ## _
#define HAVE_F77_UNDERSCORE 1
configure: exit 1
Try to locate libgfortran.so in your system and provide the path -Lthe_path -lgfortran or set the respective environment variables. If that does not help, try to find more details in the config.log (or similar) file to find out what does the configure actually try to do in that check.
Your gfortran reports it is version 4.8.2 but the libraries are from version 4.4.4. Try to locate (by which) which gfortran binary you run and where are its libraries. Try running the locate command for libgfortran.
I have installed this driver for long time, but failed. There is the same mistake as following:
scons: Reading SConscript files ...
Checking for C++ library boost_thread-mt... (cached) no
Checking for C++ library boost_thread... (cached) yes
Checking for C++ library boost_filesystem-mt... (cached) no
Checking for C++ library boost_filesystem... (cached) yes
Checking for C++ library boost_system-mt... (cached) no
Checking for C++ library boost_system... (cached) yes
scons: done reading SConscript files.
scons: Building targets ...
g++ -o build/mongo/client/dbclient_rs.o -c -O3 -pthread -D_SCONS -DMONGO_EXPOSE_MACROS -Ibuild -Isrc -Ibuild/mongo -Isrc/mongo src/mongo/client/dbclient_rs.cpp
In file included from /usr/local/include/boost/filesystem/path.hpp:24,
from src/mongo/util/paths.h:26,
from src/mongo/db/client.h:38,
from src/mongo/db/curop.h:23,
from src/mongo/db/curop-inl.h:1,
from src/mongo/db/instance.h:23,
from src/mongo/db/dbmessage.h:25,
from src/mongo/client/dbclient_rs.cpp:27:
/usr/local/include/boost/filesystem/config.hpp:16:5: error: #error Compiling Filesystem version 3 file with BOOST_FILESYSTEM_VERSION defined != 3
scons: *** [build/mongo/client/dbclient_rs.o] Error 1
scons: building terminated because of erro`enter code here`rs.`enter code here`
before install, I have installed the boost 1.5， pcre8.3, and I want install mongodb driver 2.2
Any ideas ? Thanks!
I encountered the same problem with you.
In mongodb C++ driver source src/mongo/pch.h
#define BOOST_FILESYSTEM_VERSION 2
but in /usr/local/include/boost/filesystem/config.hpp:
# if defined(BOOST_FILESYSTEM_VERSION) && BOOST_FILESYSTEM_VERSION != 3
# error Compiling Filesystem version 3 file with BOOST_FILESYSTEM_VERSION defined != 3
# endif
this is the problem.
And I change src/mongo/pch.h to
#define BOOST_FILESYSTEM_VERSION 3
then scons again, the compiles correctly.
Some solution from Internet :
RESOLVED: I have v2 of the 1.44 boost libraries, but had "#define BOOST_FILESYSTEM_VERSION 3" in my header (a co-worker using another version had added it). If I comment this directive, my code compiles correctly. Looks like we need to synchronize our libraries.