This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |