Date:	Mon, 12 Jan 2009 03:18:53 -0600
From:	"Mark A. Miller" <mark@...ell.org>
To:	"Paul Mundt" <lethal@...ux-sh.org>,
	"Mark A. Miller" <mark@...ell.org>,
	"Bernd Petrovitsch" <bernd@...mix.at>,
	"Leon Woestenberg" <leon.woestenberg@...il.com>,
	"Rob Landley" <rob@...dley.net>, "H. Peter Anvin" <hpa@...or.com>,
	"Embedded Linux mailing list" <linux-embedded@...r.kernel.org>,
	linux-kernel@...r.kernel.org,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Sam Ravnborg" <sam@...nborg.org>
Subject: Re: PATCH [0/3]: Simplify the kernel build by removing perl.

On Mon, Jan 12, 2009 at 2:20 AM, Paul Mundt <lethal@...ux-sh.org> 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@...ell.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists