Building Tools From Source

[Binkowski, Cassio]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20120925/77585804/attachment-0001.html>