Dear all<div><br></div><div>Just to let everyone know the outcome of this.</div><div>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.</div>
<div><br></div><div><b>Steps:</b></div><div><b>1) </b>Uninstalled MPC, GMP and MPFR and did a CONFIGURE for them again, just this time I specified the TARGET, which was PowerPC.</div><div><br></div><div><b>2)</b> 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 <i>/usr/local/lib</i>, unless a PREFIX is specified.</div>
<div><br></div><div><b>3)</b> Ran the CONFIGURE file for GCC again and it worked just fine!</div><div><br></div><div>A suggestion I have is to update the information located in the following links to contain some information regarding these tools (GMP, MPC, MPFR):</div>
<div><ul><li><a href="http://wiki.rtems.org/wiki/index.php/Building_Tools">http://wiki.rtems.org/wiki/index.php/Building_Tools</a></li><li><a href="http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.10.2/share/rtems/html/started/started00030.html">http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.10.2/share/rtems/html/started/started00030.html</a></li>
</ul><div><br></div></div><div>Best regards</div><div>cassio</div><div><br><div class="gmail_quote">On Tue, Sep 25, 2012 at 11:00 AM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>On Tue, Sep 25, 2012 at 8:06 AM, Ralf Corsepius<br>
<<a href="mailto:ralf.corsepius@rtems.org" target="_blank">ralf.corsepius@rtems.org</a>> wrote:<br>
> On 09/21/2012 11:31 AM, Chris Johns wrote:<br>
>><br>
>> Ralf Corsepius wrote:<br>
><br>
><br>
>>>>> I don't know if Apple or a trustworthy 3rd<br>
>>>>> party supplies binaries for gmp, mpfr, mpc on MacOS (I would be<br>
>>>>> surprised if this does not apply), you're likely better off using these<br>
>>>>> libraries and to apply shared linkage and not to use your "homegrown"<br>
>>>>> static versions.<br>
>>>><br>
>>>><br>
>>>> I have no idea what Apple provide on MacOS, or what is provided on<br>
>>>> FreeBSD (I use both) nor do I need to be concerned.<br>
>>><br>
>>><br>
>>> Well, that's the difference in your way of thinking and mine.<br>
>>><br>
>>> I trust more in OS vendors' dedicated package maintainers who are<br>
>>> supposed to be deeply familiar with packages and supposed to take more<br>
>>> care about packages, than I ever could myself.<br>
>>><br>
>><br>
>> Yes agree for the host OS.<br>
><br>
> The libgmp, libmpfr, libmpc etc. this threat started with are host<br>
> libraries, a host's GCC uses underneath.<br>
><br>
> As all of them undergo continuous upstream + OS-vendor development and<br>
> bug-fixing it's not necessarily advisable to statically link against them.<br>
><br>
> [To oversimplyfy: Code generation bugs can easily originate from inside your<br>
> host's libgmp, libmpfr, libmpc etc. and may already be fixed in later<br>
> OS-vendor versions of these.]<br>
><br>
><br>
>> I hope that the tools we release are tested<br>
>> and stable. I am only talking about gcc and the dependent libraries it<br>
>> now includes and making sure these do not vary even if the OS vendor has<br>
>> decided they need to for reasons specific to the host os.<br>
><br>
> The latter is a lost fight, because these libraries also occasionally suffer<br>
> from bugs.<br>
><br>
> I.e. when statically linking you are making a choice towards<br>
> "reproducability/staying bugward-compatible", while when dynamically you are<br>
> making a choice towards "correctness" and against "reproducability".<br>
><br>
</div></div>Exactly. Sometimes reproducability trumps correctness.<br>
<div><div><br>
> Ralf<br>
><br>
><br>
> _______________________________________________<br>
> rtems-users mailing list<br>
> <a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a><br>
> <a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
_______________________________________________<br>
rtems-users mailing list<br>
<a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
</div></div></blockquote></div><br></div>