Target-specific build failures [ was Re: eCos 3.0 beta 1 punch list #1 ]

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

Hi Bart and all

Bart Veer wrote:

>>>>>> "John" == John Dallaway <john@dallaway.org.uk> writes:
> 
>     John> b) CDL changes to split compiler warning flags out into a
>     John> separate CDL option. (bartv)
> 
> This is now complete. I have now finished in the hal/ directory, so I
> have no objection to people checking in more changes in there.

That's great news. Thank you.

> There are an awful lot of platforms which fail to build.
> 
> ARM
>    AEB, all SA1110: cxxsupp fails to link because of .gcc_except_table.

This on the punch list for jifl to investigate.

[ snip various build failures ]

Most of the failures you list are for old/obsolete targets that may no
longer be in use within the eCos community. While we could
systematically go through all these failures, I don't see this as a good
use of our time right now. We know that architectural support for the
main architectures is in good shape.

Everyone, if there are targets in the list that you care about, please
volunteer to fix as soon as possible.

> SH
>     All platforms fail to build cxxsupp

I have a patch for this issue.

> I have not tried anything with the calmrisc16, calmrisc32, coldfire,
> fr30, frv, h8300, mn10300, openrisc, sparc, sparclite or v85x targets.

The old "coldfire" HAL and associated target will not form part of the
release. The other architectures will simply not be tested (even for
build regressions) unless someone shows an interest in these targets.

> The synthetic target builds fine, but there is a run-time problem with
> cxxsupp. It appears that libgcc now assumes that glibc has done some
> initialization, setting up the %gs register to point at per-thread
> data. This came up previously in the context of the -fstack-protector
> flag, see the mailing list archives, but at the time we decided we
> could live with the problem. It looks like there are now more
> dependencies on getting this sorted - which I suspect will prove
> challenging.

We always seem to be playing catch up with gcc/glibc for the synthetic
target. If you have time to investigate the cxxsupp build failure then,
of course, feel free. However, I don't see this as a showstopper, at
least not for the beta release. We can always document the compatibility
issue in the README. For avoidance of doubt, please do finish off the
constructor priority re-work first so we can unfreeze the repository for
final check-ins and I can commence further sanity tests across the
entire repository. When do you envisage being able to check this in?

Jifl/Bart, could we limit the scope of the code freeze to those packages
that form part of the constructor priority re-work now?

John Dallaway