Marian Such wrote:
My idea was to provide pre-built package installer (.pkg) and maybe
fink/macports packages.
Someone years ago add packages to macports that where broken and now
years later are completely useless. I attempted to get them removed to
avoid us getting bug reports however the macports people refused. If
this is the quality of ports in macports I would prefer not to use them
and do not. I am sure some packages are well maintained, it is a
question of which ones. The same happened with FreeBSD however we can
get those removed. Having these ports available is nice while someone
looks after them however they are become the projects problem when they
do not.
Do we need a specific clang build for each RTEMS architecture ?
First of all, clang currently supports only limited number of targets,
see [1]. My suggestion is to complete full build for 1 platform first
(x86 or ARM) and only after this focus on sparc and other platforms.
It's quite improbable that clang will ever support all platforms
supported by RTEMS, even though llvm has a nice list of supported
architectures [2].
When I looked at the bfin a couple of years ago it was not even close to
usable. Being listed and being usable are different. As you suggest x86
is a good base and then ARM.
Does clang handle the multilib configurations RTEMS needs ?
In past two years there have been substantial work done on supporting
multilib configurations but I have reasons to believe that it will not
be flawless. I would suggest we also consider using ellcc [3].
ELLCC is not something I would consider using. I prefer RTEMS be as
close to the clang sources and maintainers as possible. Also having a
single executable for all architectures has its draw backs and the GCC
model of a single executable per architecture has its advantages. It can
be difficult to get a single set of source that has all bugs fixed for
all architectures. The RSB allows each architecture to have different
source as well as specific patches. If you look in the RTEMS git repo
rtems-tools you will see the patches there.
Multilibs is very important and needs to be address before anything else.
Which backends are considered stable and worth looking at ?
LLVM only.
I was using the gcc term, which means architecture. As discussed x86 and
ARM.
There are efforts underway for the Cortex-A9. This is happening in the
xilinx-zynq bsps. This is a due core device so SMP is being worked on
here. FYI I have OpenOCD working with the A9.
Nice. What is the current status of Cortex-A9 support?
The Cortex-A9 is working. Getting 2 A9s operating in SMP is getting
close. We have some bugs related to design choices in RTEMS code that do
not work in SMP mode. These relate to task variables and disabling
preemption as a high level lock.
Yep, OS X is solid system to work with. I wish RTEMS would provide
binary tools packages for both OS X and Linux.
I prefer building from source.
I saw that some prebuilt
packages were worked on during GSoC 2008. If the community decides on
following up on this work, I will be happy to improve and automatize
Linux prebuilt versions too. From what I've gathered, there is noone
working on debian/ubuntu packages even though they are the most common
distributions.
The RTEMS project defines the tool set at the source level. You are most
welcome to build, test and host packaged tools for the community. Having
them hosted by the RTEMS is a different matter. That depends on you and
your commitment.
Chris
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
