Building Tools From Source

[Gedare Bloom]

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