On Fri, Apr 3, 2015 at 3:07 PM, Mark Wielaard <[email protected]> wrote: > On Fri, 2015-04-03 at 14:33 +0200, Jan Heylen wrote: >> Maybe I should have called it "embedded environment" instead of >> cross-compiled, >> So, if you point to native as a typical desktop/server environment, >> the 300K probably won't be a problem, but embedded it could be a >> problem. > > Yes, I can see that. We have 12 backends currently, and hopefully more > in the future. Those do add up. So it would be nice to have an option to > only build some specific ones [*]. Specifically the backends for the > native host or target system and any secondary arches supported. But > completely removing all backends isn't really an option. That will just > break various libraries and tools working on ELF files and DWARF data > for the native toolchain. I think any solution should at least make sure > that all the self-tests in the testsuite PASS. (And ideally SKIP those > tests that rely on files for arches for which the backend was disabled.)
Ok, I was thinking it would go into this direction. I'm willing to do the effort for this (as having the right backend installed could be useful one day indeed), should I even consider looking at the mjw/RH-DTS branch? Or how do you propose I could tackle this? Jan > > Cheers, > > Mark > > [*] There is a kludge on the mjw/RH-DTS branch to build only some > specific backends statically. But I also don't think that is a nice > general solution.
