Why could GCC find the libraries for GMP, and MPFR, but not for the MPC?
 

I am trying a build gcc on my Mac it is an intel Mac. I do have these libraries "GMP, MPFR, and MPC", the libraries are here, so it is usr/local/lib for the libraries and the headers are here usr/local/include. I also successfully compiled and install gmp and mpfr accept the mpc for some reason it is not locating.

gcc error:

configure: error: Building GCC requires GMP 4.2+, MPFR 3.1.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 https://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.

Mpc error:

configure: error: gmp.h cannot be found or is unusable.

You should have directories /usr/src/gcc-x.y /usr/src/gcc-x.y-build. Use option not to build gcc in the "virtual" (build) directory. There are allot of options it's almost like having a secret key finding all the right things (to a beginner).

You need to read gcc/doc/gccinstall.info

You need to read: sh /usr/src/gcc-build/configure --help

You can read the configure script it will have there exactly what is used to detect. (for some apps these are hidden in .m4 but gcc is plain enough)

FINALLY: You said other libs are found not mpc. Perhaps it was found but the version is too old. You need to read "configure.log" in /usr/local/gcc-x,y-build after you run it - it will say if mpc was found but not great enough version.

Apple ships LLVM. Unsure why you are trying to add GCC since many are forcing use of LLVM these days. That may change. But I think if you don't know how to compile GCC you may not need it, unless you are trying to do some embedded non-cellphone thing that works only on gcc.

You have xcode with options installed don't you? Excellent development environment, that. (it installs LLVM)

Just run the download_prerequisites script in the contrib/ directory. It downloads all three right into the source tree.

I suggest NOT using contrib/gcc_build. it adds more questions/problems/configure-points than it _provides_.

I suggest NOT running contrib/gcc_update on an apple especially not if you have root permissions. it will want to "mess with configure.ac and m4" updating which there are 100 versions of. GCC is "not meant to be easily made from a configure.ac". It has many hacked makefiles that configure will not understand. The script is contrib it is NOT guaranteed to work and may cause massive problems building - unk. echo "Attempting to update a dirty hg tree!" >&2 buh bumb what??

I would ont run contrib/get_prerequisites. it has 13 options 11 of which can go wrong. Also you haven't confirmed you need to get prerequisites YET. (that was under discussion i thought). Adds more problems than it solves.

Easier to just click on the version you need in Safari, if infact that is your problem (not yet determined)

(P.S. GLIBC and GCC are infamous for out of date documents and scripts that don't work and build fails. Do not be surprised if you read gcc/doc/gccinstall and it says "X.Y or higher" and it's total bunk you need one version higher it turns out). Always works for redhat not as much for others. They must be wizards.

contrib/mark_spam.py sugg you read it, but you may need rustc llvm cmake to get it running right? gcc-12 phones home when you compile like many new RH "gnu" chain tools they are editing do. Just leave internet unplugged when you build linux from scratch. check.

The script to *checks* "mark PRs as spam" makes web service requests? To *checks* Bugzilla? Oh my god. How the hell else would you expect it to work?

I'm not seeing the problem here.

> Mpc error:
> configure: error: gmp.h cannot be found or is unusable.

SORRY. I did not see that before. Be sure to include the include/ directory where that was installed (if you find(1) it exists) in your CFLAGS and maybe CPPFLAGS CXXFLAGS

CFLAGS example: run from gcc-10.2.0-build/

env CFLAGS=' -I/usr/local/comp64/include -I/usr/local/comp64 /usr/include -I/usr/include ' ../gcc-10.2.0/configure $opts

(not everyone would agree that CFLAGS should determine the order of where "the real" includes are to be looked for - it is unusual - infact requires adjustment of some builds)

CLFAGS and -I can easily make a build go wrong. You have to have a CLEAN include/ directory (ie apple's LLVM one) first, and don't put include/ directories with trash (apps you've built). just leave those out.

if you compile crossing from 32bit to 64bit you may have to edit libstdc++-v3/configure and Makefile.in - it doesn't like doing it.

on my build of gcc-10 I have to use ar(1) to edit cp-demangle .o to get gcc working both 32 and 64 bit with .so, so be aware ;)

# to say gcc options are trying at times is a vast understatement
# i'm not sure except.c using SJLJ is "ok without dwarf2"
# note this hook always returns DW2|NONE, erasing any chance of SJLJ?
[ ! -f targhooks.c.old ] && {
cp targhooks.c targhooks.c.old
cat << EOF | ed || true
r targhooks.c
/^default_debug_unwind_info/
+1
.a

/* this may allow -gnocfi to allow some exceptions, idk */
if(flag_gnocfi)
return UI_SJLJ;

.
wq targhooks.c
EOF
}

THE FULL SCRIPT of my build adds a quirk option to gcc: to disable CFI intput/output entirely. I later found it did not cure the problem I had with older GLIBC. But the new option to gcc-10 works anyhow (on my machine only).

(CFI are gcc specific debug tags added to assembler level EVEN WHEN DEBUGGING IS NOT ON. problem is any code hacking assembler code without FULL flavor and version knowlege of CFI (which few or none have bug redhat debuggers), is broken by CFI)

So. Do you still want to compile GCC not download the binary or just use LLVM? Many get build fails. Good luck. Don't expect it to be easy. It isn't impossible. But many internet "howto" will lead to build fail I warn.

That is my point of raising all these marks about GCC building. If you aren't "really good at reading Makefile.in" it may not be something you wish to attempt.