On Mon, Jan 12, 2009 at 2:20 AM, Paul Mundt <lethal@xxxxxxxxxxxx> wrote: > On Sun, Jan 11, 2009 at 09:36:58PM -0600, Mark A. Miller wrote: >> Actually, something that has amused me during this discussion, is that >> right now, the latest stable Perl (5.8.8) does not compile correctly >> on a uclibc host, which is typically what you want for embedded >> systems, which is why you'd bother to cross compile. (Albeit I was >> doing this natively under QEMU with a gcc/uclibc toolchain). >> >> I'll have a patch submitted upstream shortly, but basically the >> hints/linux.sh assumes *obviously* you're linking to glibc. I've made >> that less libc dependent, looking for either glibc or uclibc. >> > There are plenty that ship with glibc, too. What you "want" for embedded > systems depends entirely on the application for the device, not general > hand-wavy assertions. We (Renesas) ship BSPs on both precisely because of > this reason, and eglibc will probably factor in at some point later on > too. > >> So without patching Perl, by adding it to the kernel configuration, >> it's broken being able to compile the kernel on most embedded >> architectures. >> > This again has nothing to do with the kernel and everything to do with > your distribution. I use perl on uclibc natively just fine, it is > possible there are patches that have not been merged upstream, but this > is again an entirely separate issue. > > You seem to be confusing the fact that people who build distributions and > people who use them are one and the same, whereas "most" embedded > developers are going to be using pre-built distributions provided with > their reference hardware, and locking it down during productization. The > fact you are doing a distribution aimed at embedded devices is nice, but > do not try to push off problems you run in to that have a reasonable > expectation of working everywhere else on to the kernel community as > something we ought to care about. > > If you need to use a different libc on your platform, yes, you will have > to update packages for this. This used to be true for gcc and other > packages as well, but those were all fixed over time. The fact perl still > stands out despite there being patches available is simply an indicator > that folks working in that area haven't been very proactive in getting > their changes merged upstream. Tough. > > This is now entirely off-topic and has nothing to do with the kernel any > more. Please take this to the uclibc or perl lists instead. > Paul: I initially wrote a rather details response to your e-mail. But instead, I shall quote a previous e-mail of yours: > I will repeat again that no one has provided a > _single_ reason for why they are unable to provide perl within their > constrained environment. Until that happens, this entire thread is a > joke. And I did so. And you have disregarded it. That makes me question the logic of your fervent vehemence against such "Perl is perhaps not a good idea in the kernel build infrastructure" people like myself. Thanks. -- Mark A. Miller mark@xxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
