RE: gmp/mpfr/macosx

[Jay <jayk123 at hotmail dot com>]

gmp/mpfr


1) varying ABIs due to configuration nor matching


I think there's a release note and/or I think I have noticed that
some of the config.guesses do not agree.
I think the release note was about Solaris.


Therefore it helps to specify the platform explicitly.
Run the config.guess yourself, pick the value you think is right, and then use it.


Under Cygwin for example, on Windows XP on AMD64:


  jay@jay-win9 ~
  $ /src/gcc/mpfr/config.guess
  i686-pc-cygwin


  jay@jay-win9 ~
  $ /src/gcc/gmp/config.guess
  athlon64-pc-cygwin    <=== mismatch



  jay@jay-win9 ~
  $ /src/gcc/config.guess
  i686-pc-cygwin


  so then instead of just running
  ./configure && make && make install


  do like


  ./configure i686-pc-cygwin && make && make install



ABI="32" sounds like another good option.


You might also try -disable-multilibs (no need for leading double dash,
I wonder if that is controversial?)


2) gcc configure not finding the gmp/mpfr you built/install


Yes I think I have seen this too.
It seems maybe gcc configure only looks in /usr but the default
for gmp/mpfr (and most else) is /usr/local.
I haven't debugged this further.


Easily worked around, but does seem wrong.



3) The requests to integrate gmp/mpfr into the gcc tree.


Well, if you extract the gmp/mpfr source into the gcc source,
gcc does know to just build its copy.


I've been working on some build automation, e.g.:


#
# FUTURE need to split notion of "package name" from "package version"
#
VersionGcc = "gcc-4.3.1"
VersionMpfr = "mpfr-2.3.1"
VersionGmp = "gmp-4.2.2"
VersionBinutils = "binutils-2.18"


#
# I have recoded my archives to tar+lzma = .tlz.
# Probe for .tar.gz, .tar.bz2, .tar.lzma, .tgz, .tbz, .tlz.
# Given gcc-1.2.3 we should also probe for gcc-1.23 and gcc123.
# We should also support .zip, and try to support the DJGPP names.
#
def Extract(Directory, File):
    #
    # Make these more portable by running bzcat, gzcat, etc. directly.
    #
    CreateDirectories(Directory);
    for ext in [".tar.gz", ".tgz"]:
        if os.path.exists(File + ext):
            return Run([None], Directory, "tar --strip-components=1 -zxf " + File + ext)


    for ext in [".tar.bz2", ".tbz"]:
        if os.path.exists(File + ext):
            return Run([None], Directory, "tar --strip-components=1 -jxf " + File + ext)


    for ext in [".tlz", ".tar.lzma"]:
        if os.path.exists(File + ext):
            return Run([None], Directory, "tar --strip-components=1 --lzma -xf " + File + ext)


    return Run([None], Directory, "tar tar --strip-components=1 -xf " + File)



#
# extract source -- note we carefully extract into a "combined" tree
#


EmptyDir(DoCleanSource, "/src/gcc")
if DoCleanSource:
    #
    # binutils must precede gcc so that gcc replaces common files
    #
    ExtractBinutils = Extract("/src/gcc", "/net/distfiles/" + VersionBinutils)
    ExtractGcc = Extract("/src/gcc", "/net/distfiles/" + VersionGcc)
    ExtractGmp = Extract("/src/gcc/gmp", "/net/distfiles/" + VersionGmp)
    ExtractMpfr = Extract("/src/gcc/mpfr", "/net/distfiles/" + VersionMpfr)


Notice that binutils is before gcc, so gcc will replace common files.
And that I use --strip-components=1.


You end up with


  /src/gcc/gas
  /src/gcc/ld
  /src/gcc/gcc
  /src/gcc/gmp
  /src/gcc/mpfr


etc. and can build/install it all in one fell swoop ./configure  && make && make install.


Note that binutils isn't particularly applicable on Mac OS X, I think.


While this is more "turnkey", I am not happy with it.
If you are building multiple toolsets, you end up building gmp and mpfr multiple times.
And they do take quite some time to build.


e.g. I am building cygwin native, cygwin-host to Solaris-target, and Cygwin-build to Solaris-host/target.
I end up with three gmp and mpfr instead of the requisite two.
I end up with countless libiberty.a instead of the requesitite two.
And at least three libbfd.a, libopcodes.a where I think again two is all that is needed, or maybe three.
 (I don't know if these are target specific or not.)


-enable-install-libiberty does not seem to help.
It doesn't even work unless you give a directory, contrary to documenation.
And nothing (among gcc/binutils) uses the installed one anyway.


-common-bfdlib I still need to look into. But I don't think it'll cut down the libiberties.
Probably best to build things manually and then copy/link around the outputs.


Perhaps if gmp/mpfr were integrated into gcc, they could be reduced to only what is needed
and maybe that'd save a bunch. I don't know.


 - Jay



--Forwarded Message Attachment--
From: danallen46@airwired.net


I too am having problems building an Intel gcc 4.3.1 on Mac OS X
10.5.4 on a standard iMac.  There are many issues.

--Forwarded Message Attachment--
From: nicholas.d.miller@mac.com
Subject: Re: problems compiling gcc under Max OS X

> error that gmp/mpfr  are not found... but I've built and installed them in the default

>> I really wish that these extra dependencies were not there.
>> Dan Allen