Jamie Lokier wrote:
Bill Traynor wrote:
For some reason, that stopped a while ago, and you had to go to
different places to get working basic tools. And often, the place to
go wasn't clear. Different people advertised their "ARM toolchain",
"m68k toolchain" etc. and they were slightly differe
Hi Linus,
> I tried this thing to be able to modprobe off a read-only flash
> rootfilesystem and it "sort of" works, actually.
>
> However there is no way you will pass this to the kernel DEPMOD
> parameter, I only ever get this to work when doing it after
> compilation, as a separate step.
I thi
Bill Traynor wrote:
> > For some reason, that stopped a while ago, and you had to go to
> > different places to get working basic tools. And often, the place to
> > go wasn't clear. Different people advertised their "ARM toolchain",
> > "m68k toolchain" etc. and they were slightly different sets
Enrico Weigelt wrote:
> > Contrast with kernel.org: everyone knows where to get a good working
> > Linux kernel for the mainstream architectures, and the quality work
> > tends to be quite good at reaching mainline there nowadays.
>
> ACK. But you perhaps remember the discussions on LKML where som
Enrico Weigelt wrote:
> * Alexander Neundorf <[EMAIL PROTECTED]> schrieb:
>
> > E.g. in python there are tests which call functions and check
> > their result to see if we are currently on a platform where
> > that function is broken (I think there was such a test for
> > poll() and some other
Robert Schwebel wrote:
> On Fri, Jun 13, 2008 at 11:25:23PM +0100, Jamie Lokier wrote:
> > A trouble with that is some packages have hundreds of user-selectable
> > options - or even thousands.
>
> I've not seen a package with thousands of user selectable options. It's
> not even desirable, becaus
On Fri, Jun 13, 2008 at 7:33 PM, Linus Walleij wrote:
> what are other embedded developers experience with using the
> script "depmod.pl" from BusyBox to create
> installdir/lib/modules//modules.dep
> during compile-time?
it's used in the uClinux distribution and works fine for me. only had
probl
Hi,
what are other embedded developers experience with using the
script "depmod.pl" from BusyBox to create
installdir/lib/modules//modules.dep
during compile-time?
(It's this beast:
http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/examples/depmod.pl?rev=20447&view=markup
I tried this thing to
On Fri, Jun 13, 2008 at 11:25:23PM +0100, Jamie Lokier wrote:
> A trouble with that is some packages have hundreds of user-selectable
> options - or even thousands.
I've not seen a package with thousands of user selectable options. It's
not even desirable, because the more options you have, the mo
James Chapman wrote:
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 (bui
Robert Schwebel wrote:
> On Fri, Jun 13, 2008 at 08:30:52AM +0200, Alexander Neundorf wrote:
> > Battle of Wesnoth is currently converted to both Scons and CMake, and
> > in the end they will decide about the winner. (since Eric is good at
> > arguing I guess it will be scons).
>
> The thing is th
>> And what kinds of source/kconfig changes are made for every build?
>
> I start with a baseline config for an embedded board, then
> alter, one at a time, individual config items related to kernel size.
> No source changes are made.
Using same `gcc -E` principle, I once had a dream to create
bui
Oleg Verych wrote:
> And what kinds of source/kconfig changes are made for every build?
I start with a baseline config for an embedded board, then
alter, one at a time, individual config items related to kernel size.
No source changes are made.
I do full removal of the kernel source tree and buil
Tim Bird @ Fri, 13 Jun 2008 12:06:05 -0700:
> I'm running an automated test which does numerous compiles
> of the Linux kernel. One of the things I do is create a localversion
> file at the root of the kernel source tree with a unique identifier
> that I use later on in testing.
And what kinds o
On Fri, Jun 13, 2008, Tim Bird wrote:
>
> YMMV. I put some of the resources and info I found at:
> http://elinux.org/Debugging_Makefiles
There is also "remake", which is "A patched GNU make with a debuger,
better tracing and error reporting" (based on GNU make 3.80).
Development seems to have st
Rob,
This is an excellent and concise description of the open
source perspective on the problem. I'll add just one note below.
Rob Landley wrote:
> 1) Try to reproduce the bug under a current kernel. (Set up a _test_ system.)
This sounds easy, but can be quite difficult.
Very often, product d
On Friday 13 June 2008 04:06:18 Alexander Neundorf wrote:
> > And the above are not really a big problem -
>
> "checking if something builds" is no problem, this just works. Running
> something is a problem, as in "it doesn't just work" (...because you cannot
> run it).
Noticing 2 weeks after depl
On Thursday 12 June 2008 16:28:48 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!!!
Fairly common answer actually. It tra
On Thursday 12 June 2008 12:14:32 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
On Thursday 12 June 2008 12:52:44 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 is
On Fri, Jun 13, 2008 at 08:45:09PM +0200, Bernd Petrovitsch wrote:
> > Recent pkg-config supports sysroot.
>
> FC-6 has "only" 0.21.
Solved in ptxdist by building the "right" pkgconfig as a host tool.
> > So you simply build your .pc files as usual (w/o sysroot prefix) and
> > set the sysroot pr
Hi Greg,
first, thanks for the hints.
The most common problem like this I have seen are that the
ARM machine type set by the boot loader does not match those
compiled into the kernel. Also make sure that the RAM
size being passed to the kernel is correct too.
This seems to be set correctly.
I'm running an automated test which does numerous compiles
of the Linux kernel. One of the things I do is create a localversion
file at the root of the kernel source tree with a unique identifier
that I use later on in testing.
I started using ccache to improve the performance of my builds,
but f
> Bill Traynor wrote:
Do you wanna set some breakpoints and inspect variables in makefiles?
Have a look at a simple makefile debugger (written in make):
>> http://www.embedded.com/columns/technicalinsights/197003517?printable=true
>
> The article above shows some macros you can add to you
On Fri, Jun 13, 2008 at 11:44:54AM -0700, Tim Bird wrote:
> Bill Traynor wrote:
> >>> Do you wanna set some breakpoints and inspect variables in makefiles?
> >>> Have a look at a simple makefile debugger (written in make):
> > http://www.embedded.com/columns/technicalinsights/197003517?printable=tr
On Fri, Jun 13, 2008 at 08:30:52AM +0200, Alexander Neundorf wrote:
> Battle of Wesnoth is currently converted to both Scons and CMake, and
> in the end they will decide about the winner. (since Eric is good at
> arguing I guess it will be scons).
The thing is that 'configure && make && make insta
On Fri, Jun 13, 2008 at 05:11:04AM +0200, Sam Ravnborg wrote:
> Tom has started a nice project which he named: quagmire.
> See: http://code.google.com/p/quagmire/
>
> From the website:
> quagmire is intended to replace automake and libtool. Unlike these tools
> it requires GNU make and is written
On Thu, Jun 12, 2008 at 08:37:35PM +0200, Enrico Weigelt wrote:
> 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 problems for me.
Instead of hacking around and inventing new things, you should have
spe
On Fre, 2008-06-13 at 17:16 +0200, Enrico Weigelt wrote:
> * Bernd Petrovitsch <[EMAIL PROTECTED]> schrieb:
>
> > > Basically yes. But if you have a big number of packages (or a huge
> > > package)
> > > which you didn't write yourself, there will be tests which run
> > > executables.
> > > Fi
Bill Traynor wrote:
>>> Do you wanna set some breakpoints and inspect variables in makefiles?
>>> Have a look at a simple makefile debugger (written in make):
> http://www.embedded.com/columns/technicalinsights/197003517?printable=true
The article above shows some macros you can add to your Makefi
Sorry, the link did not work.
It wants to pass by my webpage;)
Use this:
http://www.reliableembeddedsystems.com/newsflashes/newsflash/debugging-makefiles.html
Regards,
Robert
---
Robert Berger
Embedded Software Specialist
Reliable Embedded Systems
Consulting Training Engineering
Te
* Bill Traynor <[EMAIL PROTECTED]> schrieb:
> The "fixed elsewhere" is the problem. If everyone used the most current
> release and worked through issues with the community, this problem would
> go away.
Yep, and here we're again at the point that opensource/community
development and just use o
> On Fri, 2008-06-13 at 10:02 -0500,
> [EMAIL PROTECTED] wrote:
>> Do you wanna set some breakpoints and inspect variables in makefiles?
>> Have a look at a simple makefile debugger (written in make):
>> http://newsletter.embedded.com/shared/printableArticle.jhtml?articleID=197003517
>
> 404.
Is t
On Fri, 2008-06-13 at 10:02 -0500,
[EMAIL PROTECTED] wrote:
> Do you wanna set some breakpoints and inspect variables in makefiles?
> Have a look at a simple makefile debugger (written in make):
> http://newsletter.embedded.com/shared/printableArticle.jhtml?articleID=197003517
404.
You got me all
* Alexander Neundorf <[EMAIL PROTECTED]> schrieb:
> E.g. in python there are tests which call functions and check
> their result to see if we are currently on a platform where
> that function is broken (I think there was such a test for
> poll() and some other functions).
IMHO, that's broken s
> Bill Traynor wrote:
>> Maybe I'm being dense, but what's specifically wrong with the current
>> toolchain universe?
>
> Back in ye olde days, you could download GCC and Binutils from
> gnu.org, configure for whatever is your architecture, and most times
> it just worked.
Yes, the difficulty is i
* Alexander Neundorf <[EMAIL PROTECTED]> schrieb:
> Well, IMO this makes it sound too easy.
> If you write portable software, you have to do platform checks.
> Basically they can be done by
> -checking for the existence of files
> -checking if something builds
> -checking the output of running som
Hi David,
Do you wanna set some breakpoints and inspect variables in makefiles?
Have a look at a simple makefile debugger (written in make):
http://newsletter.embedded.com/shared/printableArticle.jhtml?articleID=197003517
Regards,
Robert
---
Robert Berger
Embedded Software Specialist
Reliable
* Jamie Lokier <[EMAIL PROTECTED]> schrieb:
> For some reason, that stopped a while ago, and you had to go to
> different places to get working basic tools. And often, the place to
> go wasn't clear. Different people advertised their "ARM toolchain",
> "m68k toolchain" etc. and they were slight
* Bernd Petrovitsch <[EMAIL PROTECTED]> schrieb:
> > Basically yes. But if you have a big number of packages (or a huge package)
> > which you didn't write yourself, there will be tests which run executables.
> > Figuring out what all the tests are supposed to test in a complex unknown
> > soft
On Fri, Jun 13, 2008 at 7:13 PM, Bill Traynor <[EMAIL PROTECTED]> wrote:
>> It's nice to see we have so many options and related people and pros
>> to it are available around.
>>
>> IMO there should be some sort of effort to standardize the tool-chains
>> and build environments coherently with the
* Alexander Neundorf <[EMAIL PROTECTED]> schrieb:
> In general, cross compiling is not hard. You just have to call the cross
> toolchain, give it the correct parameters, search files in the right location
> and ... make sure you don't test stuff by running programs.
Same with carefully written
* Jamie Lokier <[EMAIL PROTECTED]> schrieb:
> Relying on 'nm 'finding the variable, and not accidentally matching
> another variable with the wrong value, does not work for all C
> environments. E.g. some compile to compressed executables; some
> produce intermediate objects with incomplete or la
* Jamie Lokier <[EMAIL PROTECTED]> schrieb:
> Enrico Weigelt wrote:
> > But: the question is whether you'll need such a test at all
> > or if just using sizeof() at the right place won't do the trick ;-P
>
> It's best to do that if you can, and nearly always possible. There
> are a few coding tec
* Rob Landley <[EMAIL PROTECTED]> schrieb:
> Current compilers have a "build at once" mode where they suck the whole
> project in and run the optimizer on it at once, resulting in noticeably
> smaller and faster output at the expense of needing buckets of memory to hold
> all the source code an
Enrico Weigelt wrote:
> But: the question is whether you'll need such a test at all
> or if just using sizeof() at the right place won't do the trick ;-P
It's best to do that if you can, and nearly always possible. There
are a few coding techniques - especially performance sensitive - where
that'
Bill Traynor wrote:
> Maybe I'm being dense, but what's specifically wrong with the current
> toolchain universe?
Back in ye olde days, you could download GCC and Binutils from
gnu.org, configure for whatever is your architecture, and most times
it just worked.
For some reason, that stopped a whi
* Matthieu CASTET <[EMAIL PROTECTED]> schrieb:
> >How does it do that compile-time numeric comparison ?
> >
> for example you could do
>
> int test[my comparaison];
>
> if my comparaison < 0, the compilation should abort.
Cool trick :)
So, eg if you find out wether some type has an specific si
* Samuel Robb <[EMAIL PROTECTED]> schrieb:
> When you have a one- or two-line fix, and face Yet Another round of
> finding the right mailing list, identifying the right maintainers,
> figuring out the right way to submit a bug and a patch, and then have to
> spend the next 3 weeks explaining how n
Alexander Neundorf wrote:
On Friday 13 June 2008 15:17:54 you wrote:
Bernd Petrovitsch wrote:
Actually the size of ints (or any other type) can be easily deduced
without running a (for the target) compiled binary:
- compile the binary (for the target) with an initialized variable with
that va
* Jim Freeman <[EMAIL PROTECTED]> schrieb:
> And I'm just betting that when he said "push ... fixes ... out"
> he meant "work to get them incorporated back upstream", not just
> make them available to requesters.
Exactly.
That's the essence of opensource development:
Working together, instead of
> It's nice to see we have so many options and related people and pros
> to it are available around.
>
> IMO there should be some sort of effort to standardize the tool-chains
> and build environments coherently with the kernel. I think its a prime
> time to work around all the possibilities and st
On Thu, Jun 12, 2008 at 3:02 PM, Mike Frysinger <[EMAIL PROTECTED]> wrote:
>>> people cant even write proper *native* makefiles. mtd-utils for example ;).
>>
>> What's wrong with it? I'll fix it.
>
> is [EMAIL PROTECTED] not the place to post ? that's where
> i sent the first fix yesterday ... n
>> 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
On Friday 13 June 2008 15:17:54 you wrote:
> Bernd Petrovitsch wrote:
> > Actually the size of ints (or any other type) can be easily deduced
> > without running a (for the target) compiled binary:
> > - compile the binary (for the target) with an initialized variable with
> > that value.
> > - u
On Thu, 2008-06-12 at 16:02 -0600, Jim Freeman wrote:
> Most vendors these days have finally gotten the clue that sources/changes
> have to be made available to downstream requesters, but far fewer
> are sufficiently self-enlightened to figure out that changes need to
> be accepted upstream for the
On Fre, 2008-06-13 at 14:17 +0100, Jamie Lokier wrote:
> Bernd Petrovitsch wrote:
> > Actually the size of ints (or any other type) can be easily deduced
> > without running a (for the target) compiled binary:
> > - compile the binary (for the target) with an initialized variable with
> > that va
On Thu, Jun 12, 2008 at 3:02 PM, Mike Frysinger <[EMAIL PROTECTED]> wrote:
>>> people cant even write proper *native* makefiles. mtd-utils for example ;).
>>
>> What's wrong with it? I'll fix it.
>
> is [EMAIL PROTECTED] not the place to post ? that's where
> i sent the first fix yesterday ... n
Bernd Petrovitsch wrote:
> Actually the size of ints (or any other type) can be easily deduced
> without running a (for the target) compiled binary:
> - compile the binary (for the target) with an initialized variable with
> that value.
> - use cross nm (or a similar tool) to read it from there.
It's nice to see we have so many options and related people and pros
to it are available around.
IMO there should be some sort of effort to standardize the tool-chains
and build environments coherently with the kernel. I think its a prime
time to work around all the possibilities and standardize s
Daniel THOMPSON wrote:
James Chapman wrote:
Mike Frysinger wrote:
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 peop
On Thu, Jun 12, 2008 at 6:12 PM, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
...
> meooowww! :-) but at the risk of dragging this even further
> off-topic, i am *constantly* asked by people how to set up makefiles
> for their software project, and what would be nice is a small
> collection of exa
On Friday 13 June 2008 12:03:53 you wrote:
> On Fre, 2008-06-13 at 11:06 +0200, Alexander Neundorf wrote:
...
> > > - rewrite generated pkg_config files after generation.
> > > Yes, that's pretty ugly.
> > > But perhaps I was just too dumb to find the correct solutions.
> >
> > Can you please expla
On Fri, 2008-06-13 at 13:15 +0200, Geert Uytterhoeven wrote:
> > For minimal file systems with a select handful of tools which can be
> > tested exhaustively, it's not so bad. But for any 'full-featured'
> > userspace, I think cross-compilation is completely insane.
>
> So, how does OpenWRT manage
On Thu, 12 Jun 2008, 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 write proper *
On Thu, 12 Jun 2008, David Woodhouse wrote:
> On Thu, 2008-06-12 at 11:28 -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.cache (or
> > equ
On Fre, 2008-06-13 at 08:43 +0200, Alexander Neundorf wrote:
> 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 qu
On Fre, 2008-06-13 at 11:06 +0200, Alexander Neundorf wrote:
> On Friday 13 June 2008 10:38:36 you wrote:
> > On Fre, 2008-06-13 at 08:43 +0200, Alexander Neundorf wrote:
> ...
> > > Well, IMO this makes it sound too easy.
> > > If you write portable software, you have to do platform checks.
> > >
On 2008-06-12 22:52 +0500, 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 a
James Chapman wrote:
> Mike Frysinger wrote:
>> 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
>
On Friday 13 June 2008 11:12:00 you wrote:
> On Fri, 2008-06-13 at 11:06 +0200, Alexander Neundorf wrote:
> > > Why on earth does someone need this explicitly during the build?
> > > If you have portable software, all of that should be hidden in the code
> > > and use "sizeof(int)".
> >
> > From th
On Fri, 2008-06-13 at 11:06 +0200, Alexander Neundorf wrote:
> > Why on earth does someone need this explicitly during the build?
> > If you have portable software, all of that should be hidden in the code
> > and use "sizeof(int)".
>
> From the "developer of a buildsystem" POV: there will be user
On Friday 13 June 2008 10:50:28 you wrote:
> On Don, 2008-06-12 at 19:25 -0500, Rob Landley wrote:
...
> > in C (anybody remember X11's imake?) KDE switched to cmake:
>
> That generated "only" a Makefile IIRC.
Yes, cmake doesn't actually build the stuff itself, it generates input files
for the a
On Friday 13 June 2008 10:38:36 you wrote:
> On Fre, 2008-06-13 at 08:43 +0200, Alexander Neundorf wrote:
...
> > Well, IMO this makes it sound too easy.
> > If you write portable software, you have to do platform checks.
> > Basically they can be done by
> > -checking for the existence of files
>
On Don, 2008-06-12 at 19:25 -0500, Rob Landley 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,
>
Mike Frysinger wrote:
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
On Thu, 2008-06-12 at 19:25 -0500, Rob Landley wrote:
> Make doesn't scale.
Make scales just fine. The only real problem with make is that it's a
complete pain to debug.
--
dwmw2
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROT
77 matches
Mail list logo
