I'm trying to compile a simple hello world test program just to get things working on our CI infrastructure build boxes and it refuses to compile on CentOS with clang (but works fine with GCC on the same platform). For completeness, here is the obviously trivial program:
#include <iostream>
int main(){
std::cout << "wow" << std::endl;
return 0;
}
Running clang++ test.cpp yields:
test.cpp:1:10: fatal error: 'iostream' file not found
I installed it with a simple sudo yum install clang and can see that when GCC gets installed on Amazon Linux it comes with its own libstdc++ headers which are in /usr/include/c++/gcc-version but it seems odd to have to specify includes to compile something like this.
Clang should be using its own (possibly libc++) instead and know where the headers and libs are on the system by default (for something like iostream at least).
Compiling and running the program works just fine with GCC here. It seems like the EPEL package for clang may not have been configured correctly, is this the case? Any help would be greatly appreciated.
As Dave mentioned, he has created new RPM packages which are now in EPEL testing. You can install them on Amazon Linux right now like this:
yum --enablerepo=epel-testing --nogpgcheck install clang
Once the packages are tested further they will be in EPEL proper (stable) and be installable using clang install.
This is caused by the "triples" not being defined to support Amazon Linux. See original patch and application for EPEL on EL6.
Related
I'm trying to compile a test openmp program on an Amazon AWS t2.micro instance. It seems to have trouble. Upon trying to compile this OpenMP hello world program, the compiler fails to find omp.h despite using gcc hello_world.c -fopenmp.
After that, I tried running locate omp.h and found it in /usr/lib/gcc/x86_64-amazon-linux/4.8.5/include. I next attempted to compile by including that directory with gcc -I. Then, the compiler still needed libgomp.spec, which has been encountered and solved in this stack overflow question.
Following the most upvoted answer on there by creating some symbolic links did nothing for me and still says error: libgomp.spec: No such file or directory, even though libgomp.spec is in my /usr/lib64 directory.
So, what can I do to fix this, and why won't -fopenmp work on amazon linux like expected? This is done on an instance which was created by CfnCluster, if that helps.
As usual, header files such as omp.h come with relevant version of gcc compiler. When the compiler can't find the header file, I guess you are using the different version compiler (other than 4.8.5 in this case).
You can find all gcc versions by typing:
sudo yum list installed | grep gcc
If there are other versions of gcc such as gcc72, you can erase them by:
sudo yum erase gcc72
After that, you will compile the code successfully.
Exactly, as told #S.Takezawa , currently only gcc 6.4 installation supports libgomp (fopenmp) and supports modern c++14 standard on Amazon AMI linux.
gcc4.7 is too old. So this helps for me:
sudo yum install gcc64-c++.x86_64 libgcc64.x86_64
I am running centos 6 on a cluster. I installed the latest gcc-8.2.0. and made a link "ln -sf /usr/bin/gcc-8.2 gcc".
I did the same for g++ and gfortran.
I wanted to reinstall gcc-8.2.0 and went ahead to
make clean
in the gcc-8.2 directory.
When I try
./configure
I get that C compiler cannot create executables
The links I made are broken.
The system gcc-4.4.7 cannot be found
which gcc
gives no gcc
sudo yum install gcc gcc-c++
gives gcc is already installed.
I tried to install an rpm, which fails because of dependencies.
I have pg compilers installed in /opt/pgi
When I configure with
CC=/path to/pgi/bin/pgcc FC=/path to/pgi/bin/pgfortran ./configure
I still get C compiler cannot create executables
I tried the following c++ programm
#include <iostream>
using namespace std;
int main() {
cout << "Hello world!" << endl;
return 0;
}
With the command
/opt/pgi/linux_86_64/12.08/bin/pgcpp hello.cpp -o hello
It gives compilation error that float.h not found. On another linux PC with working gcc, the program works with the command
g++ hello.cpp -o hello
I will appreciate any assistance to either find the systemgcc or use pg compilers to compile gcc if possible
I admit it is a big mess which will require OS reinstallation and reconfiguration. But then I did
sudo yum install compat-gcc-34
Now I have gcc34 and configure of gcc-8.2 goes through without "c compiler cannot create executables". (Note that the ./configure referred to in earlier post was actually
../gcc_8_2_release/configure
inside "gcc_8_2_release_build, so gcc was not being built in its source directory.
The problem I have now is with make, which needs g++, giving error
uint_t(64) or int_t(64) not found.
Thanks all who have gone through this post, for your patience.
Any assistance will be appreciated.
Here is how I got out of this mess.
With the following two commands
sudo yum install compat-gcc-34-c++
sudo yum install compat-gcc-34-g77
I was able to install the older version of gcc, c++ and g77. Then I was able to build gcc-8.2.
Now I have a functional system with the latest gcc, yes it may need re-installation/re-configuring but it is fully functional.
I have learnt a lot and very much appreciate the comments and guidelines of #Basile. However, at one point he was rather negative and discouraging.
But thanks to my belief and perseverance, and more importantly browsing the knowledge shared by others, I have been able to recover what I was beginning to be convinced was a lost cause.
Thanks all.
This is more a sysadmin question than a programming one.
My recommendations:
don't mess your /usr/bin/. Leave your package manager yum to fill it -and never add anything inside it without yum ; so remove manually any symlinks you made there (by mistake)
reinstall the old system gcc 4.4 and g++ 4.4 (using yum)
rebuild your GCC 8 from scratch from its source code. Configure it with --program-suffix=-8 (but no --prefix, or a --prefix=$HOME/soft/ if you don't have root access). So it will install /usr/local/bin/gcc-8 and /usr/local/bin/g++-8 etc... (or, if you have given --prefix=$HOME/soft/ , a $HOME/soft/bin/gcc-8 etc...)
create a $HOME/bin/ if you don't have already one
be sure to have $HOME/bin/ early in your $PATH (before /usr/bin/)
add a symlink ln -sv /usr/local/bin/gcc-8 $HOME/bin/gcc and likewise for g++ etc..
Then, when you type gcc you are getting that symlink to /usr/local/bin/gcc-8 etc.
If you cannot write to /usr/local/ (e.g. because you don't have root permission...) you could pass --prefix=$HOME/soft/ to GCC 8 .../configure then replace /usr/local/ above with $HOME/soft/
If you are the sysadmin and can write to /usr/local/ and have to set up things for many users: add a symlink ln -s /usr/local/bin/gcc-8 /usr/local/bin/gcc etc and ask your users to put /usr/local/bin/ in their $PATH before /usr/bin/
BTW, notice that it is explicitly documented that GCC 8 (or others) need to be built outside of its source tree: in Installing GCC you can read:
First, we highly recommend that GCC be built into a separate directory from the sources which does not reside within the source tree.
(the "highly recommend" should be considered as a polite way to say "you absolutely should")
So your ./configure was another mistake.
It could happen that you messed up your system more seriously than you thought (and perhaps you need to reinstall, or to call Redhat support).
PS. I don't know Redhat (used it only in the previous century). My favorite distro is Debian/testing or Debian/unstable (and my computers are desktops, not clusters).
This problem was solved by the following commands
sudo yum install compat-gcc-34-c++
sudo yum install compat-gcc-34-g77
Once this older version of gcc is installed, the latest version, gcc-8.2 was built and the system is no longer messed terribly. It is very healthy and fit.
I am currently running a debian Jessy whose g++'s version is 4.9. For some reason I need to compile a code in g++-4.7 or previous version.
I got the files of gcc-4.7 and g++-4.7 from a debian wheezy of a friend who has g++-4.7.
I tried to make the apt-get install, it seemed to have worked for the gcc but not for the g++. I put the files in the /bin, but he doesn't seem to locate the g++-4.7 package.
When I try to compile my code I specify g++-4.7 but get the error :
g++: error trying to exec 'cc1plus': execvp: No such file or directory
Any idea how to figure this out?
My advise is to add the wheezy repositories to /etc/apt/sources.list and then install g++-4.7 using apt-get. Using this method you will also get bugfixes etc.
I guess, currently you're just having dependency Problems. These will be solved when you use apt-get.
It is very easy to install gcc from sources. Remember that you have also to use a binutils version which maps to the gcc version. Mostly it is possible to run older gcc versions on actual binutils, but I have also seen a problem during install.
I have installed a long list of gcc versions in /opt/
Simply copy an older gcc version somewhere in the file system can result in problems with using the correct library versions.
If you install different gcc versions and also the related libraries e.g.libstdc++ , don't forget to update your library data base ( ldconfig/LD_LIBRARY_PATH/...) Maybe http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html can help.
i am new to linux and I have the following question:
I am trying to install MINGW in Ubuntu.
I ran the command:
sudo apt-get install mingw-w64
It was installed, and if i put the command gcc it runs ok. The problem is g++ command does not work. I guess it is because i don't have the c++ compiler (as I read in similar questions in stackoverflow).
I read too that you can use the next command:
mingw-get install g++
but i don't have the executable program for this command.
My question is, how can I install that executable? or is there another way to update my mingw so I can use the g++ compiler?
Hope I have explained myself correctly. Thank you for any help I receive.
mingw-get is a windows specific package manager, it is not needed when you use a native linux package manager such as APT.
Installing package mingw-w64 depends on package g++-mingw-w64, which depends on g++-mingw-w64-i686 and g++-mingw-w64-x86-64.
These packages install the mingw cross compilers as
/usr/bin/x86_64-w64-mingw32-g++-posix
/usr/bin/x86_64-w64-mingw32-g++-win32
/usr/bin/i686-w64-mingw32-g++-posix
/usr/bin/i686-w64-mingw32-g++-win32
Older versions of mingw cross compiler shipped /usr/bin/i586-mingw32msvc-c++, which is replaced by i686-w64-mingw32-c++-win32
You can usually use this toolchain in a project by running ./configure CXX=i686-w64-mingw32-c++-win32 or make CXX=i686-w64-mingw32-c++-win32
Note: the above description is correct for the most recent toolchain in Debian unstable. It may need some minor tweaking for older systems.
I am receiving the following error when I try to compile a very basic C++ program.
$ g++ -fuse-linker-plugin test.cpp
g++: fatal error: -fuse-linker-plugin, but cyglto_plugin.dll not found
compilation terminated.
Code
int main() {
return 0;
}
This is using G++ installed straight out of a fresh Cygwin installation.
If I search for the file there, it does exist and is located at:
/usr/libexec/gcc/x86_64-pc-cygwin/4.8.2/cyglto_plugin.dll
How do I make Cygwin 64 look at this correctly?
I guess you only checked the gcc-g++ package at installation. Note that the version is 4.8.1-3 BUT on the next page you can see a lot of dependencies being installed, for example libgcc with version 4.8.2.
That mix of 4.8.1 and 4.8.2 seems to be the problem.
In the installer, copy all dependencies into an editor, search for 4.8.2 to find the problematic packages, go back in the installer and click those packages until 4.8.1-3 will be installed.
Double check you're not installing the latest version of those packages.
More recently using apt-cyg, g++ 4.9.2 was installed but gcc-core 4.8.2 remained.
Resolved by:
apt-cyg remove gcc-g++
apt-cyg remove gcc-core
apt-cyg install gcc-g++
Two version of gcc was causing proble, check folder /usr/libexec/gcc/x86_64-pc-cygwin/ there would be two version of gcc.
To solve remove one.
The above answer worked for me, but I got caught by the installer automatically upgrading packages back to 4.8.2. So, I initially thought this didn't work; it actually did. You just need to be aware of that when using the installer to add packages later, it may try to upgrade back to 4.8.2 again and break things.
There is the option to turn off LTO with -fno-use-linker-plugin, but that doesn't do me any good becuase CPAN is what is launching g++. It might serve as a workaround.
(I know this isn't much of an answer, but I was unable to comment)