Re: mini-ct: configuring and building binutils

["Jonathan S. Shapiro" <shap at eros-os dot com>]

Robert:

We have been using a similarly "brute simple" approach for the Coyotos
cross tools. There are some issues that your approach will not cover.

1. Many of the Makefile.po fragments in the core CCS tools aren't done
right. I don't now recall if they mishandle sharedir or infodir, but we
have a list of patches to them to correct this. This isn't a problem for
*building* the cross tools, but it is definitely a problem for
installing them in the proper host directories.

For this reason, we find it necessary to maintain patch files to patch
the Makefile.po files, and we also find it necessary to override
--mandir and --sharedir in all of our cross-builds.

2. We do not currently set --host explicitly. Perhaps we should. We
don't disable NLS. Perhaps we should.

I'm sure that there are things wrong with how we handle all of this, but
you might want to look at our makefile structure. To do so, point a
browser at

  http://www.opencm.org/opencm/~/PUBLIC/coyotos/DEV/ccs-xenv/140

and look at Makefile.xenv, which in turn invokes Makefile.target.

Issues we *know* we have not got right:

  1. Installation of system headers. We aren't a POSIX platform, so
     this is a real nuisance.

  2. Handling of TLS. Our runtime support model is still in progress,
     so we haven't tried to deal with this yet.

  3. Missing libmudflap. I hit a build problem. Cannot recall what at
     the moment.

  4. Not building g++ -- libiberty issue that is mainly due to absence
     of system headers.

I'ld be interested in any other issues that might leap to your
attention.

We maintain a patch set, but it is surprisingly small. If you look in
the SOURCES subtree above, the patch files should be obvious. Most of
these were adapted from the existing cross tools distribution.

It helps us (a lot) that we are not even attempting to do an "all
versions, all interactions" build. We are happy to find a stable
compiler and update it only occasionally.

In practice, the biggest problem we have is newlib's lack of release
discipline. I'm on the newlib list, and I see patches almost every day
for something I care about. The implications of this are disturbing. In
practical terms, it suggests that:

  (1) The newlib development process may not have an adequate testing
      regime.

  (2) It is impossible to know when to take a snapshot of the CVS tree.

It is simply beyond our available time to rebuild our C library daily,
which is what the rate of newlib patches (especially for ARM and
Crossfire of late) seems to require.

The biggest patch in our tree is the one to go from the last newlib
release to the last CVS snapshot we grabbed.

shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC


--
For unsubscribe information see http://sourceware.org/lists.html#faq