Rob Landley wrote:
> Most packages don't cross compile at all. Debian has somewhere north of
> 30,000 packages. Every project that does large scale cross compiling
> (buildroot, gentoo embedded, timesys making fedora cross compile, etc) tends
> to have about 200 packages that cross compile mor
Hi Tim.
> The program is also now better structured, IMHO.
> -- Tim
Seeing this programs gets frequent updates (good!) I have not
yet applied it.
When you consider it stabilized could you please drop me a
new mail including full changelog and updated patch.
And please cc: [EMAIL PROTECTED] + l
Rob Landley wrote:
> However, having one or more full-time engineers devoted to debugging
> cross-compile issues is quite a high price to pay too. Moore's law really
> doesn't help that one.
>
> I'm not saying either solution is perfect, I'm just saying the "build under
> emulation" approach i
On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote:
> Rob Landley wrote:
> > However, having one or more full-time engineers devoted to debugging
> > cross-compile issues is quite a high price to pay too. Moore's law really
> > doesn't help that one.
> >
> > I'm not saying either solution is per
On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote:
> On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote:
>> Rob Landley wrote:
>> > However, having one or more full-time engineers devoted to debugging
>> > cross-compile issues is quite a high price to pay too. Moore's law really
>> > doesn't
Sam Ravnborg wrote:
> Hi Tim.
>
>> The program is also now better structured, IMHO.
>> -- Tim
>
> Seeing this programs gets frequent updates (good!) I have not
> yet applied it.
>
> When you consider it stabilized could you please drop me a
> new mail including full changelog and updated patch.
On Thu, 2008-06-12 at 12:05 -0400, Mike Frysinger wrote:
> people cant even write proper *native* makefiles. mtd-utils for
> example ;).
Criticism in 'diff -u' form preferred :)
--
dwmw2
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [E
On Thu, Jun 12, 2008 at 04:50:31PM +0100, David Woodhouse wrote:
> On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote:
> > Rob Landley wrote:
> > > However, having one or more full-time engineers devoted to debugging
> > > cross-compile issues is quite a high price to pay too. Moore's law
> > > r
On Thu, 12 Jun 2008, Mike Frysinger wrote:
> On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote:
> > If we just made people write portable code and proper Makefiles,
> > it would be less of an issue :)
>
> people cant even write proper *native* makefiles. mtd-utils for
> example ;).
meooow
On Thu, Jun 12, 2008 at 12:08 PM, David Woodhouse wrote:
> On Thu, 2008-06-12 at 12:05 -0400, Mike Frysinger wrote:
>> people cant even write proper *native* makefiles. mtd-utils for
>> example ;).
>
> Criticism in 'diff -u' form preferred :)
i sent via `git-send-email` yesterday to the mtd lists
David Woodhouse wrote:
>>... fixing
>> them in the upstream packages (or in the autoconf system itself).
>>
>> Once someone fixes the cross-compilation issues for a package, they usually
>> stay fixed, if the fixes are mainlined.
>
> I don't think that's true, unfortunately. Autoconf makes it _eas
Guys:
> If you opt to cross-compile, having to deal with those
> sorts of things is the price you pay.
If the build system derives from autoconf, then a hacked-up config.cache (or
equivalent command-line args) often solves problems for me. Just give the cache
the answers that it would otherwise
On Thu, Jun 12, 2008 at 11:28:10AM -0500, Bill Gatliff wrote:
> Guys:
>
> > If you opt to cross-compile, having to deal with those
> > sorts of things is the price you pay.
>
>
> If the build system derives from autoconf, then a hacked-up config.cache (or
> equivalent command-line args) often so
On Thu, 2008-06-12 at 11:28 -0500, Bill Gatliff wrote:
> Guys:
>
> > If you opt to cross-compile, having to deal with those
> > sorts of things is the price you pay.
>
>
> If the build system derives from autoconf, then a hacked-up config.cache (or
> equivalent command-line args) often solves pr
On Thu, Jun 12, 2008 at 12:31 PM, Paul Mundt wrote:
> On Thu, Jun 12, 2008 at 11:28:10AM -0500, Bill Gatliff wrote:
>> > If you opt to cross-compile, having to deal with those
>> > sorts of things is the price you pay.
>>
>>
>> If the build system derives from autoconf, then a hacked-up config.cach
On Thu, Jun 12, 2008 at 05:37:35PM +0100, David Woodhouse wrote:
> On Thu, 2008-06-12 at 11:28 -0500, Bill Gatliff wrote:
> > Guys:
> >
> > > If you opt to cross-compile, having to deal with those
> > > sorts of things is the price you pay.
> >
> >
> > If the build system derives from autoconf,
Paul Mundt wrote:
> Yes, that's the easy case. It's things like perl that are the corner
> cases, and my objection comes from the fact that people think we ought to
> not have the kernel depend on perl rather than just fixing the package
> itself. Autoconf/libtool damage is an entirely different p
David Woodhouse wrote:
> Yeah, I was building Red Hat Linux packages for sh3 many years ago,
> using tricks like that. But there was always _something_ else going
> wrong, however much you hacked around it. And a lot of it would only
> turn up at runtime, not build time. I would never consider ship
Adrian Bunk wrote:
> There's also the middle way taken by e.g. Scratchbox of using
> cross-compilers and other tools from the machine the compilation
> is done on, but emulating a native build for the software being
> compiled.
I suppose. But I've never gotten Scratchbox to work for me, at all.
On Thu, Jun 12, 2008 at 12:14:32PM -0500, Bill Gatliff wrote:
> Paul Mundt wrote:
>
> > Yes, that's the easy case. It's things like perl that are the corner
> > cases, and my objection comes from the fact that people think we ought to
> > not have the kernel depend on perl rather than just fixing
On Thu, Jun 12, 2008 at 1:14 PM, Bill Gatliff wrote:
> Paul Mundt wrote:
>> Yes, that's the easy case. It's things like perl that are the corner
>> cases, and my objection comes from the fact that people think we ought to
>> not have the kernel depend on perl rather than just fixing the package
>>
OK - at the extreme risk of burning up whatever karma I have on
this list, I'm posting this notice. I promise not to do this very often.
(maybe two or three times a year, and only for events I help run.)
--
EMBEDDED LINUX CONFERENCE EUROPE - November 6,7 2008, EDE, THE NETHERLANDS
I w
Hi,
I have been following "Re: [PATCH 0/1] Embedded Maintainer(s)" and
felt like asking that is there one good way to get a cross compiler
work. I tried buildroot, scratchbox and even openMoko with
openEmbedded but all of them had lots of issues and don't know which
will be the best alternative.
* Rob Landley <[EMAIL PROTECTED]> schrieb:
Hi,
> There's also qemu. You can native build under emulation.
did you ever consider that crosscompiling is not only good for
some other arch, but a few more things ?
> In addition, if you have a cross compiler but don't want to spend all your
> t
In message <[EMAIL PROTECTED]> you wrote:
>
> I have been following "Re: [PATCH 0/1] Embedded Maintainer(s)" and
> felt like asking that is there one good way to get a cross compiler
> work. I tried buildroot, scratchbox and even openMoko with
> openEmbedded but all of them had lots of issues and
* Rob Landley <[EMAIL PROTECTED]> schrieb:
> Cross compiling breaks stuff, yes.
>
> Most packages don't cross compile at all. Debian has somewhere north of
> 30,000 packages. Every project that does large scale cross compiling
> (buildroot, gentoo embedded, timesys making fedora cross compile
On Thu, Jun 12, 2008 at 12:05 PM, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote:
>> On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote:
>>> Rob Landley wrote:
>>> > However, having one or more full-time engineers devoted to debugging
>>> > cross-
* Paul Mundt <[EMAIL PROTECTED]> schrieb:
> The other issue is that people that are working in this space tend to do
> very little beyond solving their immediate troubles.
Sad but true :(
> Since perl was mentioned, it also makes a good example. Embedded distros
> have been cross-compiling per
* Bill Gatliff <[EMAIL PROTECTED]> schrieb:
> If the build system derives from autoconf, then a hacked-up
> config.cache (or equivalent command-line args) often solves
> problems for me.
Only if you're working on *one specific* target for a long time.
I, for example, have to support lots of di
* Tim Bird <[EMAIL PROTECTED]> schrieb:
> If autoconf is the problem (and I think it is), then that's what
> should be fixed (see my original post).
ACK. One of the first things I did was replacing libtool and
kicked off broken-by-design macros like AC_TRY_RUN. This solved
at >80% of the proble
> Hi,
>
> I have been following "Re: [PATCH 0/1] Embedded Maintainer(s)" and
> felt like asking that is there one good way to get a cross compiler
> work. I tried buildroot, scratchbox and even openMoko with
> openEmbedded but all of them had lots of issues and don't know which
> will be the best a
El Thu, Jun 12, 2008 at 10:52:44PM +0500 Shaz ha dit:
> I have been following "Re: [PATCH 0/1] Embedded Maintainer(s)" and
> felt like asking that is there one good way to get a cross compiler
> work. I tried buildroot, scratchbox and even openMoko with
> openEmbedded but all of them had lots of i
* Bill Traynor <[EMAIL PROTECTED]> schrieb:
> There is no "one good way". I've had decent success building Dan Kegel's
> "crosstool" in the past: http://www.kegel.com/crosstool/
I'd also like to mention Yann's crosstool-ng :)
cu
--
-
On Thu, Jun 12, 2008 at 12:38:42PM -0400, Mike Frysinger wrote:
>On Thu, Jun 12, 2008 at 12:31 PM, Paul Mundt wrote:
>> On Thu, Jun 12, 2008 at 11:28:10AM -0500, Bill Gatliff wrote:
>>> That's how emdebian is doing a bunch of their stuff, and I have to admit
>>> that it
>>> works pretty darned we
In message <[EMAIL PROTECTED]> you wrote:
>
> Perl never was crosscompile-capable.
> I've rewrote much of the buildscripts, but not finished yet.
Note that Perl is included with our ELDK, and we do cross-compile it.
It's not exactly trivial, but not really difficult either.
Best regards,
Wolfga
Shaz wrote:
> Hi,
>
> I have been following "Re: [PATCH 0/1] Embedded Maintainer(s)" and
> felt like asking that is there one good way to get a cross compiler
> work. I tried buildroot, scratchbox and even openMoko with
> openEmbedded but all of them had lots of issues and don't know which
> will
In message <[EMAIL PROTECTED]> you wrote:
>
> > Since perl was mentioned, it also makes a good example. Embedded distros
> > have been cross-compiling perl for pretty much the last decade, yet even
>
> Now I'm curious: where can I find a patch ?
See for example:
http://git.denx.de/?p=eldk/bui
Enrico Weigelt wrote:
> * Bill Gatliff <[EMAIL PROTECTED]> schrieb:
>
>> If the build system derives from autoconf, then a hacked-up
>> config.cache (or equivalent command-line args) often solves
>> problems for me.
>
> Only if you're working on *one specific* target for a long time.
> I, for
On Thu, Jun 12, 2008 at 11:49 PM, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
> * Bill Traynor <[EMAIL PROTECTED]> schrieb:
>
>> There is no "one good way". I've had decent success building Dan Kegel's
>> "crosstool" in the past: http://www.kegel.com/crosstool/
>
> I'd also like to mention Yann's cr
On Thu, Jun 12, 2008 at 2:29 PM, Josh Boyer wrote:
> On Thu, Jun 12, 2008 at 12:05 PM, Mike Frysinger wrote:
>> On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote:
>>> On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote:
Rob Landley wrote:
> However, having one or more full-time engine
On 12-Jun-08, at 1:52 PM, Shaz wrote:
Hi,
I have been following "Re: [PATCH 0/1] Embedded Maintainer(s)" and
felt like asking that is there one good way to get a cross compiler
work. I tried buildroot, scratchbox and even openMoko with
openEmbedded but all of them had lots of issues and don't
Hello,
we currently try to boot a 2.6.21 kernel on a custom IXP422 based board. The
boot loader (U-Boot) works fine so far, memory and flash test run successfully,
the NPE is also able to ping a host. So we assume the board itself is more or
less working at least.
When we try to boot a 2.6.21 k
On Fri, Jun 13, 2008 at 12:02:06AM +0500, Shaz wrote:
> On Thu, Jun 12, 2008 at 11:49 PM, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
> > * Bill Traynor <[EMAIL PROTECTED]> schrieb:
> >
> >> There is no "one good way". I've had decent success building Dan Kegel's
> >> "crosstool" in the past: http:/
On Thu, Jun 12, 2008 at 3:35 PM, Marcus Tangermann wrote:
> we currently try to boot a 2.6.21 kernel
time to upgrade
> on a custom IXP422 based board.
you'll have better luck asking on the arm kernel mailing lists. they
process this stuff every day.
-mike
--
To unsubscribe from this list: send
* Wolfgang Denk <[EMAIL PROTECTED]> schrieb:
> In message <[EMAIL PROTECTED]> you wrote:
> >
> > Perl never was crosscompile-capable.
> > I've rewrote much of the buildscripts, but not finished yet.
>
> Note that Perl is included with our ELDK, and we do cross-compile it.
> It's not exactly trivi
Enrico Weigelt wrote:
* Rob Landley <[EMAIL PROTECTED]> schrieb:
Cross compiling breaks stuff, yes.
Most packages don't cross compile at all. Debian has somewhere north of
30,000 packages. Every project that does large scale cross compiling
(buildroot, gentoo embedded, timesys making fed
On 12-Jun-08, at 4:04 PM, Mike Frysinger wrote:
On Thu, Jun 12, 2008 at 3:35 PM, Marcus Tangermann wrote:
we currently try to boot a 2.6.21 kernel
time to upgrade
Wrong answer!!!
Many embedded devices can't upgrade kernels easily because of
customer requirements and certifications.
On Thu, Jun 12, 2008 at 5:28 PM, Glenn Henshaw wrote:
> On 12-Jun-08, at 4:04 PM, Mike Frysinger wrote:
>> On Thu, Jun 12, 2008 at 3:35 PM, Marcus Tangermann wrote:
>>> we currently try to boot a 2.6.21 kernel
>>
>> time to upgrade
>
> Wrong answer!!!
not really
> Many embedded devices can't up
David VomLehn wrote:
Enrico Weigelt wrote:
* Rob Landley <[EMAIL PROTECTED]> schrieb:
Cross compiling breaks stuff, yes.
Most packages don't cross compile at all. Debian has somewhere north
of 30,000 packages. Every project that does large scale cross
compiling (buildroot, gentoo embedde
On Fri, Jun 13, 2008 at 1:28 AM, Glenn Henshaw
<[EMAIL PROTECTED]> wrote:
>
> On 12-Jun-08, at 4:04 PM, Mike Frysinger wrote:
>
>> On Thu, Jun 12, 2008 at 3:35 PM, Marcus Tangermann wrote:
>>>
>>> we currently try to boot a 2.6.21 kernel
>>
>> time to upgrade
>
> Wrong answer!!!
While the answer
On Thu, Jun 12, 2008 at 5:42 PM, James Chapman wrote:
> David VomLehn wrote:
>> Amen, brother. I'm fortunate in that I work for an organization that is
>> quite good about enforcing code reviews, specifically, the QA organization
>> is empowered to reject changes that do not have code review notes.
Mike Frysinger wrote:
>> Er, is that GPL or LGPL code that you're modifying? If so, you *have* to
>> push those code changes out (make them available to others), whether you
>> think people will be interested or not!
>
> umm, not really. only if (1) he gives a binary to someone and (2)
> they ask
On Thu, Jun 12, 2008 at 5:53 PM, Tim Bird wrote:
> Mike Frysinger wrote:
>>> Er, is that GPL or LGPL code that you're modifying? If so, you *have* to
>>> push those code changes out (make them available to others), whether you
>>> think people will be interested or not!
>>
>> umm, not really. only
Glenn,
I totally agree with your certification statement statement as a legit
reason to not upgrade. I once worked for a aircraft lighting supplier,
their FAA certification testing process took about 4 years. Going
through the cert process makes one more resistant to change.
Craig
On Thu, 2008-
On Thu, 2008-06-12 at 17:28 -0400, Glenn Henshaw wrote:
> > On Thu, Jun 12, 2008 at 3:35 PM, Marcus Tangermann wrote:
> >> we currently try to boot a 2.6.21 kernel
> >
> > time to upgrade
>
>Wrong answer!!!
>
>Many embedded devices can't upgrade kernels easily because of
> customer requ
On Thu, Jun 12, 2008 at 05:46:42PM -0400, Mike Frysinger wrote:
> On Thu, Jun 12, 2008 at 5:42 PM, James Chapman wrote:
> > David VomLehn wrote:
> >> Amen, brother. I'm fortunate in that I work for an organization that is
> >> quite good about enforcing code reviews, specifically, the QA organizati
subscribe
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12-Jun-08, at 4:04 PM, Mike Frysinger wrote:
On Thu, Jun 12, 2008 at 3:35 PM, Marcus Tangermann wrote:
we currently try to boot a 2.6.21 kernel
on a custom IXP422 based board.
What bootloader are you using? It may be that the memory controller
is initialized improperly.
For othe
Hi Marcus,
Marcus Tangermann wrote:
we currently try to boot a 2.6.21 kernel on a custom IXP422 based board. The
boot loader (U-Boot) works fine so far, memory and flash test run successfully,
the NPE is also able to ping a host. So we assume the board itself is more or
less working at least.
On Thursday 12 June 2008 11:12:13 Robert P. J. Day wrote:
> On Thu, 12 Jun 2008, Mike Frysinger wrote:
> > On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote:
> > > If we just made people write portable code and proper Makefiles,
> > > it would be less of an issue :)
> >
> > people cant even w
Rob Landley wrote:
> I just did a "make distclean" on a qemu tree I had lying around. On my 1.7
> ghz 64 bit laptop, it took 9.2 seconds to figure out it had nothing to do,
> just because it had to recurse into so many subdirectories to do it.
Which is precisely why recursive makes are conside
On Thursday 12 June 2008 11:23:19 Tim Bird wrote:
> David Woodhouse wrote:
> > I don't think that's true, unfortunately. Autoconf makes it _easy_ to do
> > the wrong thing, and people will often introduce new problems.
>
> If autoconf is the problem (and I think it is), then that's what
> should be
On Thu, 12 Jun 2008, Rob Landley wrote:
> He recently converted Battle for Wesnoth to use something called
> "scons" as its build system, and apparently the resulting make stuff
> was 1/17th the size of the original. You'd have to ask him for
> details, though...
scons is definitely wicked cool.
On Thu, Jun 12, 2008 at 9:25 PM, Rob Landley wrote:
> He recently converted Battle for Wesnoth to use something called "scons" as
> its build system, and apparently the resulting make stuff was 1/17th the size
> of the original.
probably because scons has ~1/17th the functionality of autotools.
se
On Thu, Jun 12, 2008 at 09:35:16PM +0200, Marcus Tangermann wrote:
> Hello,
>
> we currently try to boot a 2.6.21 kernel on a custom IXP422 based board. The
> boot loader (U-Boot) works fine so far, memory and flash test run
> successfully, the NPE is also able to ping a host. So we assume the b
>
> Um, actually Eric Raymond and I have had long talks about this, and if we're
> ever in the same state for more than 3 days we may finally get to do a
> serious research project about the successors to ./configure and make.
Tom has started a nice project which he named: quagmire.
See: http:/
hi,
In my application I want to override the timer interrupt, and I'm
doing in this manner:
disable_irq(0); /* disable timer irq first */
free_irq(0, NULL); /* free the old irq */
setup_irq(0, new_irq0);
setup_irq() return with 0, however I got the followi
On Thu, Jun 12, 2008 at 10:52:44PM +0500, Shaz wrote:
> I have been following "Re: [PATCH 0/1] Embedded Maintainer(s)" and
> felt like asking that is there one good way to get a cross compiler
> work. I tried buildroot, scratchbox and even openMoko with
> openEmbedded but all of them had lots of is
在 2008-06-13五的 06:34 +0200，Robert Schwebel写道：
> On Thu, Jun 12, 2008 at 10:52:44PM +0500, Shaz wrote:
> > I have been following "Re: [PATCH 0/1] Embedded Maintainer(s)" and
> > felt like asking that is there one good way to get a cross compiler
> > work. I tried buildroot, scratchbox and even openM
On Thursday 12 June 2008 17:50:31 you wrote:
> On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote:
> > Rob Landley wrote:
> > > However, having one or more full-time engineers devoted to debugging
> > > cross-compile issues is quite a high price to pay too. Moore's law
> > > really doesn't help tha
On Friday 13 June 2008 03:29:52 Mike Frysinger wrote:
> On Thu, Jun 12, 2008 at 9:25 PM, Rob Landley wrote:
> > He recently converted Battle for Wesnoth to use something called "scons"
> > as its build system,
Battle of Wesnoth is currently converted to both Scons and CMake, and in the
end they
On Friday 13 June 2008 02:25:34 you wrote:
> On Thursday 12 June 2008 11:12:13 Robert P. J. Day wrote:
> > On Thu, 12 Jun 2008, Mike Frysinger wrote:
> > > On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote:
> > > > If we just made people write portable code and proper Makefiles,
> > > > it wo
72 matches
Mail list logo
