Hi DS, > You're also correct about the possible namespace clashes, although > I didn't have the problem yet since I keep the FC toolchain in a > specific location, distinct from /usr and /usr/local.
Right now I also install it in its own ad hoc location, but I was thinking that if we are going to produce deb/rpm/etc packages that install our toolchain system-wide, we would be less polluting with an arm7-elf- prefix rather than the current arm-elf. > Since we are recreating a toolchain, it might be useful to update > to a newer binutils and esp. gcc, although this might break the > current build and require a lot of cleanup of TI's old code. Ahmm, I *really* don't feel like moving to newer gcc or binutils - if it ain't broke, don't fix it. I don't like the philosophy of endless updates and constantly chasing the latest and greatest - instead I like long-term stable software, sw whose life cycle is comparable to the average life expectancy of a Homo sapiens, i.e., sw that can last the lifetime of its users. > I don't know much about Debian packaging TBH (in the rare cases I > need to recompile a package, I use the standard dpkg-buildpackage). > Maybe a simple tgz that uncompresses, say to /usr/local, would > provide a generic solution suitable for all distros? We'd just > have to build it with an old enough distro (say Debian 6), to avoid > the problem of newer glibc that ship with new symbols, making any > compiled binary incompatible with older versions. I feel that making debs and rpms would be much more attractive and better received by the user base, but we don't have to address it right now - I would like to make the transition to a leaner sans- newlib arm7-elf toolchain first anyway, and making this GNU ARM7 toolchain more easily accessible to a wider base of users/developers won't really become a pressing concern until we get back to our gcc-built gsm-fw: for as long as we are working with TCS211-based hacks, the main fw is compiled with the Windows env anyway, making the GNU ARM7 toolchain irrelevant. And we do have an fc-host-tools release out with prebuilt loadagent and compalstage - these target code pieces are very stable and very unlikely to need changes. Speaking of which, having deb and rpm packages of fc-host-tools sounds like a good idea as well. M~ _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
