Intel threaded building blocks gcc version - gcc

I have installed intel parallel studio. However looking at the gcc compiler in the directory structure of tbb it appears 4.8 is used. I am trying to build another repository that relies on tbb which is giving the following error which Im fairly certain is caused by the old version of gcc.
error:
/usr/include/tbb/concurrent_vector.h(667): error: ambiguous "?" operation: second operand of type "tbb::internal::concurrent_vector_base_v3::size_type" can be converted to third operand type "tbb::atomic<unsigned long>", and vice versa
/usr/include/tbb/concurrent_vector.h(680): error: ambiguous "?" operation: second operand of type "tbb::internal::concurrent_vector_base_v3::size_type" can be converted to third operand type "tbb::atomic<unsigned long>", and vice versa
2 errors detected in the compilation of "/tmp/tmpxft_00000d0e_00000000-4_gpu_handle.cpp4.ii".
make: *** [build/objs/cuda/tensor/gpu_handle.o] Error 2
the directory structure of tbb is as follows
mm470#pc5-036-l:~/usr/parallel_studio_xe_2020/compilers_and_libraries_2020/linux/tbb/lib/intel64/gcc4.8 $ dir
libtbb.so libtbb.so.2 libtbb_debug.so.2 libtbbmalloc.so libtbbmalloc.so.2 libtbbmalloc_debug.so.2
Does anyone know firstly if my hunch about the gcc version causing this error is correct and secondly how I would go about getting parallel studio installed with a newer version of gcc. My gcc on the computer is a higher version.
mm470#pc5-036-l:~/usr/parallel_studio_xe_2020/compilers_and_libraries_2020/linux/tbb/lib/intel64/gcc4.8 $ gcc --version
gcc (GCC) 6.3.1 20170216 (Red Hat 6.3.1-3)
Copyright (C) 2016 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.

gcc version is related to gnu runtime which will be used. AFAIR Intel compiler doesn't provide own runtime and using the gnu runtime. They(gcc runtime) had some breaking changes between earlier and 4.8 version.
AFAIS /usr/include/tbb/concurrent_vector.h is your local installed TBB from your linux distributive, not from compiler bundle. Try to source compiler environment script to setup different PATHes.

Related

GCC cross compiler for DOS produces linker errors for simple "Hello world!" in C

