Somebody claiming to be Daniel Bolgheroni wrote: > Here I propose the build of libstdc++-v3 as part of devel/arm-none-eabi. > Some ports do build it (e.g. devel/avr32), while others don't (e.g. > devel/arm-elf).
(The main reason arm-none-eabi doesn't build it is because I used arm-elf as a template.) > There was an effort to keep devel/arm-none-eabi the same, while trying > very hard to follow what was done in devel/avr32. gcc-linaro was split > in two. The first is gcc-linaro-bootstrap, used to build newlib, and > then gcc-linaro itself, with libstdc++-v3. One issue with separating out the bootstrap compiler (that's quite relevant on ARM, but I don't know enough about AVR32 to comment there) is that the newlib build uses the bootstrap GCC multilib configuration to configure itself, and the main GCC package expects newlib's multilib configuration to match its own. So anything that changes that (like my local patch that I need to clean up and get merged at some point) needs to be kept in sync between the two GCC variants. Would making the bootstrap compiler a flavour of the main one be reasonable? (I don't know enough about how flavours work to answer that question.) That should make it easier to keep patches and build configuration in sync. > I'm sending the entire port for review as a .tar.gz. I can't figure out > how to add new files to CVS and send them inline in the mailing list as > a diff. 'cvs add' and 'cvs rm' only affect local state, so you can run them against a read-only anonymous CVS server, and then 'cvs diff -N' will include the new or removed files. Now that I've managed to allocate time to build this, it builds a pile of code I have handy, which then runs happily on the target platform (as expected), but I don't have any C++ code to test the new functionality with. > Ideas? Suggestions? The Python files in /usr/local/share/gcc-4.9.3/python/libstdcxx conflict with g++-4.9.3; if there's a way to remove that conflict so that both packages (and other cross-targeted versions of g++ that have them) can be installed at the same time, it would make multi-platform devs' lives easier. arm-none-eabi-gcc-linaro has a runtime dependency (via newlib) on the bootstrap compiler; removing newlib's runtime dependency on the compiler might be a feasible way to remove to that. (That got pulled in from arm-elf without checking whether it was actually needed, and it looks like avr32 doesn't have it.) I expect that it will also need a revision bump, and a conflict marker if the Python file conflict can't be removed, before the committers will accept it. dave -- Dave Vandervies dj3va...@terse.ca / dj3va...@uwaterloo.ca Plan your future! Make God laugh!
