Rtems 4.9: Error: Requires: libgmp.so.3()(64bit)

[Ralf Corsepius]

On 03/18/2013 01:54 AM, Chris Johns wrote:
> Ralf Corsepius wrote:
>> On 03/16/2013 02:48 PM, Joel Sherrill wrote:
>>> Ralf your perspective is from that of a tool packager.
>>
>> No. A product (here: RTEMS-4.9) which hasn't received bug fixes/back
>> ports of despite there are known bugs, is dead.
>
> I do not think anyone is suggesting you start a new development with
> RTEMS 4.9. This is about long term maintenance of systems that are using
> RTEMS 4.9.
>
>>
>> Also, the packages, the rtems-4.9 toolchains are based on have been
>> discontinued upstream long time ago, read: they are dead.
>>
>
> I am not sure what you mean by "the packages".


newlib-1.16.0
gcc-4.3.x
binutils-2.19.x
gdb-6.8.x
autoconf-2.62
automake-1.10

have all been discontinued by their upstreams will not receive any 
upstream support.

  Upgrading them to newer upstream versions is hardly an option, because 
there exist many incompatibilities to which are likely to break 
building/using RTEMS-4.9.

  Of those OSes, which have been current at the time RTEMS-4.9 was 
current, only CentOS5/6 are still actively support by their upsteams. 
All others have been discontinued. Whether building these toolchains for 
newer OSes from source is still possible, is mere luck. It will be 
possible for some but not for all.

>>> It may no longer be of interest to you and not worth your trouble but
>>> it isn't dead. This is a case where building one's own tools from
>>> source is a viable option.
>> No.
>>
>> It's one of the cases, where people who already are using it, need to
>> fall back to a stand-alone long term inhouse support strategy.
>
> This is often not a viable solution due to verification and validation
> procedures.
I need to disagree. IMO, it is the only viable option.

I mean, if a developer launched a product using rtems-4.9 years ago and 
are still supporting it, the developer need to have an in-house plan to 
cope with this situation.

One way is to resort to a frozen a development environment/machine.

Another one is to "enter the development train" and to follow the 
"development train" - You've had plenty of time for it ;)

One short-cut escape, I indirectly offer to users through the 
rpm-packages is to switch to "using CentOS5/6".

>>> There may be future 4.9 releases.
>> This would seem unreasonable to me. Just announce it "discontinued and
>> dead", be done with it, and concentrate on the new versions.
>
> This is a view I do not support and I do not see the RTEMS Project
> supporting either. I know Joel does not support this view.
I know, you and Joel repeatedly pronounced this opinion.

However, I consider this to be unrealistic and wishful marketing, 
because the RTEMS project does not have the resources to cope with it 
(IMO, the "hiatus" RTEMS-4.9 is in is a symptom of this fact).

So instead of telling people RTEMS-4.9 was supported (which I consider 
to be untrue for years), I prefer clear, published cut-offs and clear EOLs.

>>  > But the number of hosts with prebuilt tools is in decline.
>> You are missing the point: The world is moving on.
>>
>
> Not everyone is able to view the world this way. When you enter a major
> development with a long life time you know, expect and hope the world
> moves on, how-ever you also know in time your new development will be
> left behind.
Exactly. therefore you need to be prepared for this.

> Good engineering practice requires you do what you can to
> aid and insulate the development environment from changes that may appear.
Exactly - This is one option (c.f. above).

>> The older toolchains gradually are becoming unbuildable on modern OSes.
>> They fail to build, because newer tools reveal and abort upon bugs
>> latented bugs, they fail to build because modern tools behave
>> differently and they fail to build because OSes are changing in general.
>
> Yes this happens and sometimes patches are needed to get an older tool
> chain to build on a newer operating system. The results of the changes
> can be evaluated and if code generation is effected choices can be made
> on how to resolve it.
Yes. But resources are finite, so you can not avoid to cut off support 
somewhere, sometime. It's an illusion and self-cheat to believe a small 
group or isolated individuals are able to cope with the "big pictures ad 
infinitum".

It's only a matter of time until people will be reaching their limits 
and will not be able to avoid introducing "cut-offs".

Back to OP's issue: Porting the rtems-4.9 toolchains to current Fedoras 
is likely possible without too much effort, but it means effort and 
would have to be done (== claims resources). So far, nobody has done 
this work and I am asking for the sense in it - IMO, it's not worth it 
and a waste of time.

Ralf