Building Tools From Source

[Chris Johns]

Ralf Corsepius 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.
>

It is RTEMS's GCC that is being discussed and not the host's GCC. I do 
not support the dependence of RTEMS's tools to the host's compiler. If 
the host provided versions of these libraries change then I assume the 
vendor has tested the effect on the hosts's gcc and on all the packages 
built by gcc the vendor provides. I do not expect the vendor of a Linux 
distribution to also test these changes against the specific versions, 
patches and architectures that are the RTEMS tools. I also do not expect 
the installation of updated versions of these packages to be blocked 
because RTEMS tools have been installed and require specific versions to 
maintain a specific configuration. It is the RTEMS project's 
responsibility to make sure the tools we provide are valid. If the RTEMS 
tools depend on host's versions of these libraries and they are updated 
I see a possibility of the RTEMS tools having an untested and invalid 
configuration.

> As all of them undergo continuous upstream + OS-vendor development and
> bug-fixing it's not necessarily advisable to statically link against them.

In the case of the host's C compiler (which we assume is gcc) this may 
be true and how a Linux distribution works. RTEMS has specific versions 
of tools that are set when a release is made. Varying the configuration 
of a user's tool set is questionable. The least we can do is inform the 
users of these packages this can happen and they can then make an 
informed choice.

>
> [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.]
>

Then the converse is also true and code generation maybe working due to 
some specific relationship with a specific version and changing that 
assumption breaks that relationship.

If a new version fixes a specific bug in released RTEMS tools then we 
need to raise a problem report, apply the fix, test the fix and then 
release an updated set of tools. If a newer version is available and it 
does not fix any known issue in the RTEMS tools then we should resist 
changing.

>> 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".
>

This is not specifically an issue of dynamically linking verses 
statically linking. It is about knowing the version and configuration of 
the tools used to build code. In my vocabulary "correctness" is knowing 
the exact configuration, being able to report that configuration in 
configuration controlled documents and being able to reproduce that 
configuration on demand. Therefore correctness is being able to 
reproduce what you developed, tested, released, and qualified. Anyone 
who has had to qualify equipment and then fix bugs years down the track 
will understand the issues here.

Configuration control can be achieved with your packages and a Fedora 
host controlling all the dependences as long as the host versions are 
the same as the RTEMS tools versions. If they vary you have a conflict 
that is more difficult to resolve than just using the correct versions 
for the RTEMS tools from the start.

Chris