Pádraig Brady wrote:
The $(( ... )) construct is standard POSIX shell syntax, see
http://www.opengroup.org/onlinepubs/95399/utilities/xcu_chap02.html#tag_02_06_04
Bash supports $[ ... ] as an alternate syntax for the same thing.
Perhaps you were thinking of that.
I think the
Jamie Lokier ja...@shareable.org writes:
Pádraig Brady wrote:
The $(( ... )) construct is standard POSIX shell syntax, see
http://www.opengroup.org/onlinepubs/95399/utilities/xcu_chap02.html#tag_02_06_04
Bash supports $[ ... ] as an alternate syntax for the same thing.
Perhaps you
On Tuesday 13 January 2009 20:51:16 Jamie Lokier wrote:
Paul Mundt wrote:
This happens in a lot of places, like embedded gentoo ports, where almost
all of the work is sent across distcc to a cross-compilation machine. In
systems that use package management, it is done on the host through
Paul Mundt wrote:
This happens in a lot of places, like embedded gentoo ports, where almost
all of the work is sent across distcc to a cross-compilation machine. In
systems that use package management, it is done on the host through
emulation, or painfully cross-compiled.
Ah yes, I remember
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
Mark == Mark A Miller m...@mirell.org writes:
Mark And for H. Peter Anvin, before you refer to such uses as compiling the
Mark kernel under a native environment as a piece of art, please be aware
Mark that the mainstream embedded development environment, buildroot, is
Mark also attempting to
On Mon, Jan 12, 2009 at 2:20 AM, Paul Mundt let...@linux-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,
On Mon, Jan 12, 2009 at 03:18:53AM -0600, Mark A. Miller wrote:
On Mon, Jan 12, 2009 at 2:20 AM, Paul Mundt let...@linux-sh.org wrote:
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
On Mon, Jan 12, 2009 at 3:41 AM, Paul Mundt let...@linux-sh.org wrote:
I will repeat, there has not been a single coherent argument against what
makes perl inherently incapable of being supported.
You're right, this thread is worthless with that particular mindset,
Paul. Not, perhaps that the
On Sun, Jan 11, 2009 at 11:50:31PM -0600, Mark A. Miller wrote:
On Sun, Jan 11, 2009 at 11:35 PM, Sam Ravnborg s...@ravnborg.org wrote:
There are several other packages which are broken for embedded
architectures, which I will hopefully attempt to fix by submitting patches
upstream. But
On Mon, Jan 12, 2009 at 04:03:32AM -0600, Mark A. Miller wrote:
On Mon, Jan 12, 2009 at 3:41 AM, Paul Mundt let...@linux-sh.org wrote:
I will repeat, there has not been a single coherent argument against what
makes perl inherently incapable of being supported.
You're right, this thread is
On Mon, Jan 12, 2009 at 11:18:03AM +0100, Sam Ravnborg wrote:
On Sun, Jan 11, 2009 at 11:50:31PM -0600, Mark A. Miller wrote:
On Sun, Jan 11, 2009 at 11:35 PM, Sam Ravnborg s...@ravnborg.org wrote:
There are several other packages which are broken for embedded
architectures, which I will
On Monday 12 January 2009 11:22:47 you wrote:
...
entire environment, QEMU allows it nicely with distcc at a reasonable
speed. (Albeit there is no distconfigure, but that's entirely an
unrelated tanget of muck and despair and rants against configure, but
we're not going there...)
I'd be
On Monday 12 January 2009 02:27:32 Peter Korsgaard wrote:
Mark == Mark A Miller m...@mirell.org writes:
Mark And for H. Peter Anvin, before you refer to such uses as compiling
the Mark kernel under a native environment as a piece of art, please be
aware Mark that the mainstream embedded
On Son, 2009-01-04 at 11:23 +0100, Leon Woestenberg wrote:
[...]
On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt let...@linux-sh.org 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
On Sun, Jan 11, 2009 at 6:45 AM, Bernd Petrovitsch be...@firmix.at wrote:
On Son, 2009-01-04 at 11:23 +0100, Leon Woestenberg wrote:
[...]
On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt let...@linux-sh.org wrote:
[...]
I'm ignoring the cross-compile perl issue - haven't tried it for
years.
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
On Sun, Jan 11, 2009 at 11:11 PM, H. Peter Anvin h...@zytor.com 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
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
On Sun, Jan 11, 2009 at 11:35 PM, Sam Ravnborg s...@ravnborg.org 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
Rob and to whom it may concern,
I didn't discover this topic independently. Somebody pinged me about it on
freenode back in February, and several other people sent me private email
about it, and it's been previously raised on several other mailing lists (such
as busybox and uclibc ones).
On Sun, Jan 4, 2009 at 05:23, Leon Woestenberg wrote:
On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt let...@linux-sh.org wrote:
Let's look at the rationale presented so far in this thread:
2 - Cross-compiling perl is hard.
2 is not hard.
i dont know where you're getting this mythical
On Sat, Jan 03, 2009 at 07:45:34PM -0600, Rob Landley wrote:
With respect to your three patches the plan is to:
- add the updated timeconst patch to kbuild-next
- add the updated cpu-feature patch to kbuild-next
- the patch touching headers_install will not be merged.
The way forward
Hello,
On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt let...@linux-sh.org wrote:
Let's look at the rationale presented so far in this thread:
1 - Being able to build the kernel natively on a constrained
target is useful, regardless of whether it is being used for
Dear Paul Mundt,
In message 20090102095023.ga28...@linux-sh.org you wrote:
Your main reasons against inclusion of perl seem to be that there is no
realistic expectation for target systems that will be self-hosting will
have perl included, or the inherent complexity in maintaining a coherent
On Friday 02 January 2009 10:04:08 Matthieu CASTET wrote:
Rob Landley a écrit :
On Friday 02 January 2009 03:26:37 Arkadiusz Miskiewicz wrote:
On Friday 02 of January 2009, Rob Landley wrote:
Heh,
I believe all three scripts run under dash and busybox ash. (The
timeconst.sh one
On Friday 02 January 2009 12:01:34 Sam Ravnborg wrote:
But the serie rased anohter topic: shall we ban use of perl
for generating a kernel.
I dunno about ban, but every time somebody adds perl to the hot path of
the kernel build it breaks my build system, and I write a removal patch
anyway.
Sam Ravnborg wrote:
With respect to your three patches the plan is to:
- add the updated timeconst patch to kbuild-next
If you add this, you take the responsibility for the breakages that will
occur. The reason his patch is simpler is because he removes the
arbitrary-precision arithmetic, and
Hello all,
On Fri, Jan 2, 2009 at 9:07 AM, Rob Landley r...@landley.net wrote:
Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 )
building a Linux kernel never required perl to be installed on the build
system. (Various development and debugging scripts were written in
Rob Landley wrote:
For the record, the reason I can't just pregenerate all these suckers on a
system that's got an arbitrary precision calculator (ala dc) and then just
ship the resulting header files (more or less the what the first version of
that first patch did) is that some architectures
Here's an updated set of patches to remove use of perl from the kernel build's
hot path (roughly defined as make allnoconfig; make; make
headers_install).
This update incorporates feedback from Sam Ravnborg, Ted Tso, Joe Perches,
Ingo Oeser, and others. It also fixes an integer overflow error
On Friday 02 January 2009 10:04:08 Matthieu CASTET wrote:
Rob Landley a écrit :
On Friday 02 January 2009 03:26:37 Arkadiusz Miskiewicz wrote:
On Friday 02 of January 2009, Rob Landley wrote:
Heh,
I believe all three scripts run under dash and busybox ash. (The
timeconst.sh one
On Friday 02 January 2009 13:27:45 H. Peter Anvin wrote:
Sam Ravnborg wrote:
Hi Wookey.
Given the
simplicitly of these patches I can't see any reason not to put them
in
Please do NOT do the mistake and think this the same thing.
Rob's patch simplyfy the timecost stuff - and will
On Saturday 03 January 2009, Robert Hancock wrote:
Rob Landley wrote:
... some architectures (arm omap and and arm at91)
allow you to enter arbitrary HZ values in kconfig. (Their help text says
that
in many cases values that aren't powers of two won't work, but nothing
enforces
On Saturday 03 January 2009 17:03:11 H. Peter Anvin wrote:
Leon Woestenberg wrote:
I agree with Rob that the amount of required dependencies should be
kept to a minimum.
If we only use 0.5% of a certain language (or: dependent package),
then rather implement that 0.5% in the existing
Rob Landley wrote:
The new patches have *more* environmental
dependencies than that ever did.
Could you please be a little more specific?
In this case, you're assuming that every version of every shell this is
going to get involved with is going to do math correctly with the
requisite
On Friday 02 January 2009 08:04:09 Theodore Tso wrote:
Sounds like though modulo dealing with 64-bit arithmetic, your patches
are mostly dash/POSIX.2 comformant, so you're probably mostly good on
that front once you address the 32/64-bit issues. I'd also suggest
explicitly add a reminder to
Rob Landley wrote:
This doesn't _need_ bignum support. It maxes out around 72 bits and
the _result_ can't use more than about $SHIFT bits because you're
dividing by the amount you shifted, so just chop off the bottom 32
bits, do a normal 64 bit division on the top (it has to fit), and
then
Jamie Lokier wrote:
Related query:
Does the Perl script being replaced use 64-bit arithmetic? Because
many Perl installations only do 32-bit arithmetic.
If the Perl version works in 32-bit arithmetic, why does the shell
version not do the same thing?
The Perl version uses
Rob Landley, 04.01.2009:
On Saturday 03 January 2009 18:37:12 Leon Woestenberg wrote:
My argument on thin dependencies indeed mostly holds for run-time
dependencies (to reduce size) but also for build dependency (to reduce
complexity)*.
I usually just point to the gnucash 1.6 release as
On Saturday 03 January 2009 21:38:13 Markus Heidelberg wrote:
Rob Landley, 04.01.2009:
Now that you mention this the second time, I have to ask where you have
this information from. Since I use Gentoo, I was always able to compile
OpenOffice (version 1, 2 and now 3) myself.
The gentoo panel
On Saturday 03 January 2009 20:14:44 H. Peter Anvin wrote:
Rob Landley wrote:
The new patches have *more* environmental
dependencies than that ever did.
Could you please be a little more specific?
In this case, you're assuming that every version of every shell this is
going to get
On Friday 02 of January 2009, Rob Landley wrote:
Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 )
building a Linux kernel never required perl to be installed on the build
system. (Various development and debugging scripts were written in perl
and python and such, but
On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote:
On Friday 02 of January 2009, Rob Landley wrote:
Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 )
building a Linux kernel never required perl to be installed on the build
system. (Various
On Jan 2, 2009, at 3:26 AM, Arkadiusz Miskiewicz wrote:
On Friday 02 of January 2009, Rob Landley wrote:
Before 2.6.25 (specifically git
bdc807871d58285737d50dc6163d0feb72cb0dc2 )
building a Linux kernel never required perl to be installed on the
build
system. (Various development and
Christoph Hellwig escribió:
On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote:
On Friday 02 of January 2009, Rob Landley wrote:
Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 )
building a Linux kernel never required perl to be installed on
On Fri, Jan 02, 2009 at 04:32:42AM -0600, Mark Miller wrote:
On Jan 2, 2009, at 3:50 AM, Paul Mundt wrote:
Misguided rhetoric aside, what does this actually accomplish? If folks
add meaningful tools in to the kernel that require python, and it is
generally regarded as being fairly ubiquitous,
On Friday 02 January 2009 03:26:37 Arkadiusz Miskiewicz wrote:
On Friday 02 of January 2009, Rob Landley wrote:
Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2
) building a Linux kernel never required perl to be installed on the
build system. (Various development
On Friday 02 January 2009 04:16:53 Alejandro Mery wrote:
Christoph Hellwig escribió:
On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote:
On Friday 02 of January 2009, Rob Landley wrote:
Before 2.6.25 (specifically git
bdc807871d58285737d50dc6163d0feb72cb0dc2 ) building a
On Friday 02 January 2009 03:50:23 Paul Mundt wrote:
On Fri, Jan 02, 2009 at 02:07:28AM -0600, Rob Landley wrote:
The perl checkin for 2.6.25 was the camel's nose under the tent flap, and
since then two more instances of perl have shown up in the core kernel
build. This patch series removes
On Friday 02 January 2009 03:49:34 Christoph Hellwig wrote:
On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote:
On Friday 02 of January 2009, Rob Landley wrote:
Before 2.6.25 (specifically git
bdc807871d58285737d50dc6163d0feb72cb0dc2 ) building a Linux kernel
never
On Fri, Jan 02, 2009 at 06:56:31AM -0600, Rob Landley wrote:
That said, how is bash _worse_ than perl? (Where's the second
implementation of perl? Even Python had jython, but perl
has... what? The attempt to rebase on Parrot went down in
flames...)
(1) bash implies POSIX extensions; perl
Rob Landley a écrit :
On Friday 02 January 2009 03:26:37 Arkadiusz Miskiewicz wrote:
On Friday 02 of January 2009, Rob Landley wrote:
Heh,
I believe all three scripts run under dash and busybox ash. (The
timeconst.sh
one needs 64 bit math which dash only provides on 64 bit hosts, which
On 2009-01-02 18:50 +0900, Paul Mundt wrote:
Your main reasons against inclusion of perl seem to be that there is no
realistic expectation for target systems that will be self-hosting will
have perl included, or the inherent complexity in maintaining a coherent
cross compiling environment.
Hi Wookey.
Given the
simplicitly of these patches I can't see any reason not to put them
in
Please do NOT do the mistake and think this the same thing.
Rob's patch simplyfy the timecost stuff - and will be applied on
this merit alone assuming comments will be addressed.
But the serie rased
Sam Ravnborg wrote:
Hi Wookey.
Given the
simplicitly of these patches I can't see any reason not to put them
in
Please do NOT do the mistake and think this the same thing.
Rob's patch simplyfy the timecost stuff - and will be applied on
this merit alone assuming comments will be
56 matches
Mail list logo
