Re: Building RedBoot for SH3 targets with new toolchain

[John Dallaway <john@dallaway.org.uk>]

Hi Bart

Bart Veer wrote:

>>>>>> "John" == John Dallaway <john@dallaway.org.uk> writes:
> 
>     John> Hi Andrew
>     John> Andrew Lunn wrote:
> 
>     >>> Taking all these things into account, plus the desire to avoid
>     >>> further delays to the eCos 3.0 release, I think it preferable
>     >>> to stick with the stock mpfr and gmp DLLs for the
>     >>> Cygwin-hosted toolchains. We must document the need to install
>     >>> the relevant Cygwin packages though, and add an entry to the
>     >>> FAQ.
>     >> 
>     >> Would it be possible to detect at build time if these DLLs are
>     >> installed? But a custom build rule with the highest priority in
>     >> infra, or HAL which will test if this files exist and stop and
>     >> print an useful error message if they are not installed?
>     >> 
>     >> The way cygwin is silently failing is not nice...
> 
>     John> The failure mode is certainly not nice. I expect that the
>     John> mpfr and gmp DLLs are loaded explicitly by the compiler
>     John> using LoadLibrary() and failure is not being reported at the
>     John> application level.
> 
>     John> We could emit a _warning_ message using a custom rule. An
>     John> _error_ message would be too strong since older toolchains
>     John> do not use mpfr and gmp. However, it seems cleaner to keep
>     John> such testing out of the build process and perform the tests
>     John> in the eCos install script instead when the relevant
>     John> toolchains are being installed. Having said that, I
>     John> appreciate that experienced eCos developers may not use the
>     John> install script.
> 
> Just how much does it save to link mpfr and gmp dynamically instead of
> statically? Ditto for intl and iconv?

I cannot quantify the size and performance savings without
experimentation, but I do know that using the DLLs is the right approach
for Windows hosts. If GCC is using LoadLibrary() for the mpfr and gmp
DLLs then the correct fix would be to patch GCC to report the failure.
However, tying such a fix (and the preceding investigation) to the
forthcoming release would not be appropriate at this stage in the
release cycle. Lets keep focussed on the remaining critical issues for
eCos 3.0.

John Dallaway