Building Tools From Source

[Pierre Ficheux]

This (simple) way works too, i.e. adding symlinks to gmp/mpc/mpfr in gcc sources :

$ tar xvf <PATH>/gmp-4.3.2.tar.bz2
$ tar xvf <PATH>/mpc-0.8.1.tar.gz
$ tar xvf <PATH>/mpfr-2.4.2.tar.bz2

...

$ cd gcc-x.y.z
$ ln -s ../gmp-4.3.2 gmp
$ ln -s ../mpc-0.8.1 mpc
$ ln -s ../mpfr-2.4.2 mpfr

Check-out  http://gcc.gnu.org/install/download.html.

regards

----- Mail original -----
> De: "Cassio Binkowski" <cassioiks at gmail.com>
> À: "Gedare Bloom" <gedare at rtems.org>
> Cc: rtems-users at rtems.org, "Ralf Corsepius" <ralf.corsepius at rtems.org>
> Envoyé: Mardi 25 Septembre 2012 18:26:15
> Objet: Re: Building Tools From Source
> 
> 
> Dear all
> 
> 
> Just to let everyone know the outcome of this.
> I was able to build GCC successfully. When I saw that MPC, GMP and
> MPFR were being built for i386, and GCC was trying to build for
> X86_64, I realized something was wrong.
> 
> 
> Steps:
> 1) Uninstalled MPC, GMP and MPFR and did a CONFIGURE for them again,
> just this time I specified the TARGET, which was PowerPC.
> 
> 
> 2) Checked the architecture for which the LIBs of each of these tools
> were built for (in MacOS, the command was FILE <name of the lib>),
> and it reported to have been built for x86_64. They are usually
> located at /usr/local/lib , unless a PREFIX is specified.
> 
> 
> 3) Ran the CONFIGURE file for GCC again and it worked just fine!
> 
> 
> A suggestion I have is to update the information located in the
> following links to contain some information regarding these tools
> (GMP, MPC, MPFR):
> 
> 
>     * http://wiki.rtems.org/wiki/index.php/Building_Tools
>     *
>     http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.10.2/share/rtems/html/started/started00030.html
> 
> 
> 
> Best regards
> cassio
> 
> 
> On Tue, Sep 25, 2012 at 11:00 AM, Gedare Bloom < gedare at rtems.org >
> wrote:
> 
> 
> 
> 
> On Tue, Sep 25, 2012 at 8:06 AM, Ralf Corsepius
> < ralf.corsepius at rtems.org > wrote:
> > On 09/21/2012 11:31 AM, Chris Johns wrote:
> >> 
> >> Ralf Corsepius wrote:
> > 
> > 
> >>>>> I don't know if Apple or a trustworthy 3rd
> >>>>> party supplies binaries for gmp, mpfr, mpc on MacOS (I would be
> >>>>> surprised if this does not apply), you're likely better off
> >>>>> using these
> >>>>> libraries and to apply shared linkage and not to use your
> >>>>> "homegrown"
> >>>>> static versions.
> >>>> 
> >>>> 
> >>>> I have no idea what Apple provide on MacOS, or what is provided
> >>>> on
> >>>> FreeBSD (I use both) nor do I need to be concerned.
> >>> 
> >>> 
> >>> Well, that's the difference in your way of thinking and mine.
> >>> 
> >>> I trust more in OS vendors' dedicated package maintainers who are
> >>> supposed to be deeply familiar with packages and supposed to take
> >>> more
> >>> care about packages, than I ever could myself.
> >>> 
> >> 
> >> Yes agree for the host OS.
> > 
> > The libgmp, libmpfr, libmpc etc. this threat started with are host
> > libraries, a host's GCC uses underneath.
> > 
> > As all of them undergo continuous upstream + OS-vendor development
> > and
> > bug-fixing it's not necessarily advisable to statically link
> > against them.
> > 
> > [To oversimplyfy: Code generation bugs can easily originate from
> > inside your
> > host's libgmp, libmpfr, libmpc etc. and may already be fixed in
> > later
> > OS-vendor versions of these.]
> > 
> > 
> >> I hope that the tools we release are tested
> >> and stable. I am only talking about gcc and the dependent
> >> libraries it
> >> now includes and making sure these do not vary even if the OS
> >> vendor has
> >> decided they need to for reasons specific to the host os.
> > 
> > The latter is a lost fight, because these libraries also
> > occasionally suffer
> > from bugs.
> > 
> > I.e. when statically linking you are making a choice towards
> > "reproducability/staying bugward-compatible", while when
> > dynamically you are
> > making a choice towards "correctness" and against
> > "reproducability".
> > 
> Exactly. Sometimes reproducability trumps correctness.
> 
> 
> 
> > Ralf
> > 
> > 
> > _______________________________________________
> > rtems-users mailing list
> > rtems-users at rtems.org
> > http://www.rtems.org/mailman/listinfo/rtems-users
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
> 
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>