I have installed gcc 5.3.0(g++) and compiled mpich(mpic++) using that.
I already have my own Makefile, when i make from command line everything perfectly.
I also imported the project to eclipse PTP (Mars) and set the build option to make and set build folder to my source folder. Added my mpic++ and g++ paths to eclipse path environment variable.
When i build from eclipse, it finds and executes my make command, it even finds out my mpic++ but internally its using clang but not gcc
When i check mpic++ version on command line, i get
MacBook-Pro:mpi$ mpic++ --version
g++ (GCC) 5.3.0
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.
And i added the same command to my make file so that i can check whats happening on eclipse, I get this
( mpic++ --version; )
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.0.0
Thread model: posix
So i am not sure what i missed here. How do i change my eclipse to use gcc instead of clang?
Thanks in advance.
Related
We have a Solaris 11 system with gcc 7.3, we need to install the Ada package. On Linux gcc 7 came with the Ada/GNAT as part of the gcc install:
apt install gcc
I visited AdaCore looks like Solaris (SPARC) is not longer on the list. I need to use Ada95 and we want the same compiler on both Linux and Solaris in any case.
pkg install gcc
Only installed various C++ commands and Fortran.
pkg install gcc-ada
And variants like gcc7ada, found nothing to install.
If must, we can rebuild the Ada component of GCC 7, however I haven't found a clear cood-book style "How To ..."for that (yet).
Hopefully you can point me to these items in order of preference to help us get back-on-track.
Solaris 11 gcc-ada package for gcc7/Solaris 11 spark, and the package repository.
An 'alternative' package repository were I can retrieve the GCC Ada tooling.
Pre-build GCC 7 Ada module that we can copy to the right places.
Ready-rolled Build Ada/GNAT project for Solaris and how to download and get start building.
Instructions to download and build gcc-ada with gcc 7 on Solaris (or Unix).
From th epast few days searching about on Gnu Compiler Collection, Oracle, the package manager searches, google and so forth ... It really seems like there's next to no support for CGG Ada on Solaris these days.
I very interested in other solutions beyond that list. For instance, has anyone cross-compiled from Linux to Solaris? Would that work with GDB on the Solaris machine anyway?
Looking forward to your suggestions.
I've successfully built gcc 7.50 (x86_64 native with i386 cross-compiler) with GNAT on OpenIndiana (Hipster 2020/10) using the following procedure.
Download the bootstrap compiler from Dragonlace at http://downloads.dragonlace.net/src/ada-bootstrap.x86_64.solaris.511.tar.bz2
Get the illumos gcc 7.5.0 source from https://github.com/illumos/gcc/tree/il-7_5_0
Put the bootstrap compiler's bin directory at the front of $PATH, replace /usr/bin/gcc /usr/bin/cpp /usr/bin/g++ with symlinks to their counterparts in the bootstrap compiler directory (see note below re g++ and c++)
Make sure you've got gnu-binutils and gmake; then run contrib/download_prerequisites
Configure with
--enable-languages='c ada c++' --build=x86_64-aux-solaris2.11 --enable-threads=posix --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-nls --disable-shared --disable-lto --disable-libstdcxx-pch --enable-multilib --with-gnu-as --with-as=/usr/bin/gas --without-gnu-ld --with-ld=/usr/bin/ld
gmake and then gmake install
NOTES:
This setup should be close enough to Solaris 11 to work. If it doesn't, try using the regular gcc 7.5.0 release rather than the illumos-modified branch.
If you get stuck at a linking stage, try using a gcc ld, but you should definitely try to use the Solaris ld first. The gnu as (gas) makes the build go much more smoothly. I didn't have any problems, but if you get stuck at the end of stage 1 or the beginning of stage 2, try setting $CONFIG_SHELL=/usr/bin/ksh -- I think it has been fixed, but at least with older gcc releases one needed to specify ksh because the built-in sh had some non-POSIX peculiarities that didn't work with some of the components' makefiles
I couldn't get one of the support libs for gnat to compile easily without building gcc c++ and using g++ with a full bootstrap. You might be able to figure it out, but the path of least resistance is likely to build gcc c++ and put the g++ symlink in /usr/bin, which is where the makefile wanted to find it.
Please note that I don't know much about Solaris, but a quick search on Google gave me the website OpenCSW. This website provides the packages gcc4ada and gcc5ada.
It appears that gcc5ada is build using a makefile (as found here, in particular notice line 424). A similar makefile exists for gcc7ada (as found here, in particular notice line 426). However, while it seems that the package "gcc7ada" can be created with the latter makefile, it is not published on the OpenCSW.org website (website is no longer updated?).
You could try to install gcc5ada first and then use this old GCC/GNAT compiler as a bootstrapper for compiling the required version (using the GCC 7 makefile).
For some reason it forces -G Ninja when I try to build within eclipse. I would prefer Eclipse just not specify the -G option to cmake, but I can't figure out how to configure Eclipse to do that.
For exampe, this in my console window:
Building in: /home/bgass/eclipse-workspace/scomlib/build/default
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_EXPORT_COMPILE_COMMANDS=ON /home/bgass/eclipse-workspace/scomlib
CMake Error: Error: generator : Ninja
Does not match the generator used previously: Unix Makefiles
Either remove the CMakeCache.txt file or choose a different binary directory.
cmake --build . -- -v
GNU Make 4.2.1
Built for x86_64-redhat-linux-gnu
Copyright (C) 1988-2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Build complete (0 errors, 0 warnings): /home/bgass/eclipse-workspace/scomlib/build/default
In a terminal it works just fine without the generator specified.
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_EXPORT_COMPILE_COMMANDS=ON /home/bgass/eclipse-workspace/scomlib
-- Configuring done
-- Generating done
-- Build files have been written to: /home/bgass/eclipse-workspace/scomlib/build/default
I always execute cmake outside eclipse and open the generated eclipse project in Eclipse.
use -G "Eclipse CDT4 - Unix Makefiles" to specify Eclipse as the generator.
Following are the full set of Eclipse generators.
Eclipse CDT4 - NMake Makefiles
= Generates Eclipse CDT 4.0 project files.
Eclipse CDT4 - MinGW Makefiles
= Generates Eclipse CDT 4.0 project files.
Eclipse CDT4 - Ninja = Generates Eclipse CDT 4.0 project files.
Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.
Type in cmake --help to see what generators are supported by your specific cmake version.
I am on a Mac. I updated my OSx to Yosemite. I updated my xcode to version 6. I downloaded the command line tools.
And still, whenever I type in g++ --version, I get:
# g++ --version
couldn't understand kern.osversion `14.1.0'
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Copyright (C) 2007 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.
meaning, I am still using the old version of g++ and gcc.
Why wasn't it upgraded? I am interested in using c++0x in Eclipse, and for that I need a newer g++/gcc compiler.
EDIT: following the comment below, I have two questions:
Why
$ clang --version
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
do I still seem to have an old version of clang?
Why didn't the installation of xcode and the command-line tools create the proper links to clang?
It looks like you maybe have an old version of xcode also installed.
From the command line you can switch to the proper one with
xcode-select --switch <path>
You should see something like this
$ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
$ clang --version
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
I had a similar problem installing ios-deploy after upgrading to yosemite. i was getting the same
couldn't understand kern.osversion `14.1.0'
for gcc. I ultimately solved it by:
cd /opt/local/bin/
sudo rm gcc
sudo ln -s /Applications/Xcode.app/Contents/Developer/usr/bin/gcc gcc
This correctly pointed gcc to the the version provided by Xcode 6.1.
I am using 32-bit eclipse CDT Kelper to manage a piece of code, which I could compile on command line but not with eclipse if I use any up-to-date c++11 feature. CDT tells me that "-std=c++11" is unrecognized.
After turning on the verbose option in project properties\settings\tool settings, I found that eclipse CDT somehow chooses an older version of MinGW that comes with Haskell platform 2013.2:
Configured with: ../gcc-4.5.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.2 (GCC)
COLLECT_GCC_OPTIONS='-O0' '-g3' '-Wall' '-c' '-fmessage-length=0' '-v' '-o' 'src\vaomp_bnb.o' '-shared-libgcc' '-mtune=i386' '-march=i386'
c:/haskell platform/2013.2.0.0/mingw/bin/../libexec/gcc/mingw32/4.5.2/cc1plus.exe -quiet -v -iprefix c:\haskell platform\2013.2.0.0\mingw\bin\../lib/gcc/mingw32/4.5.2/ -dD ..\src\vaomp_bnb.cpp -quiet -dumpbase vaomp_bnb.cpp -mtune=i386 -march=i386 -auxbase-strip src\vaomp_bnb.o -g3 -O0 -Wall -version -fmessage-length=0 -o C:\DOCUME~1\ting\LOCALS~1\Temp\ccWNoh7I.s
GNU C++ (GCC) version 4.5.2 (mingw32)
I searched SO, and there is a similar question a half year ago here. But the answer there was about setting environment variables and didn't solve the problem.
In my case, CDT can find a MinGW GCC, but found the wrong one. I have installed tdm-gcc 64 bit with gcc-4.8.1, and Haskell platform. The tdm-gcc has priority and
gcc --version
on both DOS and MSYS shows
gcc.exe (tdm64-2) 4.8.1
I don't know what heuristic does CDT use to find toolchains. My question is, how can I tell CDT to use the gcc in a specific location, e.g. c:/MinGW?
Note, I can't uninstall the Haskell platform version of gcc as I will need HP.
Thanks,
I figured it out. It seems that Eclipse CDT does not take tdm-gcc MinGW 64-bit because eclipse itself is 32-bit. So it picked up the only 32-bit MinGW it can find, which is the old version from HP.
To verify this, I installed java 1.7 64-bit, and downloaded 64-bit version of Eclipse CDT (Kelper). Now, CDT automatically selects the TDM-GCC 64 version of MinGW gcc.
For those in a similar situation, one additional issue is that the 64-bit CDT - MinGW64 combination combination does not build projects. No binary/executable files are generated even for a newly created HelloWorld c++ project (even though compilation is OK). In my case, I changed the build tool in the project properties..\tool chain. from CDT internal builder to either of the other two options (one is Gnu's and another is a long name), and then the project can be successfully made to generate exe files.
I've had Eclipse for Java on my computer for a few years, and decided to install the CDT and learn C. I installed both MinGW and Cygwin and the CDT detects and tries to use them when I make a new project.
I choose File > New C++ Project and choose Hello World C++ Project and the CygwinGCC toolchain. I name the project "asdf" and hit "Build Debug" in the toolbar. The compiler completes without error. I hit Run and nothing happens.
Browsing to the project directory manually and running asdf.exe gives me an error saying:
"The program can't start because cygwin1.dll is missing from your computer. Try reinstalling the program to fix this problem."
The same thing happens using MinGW, only a different dll is missing.
What do I need to do to have a usable .exe?
(I'm running Windows 7 x64 and the newest version of Eclipse and the CDT.)
EDIT:
The compiler output is as follows:
**** Build of configuration Debug for project asdf ****
make all
Building file: ../src/asdf.cpp
Invoking: Cygwin C++ Compiler
g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/asdf.d" -MT"src/asdf.d" -o"src/asdf.o" "../src/asdf.cpp"
cygwin warning:
MS-DOS style path detected: C:\Users\Shawn\Dropbox\eclipse\asdf\Debug
Preferred POSIX equivalent is: /cygdrive/c/Users/Shawn/Dropbox/eclipse/asdf/Debug
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
Finished building: ../src/asdf.cpp
Building target: asdf.exe
Invoking: Cygwin C++ Linker
g++ -o"asdf.exe" ./src/asdf.o
Finished building target: asdf.exe
This error message means that Windows isn't able to find "cygwin1.dll". The Programs that the Cygwin gcc create depend on this DLL. The file is part of cygwin , so most likely it's located in C:\cygwin\bin. To fix the problem all you have to do is add C:\cygwin\bin (or the location where cygwin1.dll can be found) to your system path. Alternatively you can copy cygwin1.dll into your Windows directory.
There is a nice tool called DependencyWalker that you can download from http://www.dependencywalker.com . You can use it to check dependencies of executables, so if you inspect your generated program it tells you which dependencies are missing and which are resolved.
You can compile with either Cygwin's g++ or MinGW (via stand-alone or using Cygwin package). However, in order to run it, you need to add the Cygwin1.dll (and others) PATH to the system Windows PATH, before any cygwin style paths.
Thus add: ;C:\cygwin64\bin to the end of your Windows system PATH variable.
Also, to compile for use in CMD or PowerShell, you may need to use:
x86_64-w64-mingw32-g++.exe -static -std=c++11 prog_name.cc -o prog_name.exe
(This invokes the cross-compiler, if installed.)
To add to this and save someone another google, just do this in cmd:
set PATH=%PATH%;C:\cygwin64\bin