Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Sun, Jan 11, 2009 at 11:35 PM, Sam Ravnborg wrote: >> There are several other packages which are broken for embedded >> architectures, which I will hopefully attempt to fix by submitting patches >> upstream. But this is why we should be cautious about including new tools >> for compiling the kernel. Sam Ravnborg was correct in that a C program to do >> the work would be the proper way. But by not addressing a currently existing >> problem with an adequate replacement with something that does not exist >> currently, seems faulty. > > Why are "make headers_install" such a crucial thing for your > embedded environmnet? Sanity check. If the environment cannot replicate itself, then something has been faulty in the cross-compiling stage, that was used to propagate a native environment for the target architecture. > I would assume that if this of such improtance then there is also > someone to step up and contribute a C version of it. You've already dismissed a shell version to correct the issue, in hopes of a "possible" C version. It would be nice, I'm not capable of doing it personally, but a solution already exists to "unbreak" the kernel build. If you're unwilling to merge the current patches, then feel free to claim that this doesn't break anything on current architectures, but it's incorrect, due to Perl not even compiling as is currently on a native uclibc environment. I look forward to what other tools will be introduced to break yet more architectures until the kernel cannot be compiled unless on an i686+glibc architecture. >Sam -- Mark A. Miller m...@mirell.org -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
> There are several other packages which are broken for embedded > architectures, which I will hopefully attempt to fix by submitting patches > upstream. But this is why we should be cautious about including new tools > for compiling the kernel. Sam Ravnborg was correct in that a C program to do > the work would be the proper way. But by not addressing a currently existing > problem with an adequate replacement with something that does not exist > currently, seems faulty. Why are "make headers_install" such a crucial thing for your embedded environmnet? I would assume that if this of such improtance then there is also someone to step up and contribute a C version of it. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Sun, Jan 11, 2009 at 11:11 PM, H. Peter Anvin wrote:
> 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...
>>
>
> The latest stable Perl is 5.10.0, and the latest of the 5.8 series is 5.8.9.
>
>-hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. I don't speak on their behalf.
My mistake. However,
http://perl5.git.perl.org/perl.git/blob_plain/HEAD:/hints/linux.sh
still has the issue, specifically:
if test -L /lib/libc.so.6; then
libc=`ls -l /lib/libc.so.6 | awk '{print $NF}'`
libc=/lib/$libc
fi
So, my version was incorrect, yet the problem still exists. I've got a
patch, need to submit it, yet Perl *does not compile* on a uclibc
target *as is*.
And this is why we should avoid adding new tools to build the kernel,
because they introduce yet more break points, as such.
Thanks.
--
Mark A. Miller
m...@mirell.org
"My greatest strength, I guess it would be my humility. My greatest
weakness, it's possible that I'm a little too awesome" - Barack Obama
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
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... > The latest stable Perl is 5.10.0, and the latest of the 5.8 series is 5.8.9. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Sun, Jan 11, 2009 at 6:45 AM, Bernd Petrovitsch wrote: > > On Son, 2009-01-04 at 11:23 +0100, Leon Woestenberg wrote: > [...] > > On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt wrote: > [...] > > I'm ignoring the "cross-compile perl" issue - haven't tried it for > years. > > > 5. Tool *version* dependency is hard to get right. When cross-building > > 30 software packages all requiring native perl, we probably need to > > build a few versions of perl (native), one for each set of packages. > > perl is IMHO special (and quite different to others - including > especially autotools): perl5 is used widely enough so that "one somewhat > recent version" should cover all of 30 software packages. > The hard part are the CPAN modules and their versions which are really a > PITA. > As long as you don't use modules from CPAN, "perl5" should be specific > enough. > >Bernd > -- > Firmix Software GmbH http://www.firmix.at/ > mobil: +43 664 4416156 fax: +43 1 7890849-55 > Embedded Linux Development and Services 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. So without patching Perl, by adding it to the kernel configuration, it's broken being able to compile the kernel on most embedded architectures. And for H. Peter Anvin, before you refer to such uses as compiling the kernel under a native environment as a "piece of art", please be aware that the mainstream embedded development environment, buildroot, is also attempting to utilize QEMU for a "sanity check" on the environment. There are several other packages which are broken for embedded architectures, which I will hopefully attempt to fix by submitting patches upstream. But this is why we should be cautious about including new tools for compiling the kernel. Sam Ravnborg was correct in that a C program to do the work would be the proper way. But by not addressing a currently existing problem with an adequate replacement with something that does not exist currently, seems faulty. -- Mark A. Miller m...@mirell.org -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Son, 2009-01-04 at 11:23 +0100, Leon Woestenberg wrote: [...] > On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt wrote: [...] I'm ignoring the "cross-compile perl" issue - haven't tried it for years. > 5. Tool *version* dependency is hard to get right. When cross-building > 30 software packages all requiring native perl, we probably need to > build a few versions of perl (native), one for each set of packages. perl is IMHO special (and quite different to others - including especially autotools): perl5 is used widely enough so that "one somewhat recent version" should cover all of 30 software packages. The hard part are the CPAN modules and their versions which are really a PITA. As long as you don't use modules from CPAN, "perl5" should be specific enough. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
