I'm trying to update GCC on a particular linux machine I have, to a version for which there is no package available.
I run the configure script and it complains about the version of GMP:
# ../gcc/configure
checking build system type... i686-pc-linux-gnu
[snip]
checking for the correct version of gmp.h... no
configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
their locations. Source code for these libraries can be found at
their respective hosting sites as well as at
ftp://gcc.gnu.org/pub/gcc/infrastructure/. See also
http://gcc.gnu.org/install/prerequisites.html for additional info. If
you obtained GMP, MPFR and/or MPC from a vendor distribution package,
make sure that you have installed both the libraries and the header
files. They may be located in separate packages.
However, when I check gmp.h it shows:
/* Major version number is the value of __GNU_MP__ too, above and in mp.h. */
#define __GNU_MP_VERSION 4
#define __GNU_MP_VERSION_MINOR 2
#define __GNU_MP_VERSION_PATCHLEVEL 1
and RPM reports the following:
# rpm -q --qf "%{VERSION}\n" gmp
4.2.1
# rpm -q --qf "%{VERSION}\n" gmp-devel
4.2.1
so both library and headers seem to be of a correct version to me (confusingly, the numbering of the .so file for libgmp seems to have exactly nothing to do with the version number... that is showing as
libgmp.so -> libgmp.so.3.4.1
Does anyone know why this might be failing? Those are the only two gmp packages installed on this machine and they are in standard /usr/include and /usr/lib locations, so they should be on the search path already.
Please read Installing GCC:
The difficult way, which is not recommended, is to download the sources for GMP, MPFR and MPC, then configure and install each of them in non-standard locations, then configure GCC with --with-gmp=/some/silly/path/gmp --with-mpfr=/some/silly/path/mpfr --with-mpc=/some/silly/path/mpc, then be forced to set LD_LIBRARY_PATH=/some/silly/path/gmp:/some/silly/path/mpfr:/some/silly/path/mpc/lib in your environment forever. This is silly and causes major problems for anyone who doesn't understand how dynamic linkers find libraries at runtime. Do not do this. If building GCC fails when using any of the --with-gmp or --with-mpfr or --with-mpc options then you probably shouldn't be using them.
Just run ./contrib/download_prerequisites and save yourself a lot of time and pain.
Turns out that "Building GCC requires GMP 4.2+" is insufficiently detailed. Digging into configure, it's actually checking:
#if GCC_GMP_VERSION < GCC_GMP_VERSION_NUM(4,2,3)
choke me
#endif
i.e. GMP 4.2 .3 or greater, so my 4.2.1 wasn't cutting it.
Related
I am building an self-made shared library using G++ 4.9.3 on Centos 6.8.
This library uses boost::interprocess::file_lock and version of boost is 1.41.0.
I am not working on multiple environment.. I just use a device and I've never changed build environment after I built the library.
When I build library, g++ build it well. But when I run it by linking with an binary, it shows
"./a.out: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by ./libmylib.so)".
So, I checked which versions supported by the libstdc++ and it show it doesn't support GLIBCXX upper than 3.4.13.
GLIBCXX_3.4.13 is the latest version of /usr/lib64/libstdc++.so.6 supports.
Even though I am working on a device and its libstdc++ doesn't support GLIBCXX_3.4.15, the library build from my device requires GLIBCXX_3.4.15.
And another binaries doesn't require GLIBCXX_3.4.15 even if I use same compiler(g++4.9.3). They just work well.
How can the library notice it should use GLIBCXX_3.4.15?
Is it differed by source code?
Does compiler tell the library such as "you require to use GLIBCXX_3.4.15 because you use some special grammar in your code"?
I want know who determine which version of GLIBCXX to use for a binary.
It depends on the version of GCC, the compiler flags, and the source code. Symbols such as GLIBCXX_3.4.15 are only referenced if a specific feature is used in a program. The list of features for this particular symbol version is rather large. You can get a sense of what features are relevant using this command (which you have to run against the newer libstdc++, i.e. the one that comes with GCC 4.9):
$ readelf -sW libstdc++.so.6 | awk '/#GLIBCXX_3.4.15/{print $8}' \
| sort -u \
| c++filt
If you want to run your program with the unmodified libstdc++.so.6 version that comes with Red Hat Enterprise Linux or CentOS, you can use Developer Toolset (which is also available as a supported part of Red Hat Enterprise Linux. Developer Toolset avoids dependencies on newer symbol versions by using the old (C++98 era) C++ ABI and providing statically linked copies of functions which are not part of the system libstdc++ version for the particular target operating system version.
I have code that depends on <X11/Xlocale.h>. When I try to compile with the emscripten tool chain (after CMake generate), I get the following error. What do I need to change in my configuration?
'X11/Xlocale.h' file not found
# include <X11/Xlocale.h>
^~~~~~~~~~~~~~~
1 error generated.
I'm doing this on Linux.
$ uname -a
Linux bracket 4.10.0-37-generic #41-Ubuntu SMP Fri Oct 6 20:20:37 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
I've confirmed I have libx-dev installed.
$ sudo apt-get install libx11-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libx11-dev is already the newest version (2:1.6.4-3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Emscripten can't use native libraries -- it's outputting Javascript code, after all; it can't use libraries which contain native x86 (or other architecture) code. As such, emscripten won't search for headers in your system's include directories, because a lot of those headers will describe functionality which isn't available to an Emscripten program. It uses internal search paths instead.
Now, <X11/Xlocale.h> is a bit of a weird header. It doesn't actually define anything; it just includes <locale.h>, so you may be able to get away with replacing #include <X11/Xlocale.h> with #include <locale.h>. However, if your application uses other X11 functionality, it may not be buildable under Emscripten.
As titled, is binutils contained in gcc for Centos Linux?
If I install gcc rpm package, is there need to install binutils also?
What's more, are gcc and g++ both installed by default in Centos?
The gcc package probably contains the compiler proper, e.g. files /usr/bin/gcc and directory /usr/lib/gcc/x86_64-linux-gnu/4.8/ (which contains the cc1 executable).
The /usr/bin/gcc program starts cc1 (or cc1plus etc...) to compile your source code *.c, and also as to translate cc1-generated assembly code (produced by cc1) into object file *.o, and at last ld to link.
Compile once with gcc -v to understand what is happening, it would show the really executed binaries. Notice that gcc is only a driving program (starting other executables like cc1, as, ld ...)
The as and ld programs are provided by binutils -which is needed to compile.
So the binutils package is a required dependency for the gcc package (with many other dependencies, probably including libc and libc-devel, but if you really want you could use some other libc like MUSL libc; the libc is generally providing the dynamic linker like /lib/ld-linux.so*).
Learn how to use rpm (on Centos, or dpkg on Ubuntu & Debian) to query the dependencies between packages.
For development you probably want some other packages. Debian has the build-essential virtual package. Probably CentOS has an equivalent. And you'll surely want to use some libraries (and you want the development packages for them, e.g. on Debian libcurl4-gnutls-dev to develop with the libcurl HTTP client library). See also this answer (for Ubuntu and Debian, but you can adapt it for CentOS).
In 2021 you want to use GCC 10 at least, as g++ -Wall -Wextra -g and you could decide to code your own GCC plugin (checking some coding rules in your C++ code; you also want to document your coding conventions by writing). Be aware of the rule of five.
I've downloaded MinGW with mingw-get-inst, and now I've noticed that it cannot compile for x64.
So is there any 32-bit binary version of the MinGW compiler that can both compile for 32-bit Windows and also for 64-bit Windows?
I don't want a 64-bit version that can generate 32-bit code, since I want the compiler to also run on 32-bit Windows, and I'm only looking for precompiled binaries here, not source files, since I've spent countless hours compiling GCC and failing, and I've given up for a while. :(
AFAIK mingw targets either 32 bit windows or 64 bit windows, but not both, so you would need two installs. And the latter is still considered beta.
For you what you want is either mingw-w64-bin_i686-mingw or mingw-w64-bin_i686-cygwin if you want to compile for windows 64. For win32, just use what you get with mingw-get-inst.
See http://sourceforge.net/apps/trac/mingw-w64/wiki/download%20filename%20structure for an explanation of file names.
I realize this is an old question. However it's linked to the many times the question has been repeated.
I have found, after lots of research that, by now, years later, both compilers are commonly installed by default when installing mingw from your repository (i.e. synaptic).
You can check and verify by running Linux's locate command:
$ locate -r "mingw32.*[cg]++$"
On my Ubuntu (13.10) install I have by default the following compilers to choose from... found by issuing the locate command.
/usr/bin/amd64-mingw32msvc-c++
/usr/bin/amd64-mingw32msvc-g++
/usr/bin/i586-mingw32msvc-c++
/usr/bin/i586-mingw32msvc-g++
/usr/bin/i686-w64-mingw32-c++
/usr/bin/i686-w64-mingw32-g++
/usr/bin/x86_64-w64-mingw32-c++
/usr/bin/x86_64-w64-mingw32-g++
Finally, the least you'd have to do on many systems is run:
$ sudo apt-get install gcc-mingw32
I hope the many links to this page can spare a lot of programmers some search time.
for you situation, you can download multilib (include lib32 and lib64) version for Mingw64:
Multilib Toolchains(Targetting Win32 and Win64)
By default it is compiled for 64bit.You can add -m32 flag to compile for 32bit program.
But sadly,no gdb provided,you ought to add it manually.
Because according to mingw-64's todo list, gcc multilib version is done,but gdb
multilib version is still in progress,you could use it maybe in the future.
Support of multilib build in configure and in gcc. Parts are already present in gcc's 4.5 version by using target triplet -w64-mingw32.
gdb -- Native support is present, but some features like multi-arch support (debugging 32-bit and 64-bit by one gdb) are still missing features.
mingw-64-todo-list
I'd like to build the latest version of gcc on a mac. I have the latest xcode but I'm looking for some of the c++0x features that are in more recent versions (the lambda functions, etc).
Are there any good step-by-step tutorials on doing this?
You should look at the Homebrew project.
Homebrew allows you to do things like this:
brew install gcc
Mac homebrew installation instructions are available here.
Add GCC support to a fresh Xcode 4.2 installation using this homebrew formula:
brew install https://raw.github.com/Homebrew/homebrew-dupes/master/apple-gcc42.rb
Upgrading from Xcode 4.1 doesn't drop existing GCC support, so this formula is only useful if you're working with a fresh 4.2+ installation.
One option is to install MacPorts and install the gcc46 package:
sudo port install gcc46
Another option is to download the source code and build it as follows:
tar xzvf gcc-4.6.0.tar.gz
cd gcc-4.6.0
./configure
make
Note that GCC 4.6.0 requires as prerequisites GMP 4.2+, MPFR 2.3.1+, and MPC 0.8.0+. If ./configure fails, it's probably because you're missing one of these (though it should give you a helpful error message in any case).
Building will take a while—likely several hours, depending on your hardware.
I would suggest building it yourself (Adam details how to do so). This will give you fine control on where to install and all the options you want to select. My experience from having multiple versions of gcc is that, if care is not taken apple's version of gcc can be damaged.
To speed up gcc installation you might want to look at --enable-languages option. If there are languages you don't need installed with the new gcc then you may not want to select them.