R configure error that C99 double complex is required - c

I am trying to update R to version 3.5.3 on my Centos 7 server with a GCC compiler of version 8.2.0. But when I tried to configure in the home directory of R-3.5.3, it was stuck with the following error:
checking complex.h usability... no
checking complex.h presence... no
checking for complex.h... no
checking whether C99 double complex is supported... no
configure: error: Support for C99 double complex type is required.
The version information of my GCC compiler is as follows:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-libmpx --with-system-zlib
Thread model: posix
gcc version 8.2.0 (GCC)
Could anyone help me to get rid of such a problem?
Thanks!
EDIT:
After I checked the discussion, I thought the complex.h might be included wrongly and then I double checked in the config.h. But it turned out to be the included complex.h was the new header for gcc 8.2.0 as follows:
configure:38022: checking complex.h usability
configure:38022: gcc -c -g -O2 -I/usr/local/include/c++/8.2.0/ conftest.c >&5
Below them, there was another error which was:
/usr/local/include/c++/8.2.0/complex.h:29:10: fatal error: bits/c++config.h: No such file or directory
I tried again to configure with options --includedir and CXXFLAGS but both didn't work.

I found the same issue and fixed it by add gcc-9.3.0_install/include/c++/9.3.0/x86_64-pc-linux-gnu/ into include path.
when only gcc-9.3.0_install/include/c++/9.3.0/ was added into the include path, the <bits/c++config.h> could not be found and lead to this error !
Lidong

Related

Questions about "gcc: unrecognized option `-rdynamic'"

