Riku Voipio wrote:
Since maemo atleast already compiles some of their apps and libs with thumb code.
That is irrelevant. "Maemo is the application development platform for the Nokia 770 Internet Tablet" which runs something called "Internet Tablet OS 2006". We do not need to be able to install Nokia Tablet binaries into ARM Debian systems or vice versa, and they wouldn't work anyway. Anyway, your view (Riku) is coloured by the fact that you are trying to make the armel port with the emdebian people and your personal hobby-horse scratchbox, you already have a half-baked repository of "armel" binaries compiled for armv5t using the CodeSourcery compiler, and are in a hurry to get something (*anything!*) working as soon as possible for some reason. Sadly your haste has produced a repository of 147 random packages but no libc6 package (!). I don't see how it can work. libc comes first along with a working toolchain as I understand it, and everything else depends on libc. My question is about the ARM Debian distribution, not emdebian, and whether we can satisfy the specific Debian policy "Debian runs on as wide a range of hardware as possible" without wasting time and creating danger of bugs by modifying GCC just to support what seems to me to be a minor feature of very little value -->in the context of mainline Debian<--. emdebian devs and users will always have their own optimised repositories for their specific devices. ARM Debian for ARM is the Debian system compiled for ARM processors, not something special and different tailored for tiny systems and the latest cellphones. It should run the same as it does on all the other processors, and it should run the same on all the ARM processors that it can support, which is armv4 and above. The "armv4 thumb interwork compatability" trick is cute, but it requires getting armv4t instructions (BX) through GCC and the assembler while they are running in compile-for-armv4 mode among other difficulties. It's nice in theory but is still far from ideal, and I see trouble and brokenness forever down that path, while pure armv4 without thumb interworking will work faster on every processor. In fact, one way to make sure that the Debian does run properly on as many ARM CPUs as possible is to mandate armv4 and ban Thumb. Thumb also creates the risk of making packages that work on the dev system they're compiled on but don't work on half the ARM processors out there in the real world - something that seems to have happened already to the current ARM port (on armv4t, firefox bombs with "illegal instruction" on ARMv4t, and aptitude segfaults at random) Oh, and Paul, yes, I'm sure thumb and thumb2 are whizzo when people are compiling for a specific small device, which is what CS customers do on the whole, but my question remains "is Thumb compatibility really worth all the trouble and risk and bloat in the context of generic Debian?" I think not. M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
