I am running Redhat Developer Toolset 7 on Centos 7. Centos 7 has gcc 4.8.2 installed by default and the include path for that compiler is:
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/include/
Devtoolset 7 provides g++ 7.3.1 and that compiler is found at:
/opt/rh/devtoolset-7/root/usr/bin/g++
I'm using VS Code with the cpptools extension to develop the code. I may need to specify the browse path for system header files to cpptools.
What is the include path for devtoolset 7? I.e. where are the g++ 7.3.1 header files found (or are the 4.8.2 header files used)?
The include paths are shown by:
cpp -v
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).
How can I compile a swift file on Mac as an executable to run on Windows?
All I need is an executable that can be called from C# code.
If you have a proper swift library module for Windows, your swift compiler for macOS can generate object files for Windows, such as Hello.obj.
Moreover, you can build the executable (ex. Hello.exe) if you have the special linker and some C/C++ runtime object files for Windows.
All you need one is follows.
Copy the directories to the macOS from the package for Windows.
1) Install Swift for Windows ver-1.5 (https://swiftforwindows.codeplex.com) on Windows
2) Copy directories to macOS from Windows
SwiftForWindows/Swift/lib/swift // Swift library for Windows (MinGW)
SwiftForWindows/Swift/lib/mingw // C/C++ runtime object files (MinGW)
Install Swift compiler for MacOS (https://swift.org/builds/swift-3.0-release/xcode/swift-3.0-RELEASE/swift-3.0-RELEASE-osx.pkg)
You should use the same version for the library module and compiler. Use the version 3.0. Swift 3.0.1 or 3.1 will not work with SwiftForWindows-1.5.
Install MinGW linker with Mac Port
1) Install Mac Port (https:// www.macports.org/install.php)
2) $ sudo port install x86_64-w64-mingw32-binutils
3) Create directory bfd_ld and copy /opt/local/bin/x86_64-w64-mingw32-ld and name to ld
$ mkdir bfd_ld
$ cp -p /opt/local/bin/x86_64-w64-mingw32-ld bfd_ld/ld
More Settings
1) Rename the directory in macOS
mv SwiftForWindows/Swift/lib/swift/mingw SwiftForWindows/Swift/lib/swift/windows
2) Copy C runtime objects (3 files)
cp SwiftForWindows/Swift/lib/mingw/*.o bfd_ld
Compiling
echo "print(Hello)" > Hello.swift
~/Library/Developer/Toolchains/swift-3.0-RELEASE.xctoolchain/usr/bin/swiftc -target x86_64-pc-windows-gnu -resource-dir SwiftForWindows/Swift/lib/swift -tools-directory bfd_ld -L SwiftForWindows/Swift/lib/mingw -lswiftSwiftOnoneSupport -o Hello.exe Hello.swift
This will generate Hello.exe. You can ignore the 'Warning: .drectve' message.
Running
The executable file will need the DLL's in the directory 'SwiftForWindows/My Programs'.
Copy Hello.exe to the directory in Windows and run it.
Good luck to you. Thanks.
If you want to run Swift code on Windows, the closest you can get is swift-windows. I have never used it but it looks like you can compile Swift 3.0 code to a Windows executable.
To download pre-built binaries, try this link. It requires Windows 10 64 bit and the Visual Studio 2015 SDK. Additionally you will have to have a cygwin or mingw environment.
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 have been asked to port a Linux C++ application to 64-bit RedHat 6.2. Instructions for buildling the application indicate that GTK+ (gtkmm24-2.8.0 or greater) and GLADE (libglademm24-2.6.1 or greater) are required. I successfully ran: aclocal, automake and ./configure but when I run make, I get:
error: gtkmm.h No such file or directory
I could not find gtkmm.h anywhere in the file system. I used yum to search for gtkmm and it found gtkmm24.x86_64 which I installed but it did not install gtkmm.h. Does anyone know how I can get the header files for gtkmm for 64-bit RedHat 6.2?
Install gtkmm24-devel. After that you'll be able to use
pkg-config --cflags gtkmm-2.4
to get the list of include directories needed for using gtkmm.
I have gcc 3.4.6 installed on sparc9 and sparc10 systems. I am having incompatibility issues when I try to use shared object(built on sparc9) on sparc10. I am not seeing any issue if I use same shared object on sparc9 system. Snippet from makefile:-
LIB=-L/usr/lib/sparcv9 -L/usr/local/lib/sparcv9 -L/lib/sparcv9
gcc -m64 -shared -fPIC -o myapi.so.1 myapi.o $(LIB) -lc -lstdc++ -luuid
Now following in sparc10:-
ldd -d /home/myapi.so
libstdc++.so.6 => /usr/local/lib/sparcv9/libstdc++.so.6
symbol not found: _ZNSt15basic_streambufIcSt11char_traitsIcEE7seekoffExSt12_Ios_SeekdirSt13_Ios_Openmode (./myapi.so)
I have skipped other dependencies in above output which appear normal.
Then, I ran "nm" against libstdc++.so.6 in /usr/local/lib/sparcv9 for above unreferenced symbol and came with following conclusion:-
V9---> _ZNSt15basic_streambufIcSt11char_traitsIcEE7seekoffExSt12_Ios_SeekdirSt13_Ios_Openmode
V10--->_ZNSt15basic_streambufIcSt11char_traitsIcEE7seekoffElSt12_Ios_SeekdirSt13_Ios_Openmode
If you look carefully, you can see a difference in mangled-name symbol in sparc9 and sparc10... "ExSt12" v/s "ElSt12".
Similarly, if I build myapi.so on sparc10, it fails on sparc9 because of symbol mismatch in V9 and V10.
Can someone please point me to any helpful hints as to if I am missing something? Or do I need to install any package on V9. I am assuming that shared object built on V9 should work on V10.
I would like to add that there is a size of libstdc++.so.6 on V9 is different from V10. V9 has SMCgcc and V10 has both SUNWgccruntime and SMCgcc.
Those symbols demangle as:
std::basic_streambuf<char, std::char_traits<char> >::seekoff(long long, std::_Ios_Seekdir, std::_Ios_Openmode)
and
std::basic_streambuf<char, std::char_traits<char> >::seekoff(long, std::_Ios_Seekdir, std::_Ios_Openmode)
Notice that one uses long and the other uses long long
I suspect that means one was built with 64-bit file offsets (aka large file support) and the other wasn't. That means the two versions of GCC have been built differently (by sunfreeware.com or whoever provided them) and are incompatible.
Looks like you're using incompatible versions of the GNU C++ compiler & standard library on the two OS'es. Unfortunately, there is no standard ABI for C++ and many compilers change symbol mangling conventions incompatibly between major releases (such as Sun C++ compiler 4.x vs. 5.x, or g++ 2.x vs. 3.x vs. 4.x).
The /usr/local/lib path implies you're using the libraries from the SMCgcc packages downloaded from the sunfreeware.com site - make sure you have matching versions on the Solaris 9 and 10 machines. (There is no "sparc 10", so you must mean Solaris 10.)