I use gcc on Solaris 10 to build make program, and get the following information:
gcc: unrecognized option `-rdynamic'
After checking the rdynamic in gcc document, I get the following explantions:
-rdynamic
Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of dlopen or to allow obtaining backtraces from within a program.
My questions are:
(1) Although gcc prints "gcc: unrecognized option -rdynamic", the build is still success. Is this the default behavior of gcc?
(2) I replace "-rdynamic" with "-export-dynamic" in Makefile, and the build is success. Is there any side-effect of this substitution?
P.S. My gcc information:
bash-3.00# gcc -v
Reading specs from /usr/local/lib/gcc/i386-pc-solaris2.10/3.4.6/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.6
You are using an obsolete version of gcc, but you refer to an up-to-date documentation. There is no such linker option for gcc-3.4.6, see https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Link-Options.html.
Try using -Wl,--export-dynamic option when linking instead.
I replace -rdynamic with -export-dynamic in Makefile, and the build is success. Is there any side-effect of this substitution.
This option is not documented, it may well do nothing, you need to check strace output what command line options it passes to the linker.

gcc creates a different folder base on its version

When I try to rpmbuild something I got this error message
checking for x86_64-redhat-linux-gcc... no
checking for gcc... no
checking for x86_64-redhat-linux-cc... no
checking for cc... no
checking for x86_64-redhat-linux-cl.exe... no
checking for cl.exe... no
And I found out that, the tool are in /usr/bin/gcc48 what I did is link the gcc48 to gcc folder: Which I got the idea from this link https://stackoverflow.com/a/13327320/612920
ln /usr/bin/gcc48 /usr/bin/gcc
And when I tried to run rpmbuild again I got this error message:
checking for x86_64-redhat-linux-gcc... no
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/usr/src/rpm/BUILD/courier-unicode-1.1':
configure: error: C compiler cannot create executables
See `config.log' for more details
error: Bad exit status from /var/tmp/rpm-tmp.jrbnrw (%prep)
What is wrong? I had already installed all development tools and its on its latest versions. Can Somebody help me?
And by the way I am using Amazons Redhat (gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC))
UPDATED:
config.log
configure:3499: $? = 0
configure:3488: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-amazon-linux/4.8.2/lto-wrapper
Target: x86_64-amazon-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugu$
Thread model: posix
gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
configure:3499: $? = 0
configure:3488: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3499: $? = 4
configure:3488: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'
gcc: fatal error: no input files
compilation terminated.
configure:3499: $? = 4
configure:3519: checking whether the C compiler works
configure:3541: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp$
collect2: fatal error: cannot find 'ld'
compilation terminated.
configure:3545: $? = 1
configure:3583: result: no
configure: failed program was:
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3588: error: in `/home/falko/rpm/BUILD/courier-unicode-1.1':
configure:3590: error: C compiler cannot create executables
gcc is one of a number of tools required to build a software package, and as you can see from the error in your config.log, some more are missing from your system:
collect2: fatal error: cannot find 'ld'
It is complaining that it cannot find the system linker (ld).
Before addressing this, I recommend you set the gcc version to be used correctly. Unfortunately the advice you followed from https://stackoverflow.com/a/13327320/612920 is somewhat incomplete.
Redhat based systems provide a mechanism for being able to switch between different implementations of a piece of software at will (for example, different versions). This tool is called alternatives. You should use that to set the GCC version that will be used when you run 'gcc' at the command line. It will update a whole set of symlinks, not just the one you manually set.
sudo alternatives --config gcc
After doing this set the linker to be used:
sudo alternatives --config ld
Note that when I've tried out an AMI linux image, I found that by installing gcc like this:
sudo yum install gcc48
it automatically set the correct 'alternatives' for the newly installed compiler and corresponding linker. I'm not sure how your system got into the state that it is currently in, but if you still have problems after the above procedure, I recommend uninstalling and re-installing gcc and binutils.
After a couple of research I had found out that I am just lacking of ld(GNU linker) tool from RedHat's developer tool set and I also found out that there is an alternative tool just in case ld(GNU linker) is not available, ld.bfd(alternative to the GNU linker) which is in my case it is available. What I did, I make a link from ld.bfd to ld:
ln /usr/bin/ld.bfd /usr/bin/ld
I don't know if it is the proper solution but it works for me.
Reference: Red_Hat_Developer_Toolset

undefined reference to sync_fetch_and_add_4

Whenever I try to use __sync_fetch_and_add with -m32 on a 64 bit machine, I get the following error, while it compiles fine with normal 64 bit. I am using gcc compiler 4.1.2. What can be the problem here and what is the solution?
replication.cpp:(.text+0xb3b): undefined reference to `__sync_fetch_and_add_4'
replication.cpp:(.text+0xb82): undefined reference to `__sync_fetch_and_add_4'
replication.cpp:(.text+0xcc2): undefined reference to `__sync_fetch_and_add_4'
/tmp/cc7u9FLV.o: In function `potential_barrier_leader(unsigned int, pthread_barrier_t*)':
replication.cpp:(.text+0xd3f): undefined reference to `__sync_fetch_and_add_4'
replication.cpp:(.text+0xd54): undefined reference to `__sync_fetch_and_add_4'
/tmp/cc7u9FLV.o:replication.cpp:(.text+0xdb0): more undefined references to `__sync_fetch_and_add_4' follow
collect2: ld returned 1 exit status
make: *** [all] Error 1
Using -march=i486 flag did the trick for me.
Try using a more recent GCC compiler (e.g. GCC 4.6). I tried to compile with gcc -S -O3 -m32 -fverbose-asm sync-3.c the test file gcc/testsuite/gcc.c-torture/compile/sync-3.c and it works. My gcc (on Debian/Sid/AMD64) is the system gcc 4.6.2 compiler.
hahah! there are 5+ "standard atomic libs" (+kernel support) that's hardly atom
ic if you ask me. but ignore it, is all a timely distraction.
so your building, ie glibc and get that error (i did)
glibc-2.11.x expects gcc-4.4.x to define it internally, and you have gcc sans bu
ilt-in atomic, likely you didnt specify arch that gcc accepts (due to lacky dire
ctions). were glibc likes 786, gcc wants 386 and figures 786 maybe. use "nativ
e" should do it. opt(march) and opt(mtune) ARE NON OPTIONAL gcc builds wrong w/
o them (likely)
you won't find a header or libfoo that defines it (per say)
for linux-gnu you might use (a simple for moi build)
cd gcc-4.4.foo
./configure --with-glibc-version=2.11 --enable-threads=posix \
--disable-cloog --disable-ppl --disable-libssp --enable-__cxa_atexit \
--disable-rpath --disable-nls --disable-bootstrp --disable-multilib \
--with-system-libunwind
IMPORTANT: if you build gcc w/o mtune march right, gcc wont define sync_fetch_and_add
(p.s. glibc sync_fetch_and_add_4 is just macro for sync_fetch_and_add which, aga
in, glibc expects is defined)
also if you replace gcc-3.foo with gcc-4.4.foo and are compiling you may need:
[ -n "$newgnu" ] && CFLAGS="$CFLAGS -march=native -mtune=native "
[ -n "$newgnu" ] && \
CFLAGS="$CFLAGS -std=gnu89 " && CPPFLAGS="$CPPFLAGS -std=gnu89 "
i newly need this (newgnu) to build binutils-ver/: -Wstrict-aliasing=0
cd glibc-2.foo/
./configure --with-headers=/usr/src/linux/usr/include \
--enable-kernel=2.2.foo \
--disable-profile --disable-sanity-checks --with-tls \
--disable-rpath --disable-nls
thanks guy in holland for posting --std that might be an issue for gcc upgraders !
no thanks to comittees continually changing and also creating "standards" that make depends problems in gcc :( use .h or .c appropriately for foo "builtin" to add features you want in your code like everyone else !!
have fun :)
With old GCC versions (4.5 for example) you might encounter the problem of __sync_fetch_and_add() being undeclared when using the g++ driver instead of gcc for linking a shared library.
Background: __sync_fetch_and_add is defined within static libgcc and missing from shared library libgcc_s.
So simply adding -lgcc might solve the problem. But there is a more elegant solution.
See here for full information and workaround(s):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563

