On Mon, Nov 05, 2012 at 03:39:17PM +0100, Loïc Minier wrote: > > still, i see the case at hand more as multi-lib thing than a multi-arch > > thing for pragmatic reasons: we can't expect to have a debian > > architecture dedicated to something that won't even run linux, can we? > > We have Debian architectures for kfreebsd and hurd, so why not? :-) i'm tempted to put it as "those chips won't run debian", but that was my idea before i had a look at emdebian, so: the chips i'm dealing with won't run a gcc, that's pretty sure. > Also, I believe Cortex-M can run linux with no-MMU patches/configs and > uclibc? it can indeed, though not on all of them. as wookey pointed out in irc, it's important to see why we should build such a library. the motivation is imo very simple: installing a development environment for arm should not be harder than doing the same for avr (there, `aptitude install arduino` sets you up everything from compiler to ide). what i can offer for discussion are the options i see: * package a arm-none-eabi gcc with its own libc. that's what gcc-avr (and probably gcc-m68hc1x and gcc-msp430) does. they have their own avr-libc too, with provides both standard libc features and platform specific features. that would be another source package from the gcc tarballs. * package a thumb libgcc.a completely independently. users would have to supply their own paths to the linker, link in the new libgcc, and add -nostdlib. that would either be another source package from the gcc tarballs (utilizing only what is needed to build libgcc.a) or a part of the regular (emdebian?) gcc package. for users, that would be pretty inconvenient, as they'd have to explicitly add include paths. * enable multilib on the gcc for arm (cross) compiler -- that's what i mentioned in my first message. a thumb variety of libgcc.a would go to a subdirectory of the libdir, and gcc would decide to use that based on compile flags (-mthumb). looking around in the database, i found that a gcc-4.7-multilib package is already built on amd64 (containing the /32/ subdirectory) and several other platforms (mips: n32, 64; powerpc and sparc: 64), but not on arm. might it be that this just needs enabling on arm? for multiarch+multilib+crosscompiler support, i assume that would mean that gcc-4.7-arm-linux-gnueabi:any would suggest gcc-4.7-multilib:armel, right? * use multiarch. that would mean creating a new :armthumb architecture that initially only contains a libc and a libopencm3 package. that'd be a thing that might even work for emdebian, but unless there are serious linux (or other debian) ports there, i doubt that will be taken well with the general debian community. even if so, i imagine the time frame for that to be longer than what i'd be willing to wait until i implement a workaround using the other options. i'd prefer to not have yet another package built from the gcc sources; that'd make all improvements contributed work everywhere. i'm completely leaving the libc discussion out of here for now. as i'm planning to use the debian default gcc for embedded development, i have to either accept the choice of eglibc, or add tweaks to whatever wants to use another one in its makefiles (uclibc or newlibc). i'm open to to suggestions on that topic, but i'd not focus on it right now. best regards chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
Attachment:
signature.asc
Description: Digital signature