[ ] Migrate .config and build.log into per-target directory, make top-level file into symlinks - this will allow to compare/debug multiple configs side-by-side without overwriting each other
[ ] mirror: remove crosstool-ng.org mirroring of archives? Use the option only for local mirrors? Archives currently hosted are outdated.
[ ] old mingw-w64 fails to build (with new gcc?) - the headers are installed into usr/x86_64-w64-mingw32/x86_64-w64-mingw32/include instead of usr/x86_64-w64-mingw32/include
[ ] Set up 3 testing VMs: plain (using clang), using default 'gcc', using 'gcc6'
[ ] GDB7.1 build fails on macOS
[ ] need 'cpp' in the list of symlinked tools
[ ] still fails at link due to multiple definitions of BC/UP/PC
[ ] mingw.sh: create a hook for "pre-checks" for all libcs
[ ] move CT_DoMultilibList to this new hook?
[ ] go over all config options and evaluate their applicability to cross/canadian/cross-native (i.e. WANTS_STATIC_LINK does not have to test build's support for static link)
[ ] Update "Internals" chapter in the docs to match current state
[ ] Integrate openrisc support
[ ] Re-enable shared libraries - can it be done without wrapper scripts, e.g. via rpath?
[ ] Install a "trap" C++ compiler as ${CT_TARGET}-g++ during core compiler build to trap attempts to compile target code with g++ (currently glibc detects host g++ and warns that it uses g++ w/o target triplet)
[ ] Somehow it needs to be functional during the configure step - export env var while running in CT_DoExecLog with CFG level, and forward it to host compiler?
[ ] elf2flt not compatible with multiple linkers enabled in binutils (ld.bfd + ld.gold) - fix upstream?
[ ] Companion libs
[ ] Group options into submenus
[ ] Allow building [companion] target libs (and tools, like gdbserver or native gdb or strace) for all multilibs
[ ] Install companion libs into a multi-os-directory for the default multilib
[ ] Perhaps remove the distinction between multi_os_dir/multi_os_dir_gcc and use gcc-reported dir always, and rely on "demultilib" to combine them if possible
[ ] Check for python-devel to enable cross-gdb python bindings
[ ] Common location for sources provided by ctng - duma.in, gdbinit.in, uclibc{,-ng}-config.in ...
[ ] CTNG_LD_IS=bfd has no effect on subsequent build steps, as each step runs in its own environment
[ ] Disallow libc selections that cannot handle the arch (e.g. aarch64-*-uclibc, aarch64-*-musl, ...)
[ ] Support removal of .build/<TARGET>/build after each step (to save space while compiling in a VM; and to test restartability - since this directory is lost after restart)
[ ] Configure enhancements
[ ] What is --host= in ct-ng's configure used for? should it set the default canadian cross?
[ ] CFLAGS/LDFLAGS from configure should probably be added into default build flags
[ ] Move tool checks from configure to runtime (i.e. if xz was installed after crosstool-ng, it should be usable)
[ ] Check for companion libs and allow using host's libraries for native/cross (need to check if the host has them) - but allow them to be selected for build
[ ] Merge aggregator scripts like cc.sh, debug.sh etc
[ ] #534 Merge gcc backends in 100-gcc.sh
[ ] Currently some options (e.g. plugins) are not supported in core backend, hence aren't available on baremetal configurations
[ ] Install a single lib/ directory with all the stuff needed - scripts, makefile fragments, etc
[ ] Separate maintainer's scripts from the scripts used by crosstool-ng itself
[ ] Commit testing.py to the new maintainer's dir
[ ] Add an ability to do a single run of testing.py? or just use build-all, when the branch for separate canadian install is done
[ ] Extensibility to allow custom kernel headers and/or libc
[ ] Support elfkickers
[ ] Make cross-native toolchain non-experimental
[ ] Rework dependency order to suit xnative toolchain too
[ ] Make native/cross-native toolchain non-experimental
[ ] Pick up libc from host for native
[ ] Optimize steps to not require simple-cross for cross-native
[ ] Make supplemental commands like show-config leave .config and .build alone
[ ] Test populate script
[ ] 3rd party extensions to GCC
[ ] GHDL seems to be active and supports GCC6
[ ] COBOL? Cannot find which GCC version they need [http://cobolforgcc.sourceforge.net/]
[ ] At the very least they have an awesome guide to GCC internals: http://cobolforgcc.sourceforge.net/cobol_14.html; might just as well reference it in our docs
[ ] Modula-2 supports GCC 4.7 as the latest
[ ] Resurrect GCC4.7?
[ ] readelf: DWARF parser does not handle DW_CFA_remember_state/DW_CFA_restore_state