Is there a way for extconf.rb to not use certain warning flags?

I just updated gcc from the default 4.2.1 to 4.5. But when I run ruby extconf.rb, I get a warning flag created that gcc doesn't recognize.
cc1: error: unrecognized command line option "-Wshorten-64-to-32"
Is there a way to edit the extconf.rb file to tell it not to use this warning flag, or is there a way to get gcc to recognize it? Here is my gcc version if it is helpful:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.5.3/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.5.3/configure --prefix=/opt/local --build=x86_64-apple-darwin10 --enable-languages=c,c++,objc,obj-c++,fortran,java --libdir=/opt/local/lib/gcc45 --includedir=/opt/local/include/gcc45 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.5 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.5 --with-gxx-include-dir=/opt/local/include/gcc45/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking --disable-multilib --enable-fully-dynamic-string
Thread model: posix
gcc version 4.5.3 (GCC)
mkmf generates makefile configurations by using a table of strings defined in CONFIG, and the warning flags are in CONFIG['warnflags'], so you can do something like
CONFIG['warnflags'].slice!(/ -Wshorten-64-to-32/)
before create_makefile is called to get rid of a specific warning flag.

Installing rb-gsl gem using Cygwin

I'm having issues installing rb-gsl under Windows using Cygwin. I'm using the RubyInstaller for Windows with the dev kit installed. I've installed Cygwin and the GSL runtime, gsl-apps, gsl-devel and gsl-doc packages. When issuing a gem install command I get the following:
$ gem.bat install "C:\Documents and Settings\jzh3fd.2UA1071FGF\Desktop\gsl-1.14
.7.gem"
Temporarily enhancing PATH to include DevKit...
Building native extensions. This could take a while...
ERROR: Error installing C:\Documents and Settings\jzh3fd.2UA1071FGF\Desktop\gsl
-1.14.7.gem:
ERROR: Failed to build gem native extension.
C:/Ruby192/bin/ruby.exe extconf.rb
checking gsl version... 1.14
checking gsl cflags... -I/usr/include
checking for main() in -lcblas... no
checking gsl libs... -L/usr/lib -lgsl -lgslcblas -lm
checking for round()... no
checking for rngextra/rngextra.h... no
checking for qrngextra/qrngextra.h... no
checking for ool/ool_version.h... no
checking for tensor/tensor.h... no
checking for jacobi.h... no
checking for gsl/gsl_cqp.h... no
checking for gsl/gsl_multimin_fsdf.h... no
checking for gsl_poly_solve_quartic() in -lgsl... no
checking for gsl_eigen_francis() in -lgsl... no
checking for ndlinear/gsl_multifit_ndlinear.h... no
checking for alf/alf.h... no
checking rb-gsl version...1.14.7
checking ruby version... 1.9.2
checking for graph... no
checking for narray.h... yes
checking for main() in -lnarray... no
checking for tamu_anova/tamu_anova.h... no
checking for main() in -ltamuanova... no
creating Makefile
make
C:/Ruby192/bin/ruby -e "puts 'EXPORTS', 'Init_rb_gsl'" > rb_gsl-i386-mingw32.de
f
gcc -I. -IC:/Ruby192/include/ruby-1.9.1/i386-mingw32 -I/C/Ruby192/include/ruby-1
.9.1/ruby/backward -I/C/Ruby192/include/ruby-1.9.1 -I. -DHAVE_NARRAY_H -IC:/Rub
y192/lib/ruby/gems/1.9.1/gems/narray-0.5.9.9/. -IC:/Ruby192/lib/ruby/site_ruby/1
.9.1/i386-msvcrt -Wall -I../include -I/usr/include -o alf.o -c alf.c
gcc -I. -IC:/Ruby192/include/ruby-1.9.1/i386-mingw32 -I/C/Ruby192/include/ruby-1
.9.1/ruby/backward -I/C/Ruby192/include/ruby-1.9.1 -I. -DHAVE_NARRAY_H -IC:/Rub
y192/lib/ruby/gems/1.9.1/gems/narray-0.5.9.9/. -IC:/Ruby192/lib/ruby/site_ruby/1
.9.1/i386-msvcrt -Wall -I../include -I/usr/include -o array.o -c array.c
In file included from array.c:14:0:
../include/rb_gsl_common.h:18:27: fatal error: gsl/gsl_errno.h: No such file or
directory
compilation terminated.
make: *** [array.o] Error 1
Gem files will remain installed in C:/Ruby192/lib/ruby/gems/1.9.1/gems/gsl-1.14.
7 for inspection.
Results logged to C:/Ruby192/lib/ruby/gems/1.9.1/gems/gsl-1.14.7/ext/gem_make.ou
t
I have checked and I can find gsl_errno.h at /usr/include/gsl
Try supplying the path for the GSL includes on the command line when installing the gem.
gem install gsl -- --with-gsl-include-path=/usr/include/gsl

Resources