I've tried to configure GCC 9.3.0 to produce executable files for DOS. However, for a simple "Hello world!" program in C, it outputs:
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0xd6): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0x10b): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0x131): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0x141): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0x3d4): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(getenv.o):getenv.c:(.text+0x4): more undefined references to `_environ' follow
collect2: error: ld returned 1 exit status
djgpp-gcc -v outputs:
Using built-in specs.
COLLECT_GCC=djgpp-gcc
COLLECT_LTO_WRAPPER=/home/teo.samarzija/djgpp-9.3.0/libexec/gcc/djgpp/9.3.0/lto-wrapper
Target: djgpp
Configured with: ../gcc-9.3.0/configure --target=djgpp --prefix=/home/teo.samarzija/djgpp-9.3.0 --enable-languages=c,c++,objc,ada,fortran,go
Thread model: single
gcc version 9.3.0 (GCC)
I've also compiled the newest version of the GNU linker and GNU Assembler, they output as their versions:
GNU ld (GNU Binutils) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
and
GNU assembler (GNU Binutils) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `djgpp'.
Any idea what I am doing wrong? Have GCC or GAS or GLD stopped supporting DOS some time in the past? I suppose not, because they compile for DOS as a target without warning about that.
I only stumbled on this question because of a more recent Stackoverflow question you asked about some code that didn't run properly in 32-bit Windows 10 inside an NTVDM virtual DOS session.
The problem is that you have not properly built a DJGPP cross compiler and all the needed components. You do not show us what commands you use for the build process and which versions of the dependencies were used and where they came from.
1st thing you need to do is build a DJGPP cross compiler. There are some people who maintain scripts to do just that. One build environment/script in particular I have used successfully is from the user Andrew Wu on Github. It is very simple to use. It appears you are using a Unix type environment based on the output you have shown us. Since you managed to build DJGPP (albeit one that doesn't work) I will assume you have all the necessary build tools installed already. First retrieve the scripts with:
git clone https://github.com/andrewwutw/build-djgpp
Change into the project directory with:
cd build-djgpp
Review the README.md file! It tells you what versions are supported by the script, build requirements for the type of OS you are on etc. At present they support versions all the way to 10.1.0. If you have everything needed choose a version to build (I'll use 9.3.0 since it is the version you are using) and then start the build. You will have to build as root or use sudo as it installs to directory /usr/local/djgpp
./build-djgpp.sh 9.3.0
It will take a while but when finished it should be installed and ready to use. The naming convention is a bit different than prefixing the commands with djgpp-. This script builds things with a more complete target prefix i586-pc-msdosdjgpp-
To add it to your path and set up other environment variables use:
. /usr/local/djgpp/setenv
If you wish it to be done each time you are logged in add that line to your shell login script. For BASH that is in the file ~/.bashrc
Create a file called hello.c containing:
#include<stdio.h>
int main()
{
printf("Hello, world!\n");
}
Compile it to a file called hello.exe:
i586-pc-msdosdjgpp-gcc -O3 -Wall -Wextra hello.c -o hello.exe
Assuming you have a DPMI host installed (like CWSDPMI.EXE), hello.exe should run in MS-DOS, FreeDOS, DOSBox, a Windows NTVDM session etc. When run it should display:
Hello, world!
If you don't wish to build from scratch, Andrew Wu has a number of pre-built packages for a number of the latest DJGPP releases. Platforms they are available for are MacOS, Linux 32, Linux 64, MinGW, and a MinGW standalone version that doesn't need the MinGW environment to run.

How to compile C++ code using modules-ts and gcc (experimental)?

I've been trying to code something using the new experimental feature "modules-ts" that will be included in c++20. I've cloned the gcc branch (found here: https://gcc.gnu.org/wiki/cxx-modules), and I'm trying to follow that tutorial (on the link) using modules-ts but an g++ error is preventing me from doing that:
g++: error: unrecognized command-line option ‘-fmodules-ts’
I tried to see the version of g++, to make sure that is not reading from another previous version. And the answer is:
g++ (GCC) 10.0.0 20191029 (experimental)
Copyright (C) 2019 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.
Here is the command that I'm trying to run:
g++ -fmodules-ts hello.cppm main.cpp
Modules-ts is not merged into GCC's main branch yet. You need to download GCC's source and compile it yourself, for further instructions see GCC's installation guide. Grab the source using
svn co svn://gcc.gnu.org/svn/gcc/branches/c++-modules SomeLocalDir
instead of
svn checkout svn://gcc.gnu.org/svn/gcc/trunk SomeLocalDir
and you'll get the correct version.
EDIT:
For clarification, in this answer I assumed the OP did not compile the right GCC version because there is no svn revision number inside his gcc --version.

GDB Compilation Issue

I have run in an issue with compiling gdb from source. I am downloading version 8.2.1 but when I try to compile it, I get the following error:
configure: error: *** A compiler with support for C++11 language features is required.
make[1]: *** [configure-gdb] Error 1
My operating system is Red Hat 7.6 (Maipo) but i have a compiled from source gcc(that i set as the default one with an alias in bashrc)
gcc --version
gcc (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
which gcc
alias gcc='/usr/local/gcc8.2/bin/gcc'
/usr/local/gcc8.2/bin/gcc
which g++
alias g++='/usr/local/gcc8.2/bin/g++'
/usr/local/gcc8.2/bin/g++
What i have tried/read so far
Read the gdb manual regarding the configure and instalation part, also various stackoverflow links but nobody seems to have this problem
Read the README file in the gdb folder/subfolders
Tried setting the following env options CXX_FOR_TARGET=/usr/local/gcc8.2/bin/g++ GCC_FOR_TARGET=/usr/local/gcc8.2/bin/gcc (not sure if i should replace target with my actual target architecture)
Looked in the gdb-8.2.1 folder at the file config.log and found these: ac_cv_env_GCC_FOR_TARGET_value=/usr/local/gcc8.2/bin/gcc
ac_cv_prog_CXX_FOR_TARGET=/usr/local/gcc8.2/bin/g++
ac_cv_prog_GCC_FOR_TARGET=/usr/local/gcc8.2/bin/gcc
However in the C compiler section of the same config log I have found the following:
configure:4284: checking for C compiler version
configure:4293: gcc --version >&5
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
Copyright (C) 2015 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.
I am not sure ifi can use the devtoolset-8 gdb from RedHat because i have compiled gcc with GLIBCXX_USE_CXX11_ABI=1 and on RedHat due to a bug this is disabled by default and i am not sure if gdb will be able to manage the different binary interface.
Short version: What am I doing wrong that is making the GDB configure script not find the correct compiler and how can i fix/workaround this?
Thank you very much for your help!
A C++11-capable compiler for Red Hat Enterprise Linux 7 is provided as part of Red Hat Developer Toolset. It happens to include not just GCC 8, but GDB 8.2 as well, so you may not even have to compile it yourself. The DTS C++ compiler has been built in a special way so that it interoperates with the system C++ runtime. Unless you have replicated those modifications in your GCC build, it will not be compatible with the rest of the system (and you will have to replace the system libstdc++ library).
The system compiler in Red Hat Enterprise Linux 7 is based on GCC 4.8. In that version, C++11 support was still experimental and not enabled by default. You can try to configure GDB with
./configure CXX="g++ -std=gnu+11"
but this is not recommended (only the C++98 mode is supported).
The configure script does not use shell aliases because those are not inherited by shell scripts invoked from a shell. You will have to specify the full path to the C++ compiler explicitly (in the CXX= argument to configure), or adjust the PATH environment variable manually, or use scl enable to do so in a more polished fashion (for software collections such as Developer Toolset).

C++11 on Cloud9 IDE

When I run g++ --version on in my Cloud9 terminal I get g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3). This is a fairly old version - old enough that when I try to use C++11 library features like std::unordered_set, I get: "This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options."
I'm not really okay with this, because I don't like having to worry about what features I'm allowed to use and which ones I need to avoid. So I went looking around for how to update g++ to the latest stable version (which seems to be 4.8.1 as of this writing), but I can't figure out how to do it. I tried apt-get, but I just got an error: "Sorry, apt-get is not supported on this system. Try c9pm instead.". Well I tried that, but c9pm list (which is supposed to "List available packages") doesn't show anything that looks like g++. So I'm lost.
How do I install g++ 4.8.1 on Cloud9?
When I run lsb_release -a I see that Cloud9 IDE currently runs on "Red Hat Enterprise Linux Server release 6.4 (Santiago)".
If you choose C/C++ as the project type for a new project you will get a newer gcc version (currently 4.7.2). If you need an even newer one let us know and we can update that version. You can always try to compile the tools you need on the workspace but in case of gcc this might take ages.
This is no longer a problem. g++ --version now returns g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2 which, to my knowledge, has full support for C++11.
Actually, cloud9 gives you 4.8.2
cpp --version
cpp (Ubuntu 4.8.2-19ubuntu1) 4.8.2
Copyright (C) 2013 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.

CUDA SDK issues with gcc/g++: old version of gcc can't find old version of g++?

I'm installing CUDA on F15. I'm well aware of the fact CUDA needs older versions gcc/g++ and I've installed gcc/g++ 4.5.1, and softlinked them as documented here. I no longer get the error mentioned in that post...however, when I tried compiling the SDK, I get the following error:
make[1]: Entering directory `/home/whao/NVIDIA_GPU_Computing_SDK/C/src/bilateralFilter'
gcc: error trying to exec 'cc1plus': execvp: No such file or directory
make[1]: *** [obj/x86_64/release/filter_kernel.cu.o] Error 1
I suspect that somehow, the older version of g++ in question isn't being recognized? For what it's worth, consider the following two outputs:
[whao#gen-whao-cuda C]$ /usr/local/cuda/bin/gcc --version
gcc (GCC) 4.5.1 20101130 (Red Hat 4.5.1-6)
Copyright (C) 2010 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.
[whao#gen-whao-cuda C]$ /usr/local/cuda/bin/g++ --version
g++ (GCC) 4.5.1 20101130 (Red Hat 4.5.1-6)
Copyright (C) 2010 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.
There is a file named host_config.h where gcc version is checked (the path is /usr/local/cuda/include). You can comment out the appropriate if part (if gcc_version>4.5.* ....). gcc 4.5 may be supported in toolkit 4.1 but if this lines remain, there always be an error before even start compiling.

Resources