* modules.dep and depmod.pl
From: Linus Walleij @ 2008-06-13 23:33 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <63386a3d0806131611g61ad6ab1t16bc68ab6407a8dc@mail.gmail.com>
Hi,
what are other embedded developers experience with using the
script "depmod.pl" from BusyBox to create
installdir/lib/modules/<version>/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 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.
Is there anyone beside me who would like to see this integrated
into scripts/ in the kernel to get some default modules.dep for
a read-only rootfs also when doing cross compilation, or am I
totally going down the wrong lane here?
Yours,
Linus Walleij
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Robert Schwebel @ 2008-06-13 23:19 UTC (permalink / raw)
To: Jamie Lokier; +Cc: Alexander Neundorf, linux-embedded
In-Reply-To: <20080613222523.GA28805@shareable.org>
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 more
difficult it becomes to test all the combinations.
> Some other packages _should_ have more options, but don't because it's
> too unwieldy to make them highly configurable with Autoconf. Imho,
> Kconfig would be good for more programs than it's currently used for,
> and could be made to work with those --enable/--with options: you'd be
> able to configure them entirely on the command line, or interactively
> with "./configure --menu" (runs menuconfig), or with a config file.
That's exactly what ptxdist does: add a Kconfig frontend to the
configurable switches. It does it for the user's convenience, although
the currently implemented method is really developer-unfriendly (but we
care about our users first).
But it's of absolutely no use to whine about the fact that the world is
such a curel place. *If* Kconfig had been there 20 years ago ... *if*
90% of the packages out there would have been Kconfig instead of
autotools... We have to live with *reality*, and reality is that
autotools solve real world problems, and they offer *one* standard user
interface to package building. I can cross build almost all autotoolized
packages in exactly the same way and people are used to it. All other
build systems I've seen invented their very special way of doing things,
leading to wheel-reinvention all over the place.
> The "make" / "make install" part is easy to retain even with other
> build systems, using a trivial Makefile which calls the other tools.
I still don't understand why all the scons, cmakes and jams out there
don't even try to provide the *standard* user interface everyone is used
to on a unix system.
> Lots of packages need special tools or other software installed to
> build them; this is no different.
autotools need only a shell and make
> Perhaps it might even be possible to write a very small, portable,
> specialised alternative to Make which is small enough to ship with
> packages that use it?
Why on earth would one want to reinvent make?
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Jamie Lokier @ 2008-06-13 22:25 UTC (permalink / raw)
To: Robert Schwebel; +Cc: Alexander Neundorf, linux-embedded
In-Reply-To: <20080613185157.GT13599@pengutronix.de>
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 that 'configure && make && make install' plus the usuall
> --enable-foo / --disable-foo / --with-bla=blub semantics is simply *the*
> standard way of configuring stuff for unix systems. You don't need fancy
> tools, you get cross compiling almost for free and unix people simply
> know how to use it.
A trouble with that is some packages have hundreds of user-selectable
options - or even thousands. It is unfeasible to use --enable-foo
options for all of those when configuring then.
Some other packages _should_ have more options, but don't because it's
too unwieldy to make them highly configurable with Autoconf. Imho,
Kconfig would be good for more programs than it's currently used for,
and could be made to work with those --enable/--with options: you'd be
able to configure them entirely on the command line, or interactively
with "./configure --menu" (runs menuconfig), or with a config file.
The "make" / "make install" part is easy to retain even with other
build systems, using a trivial Makefile which calls the other tools.
Lots of packages need special tools or other software installed to
build them; this is no different.
Perhaps it might even be possible to write a very small, portable,
specialised alternative to Make which is small enough to ship with
packages that use it?
-- Jamie
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: David VomLehn @ 2008-06-13 22:24 UTC (permalink / raw)
To: James Chapman; +Cc: weigelt, Linux Embedded Maillist
In-Reply-To: <48519837.1090902@katalix.com>
James Chapman wrote:
> David VomLehn wrote:
>> Enrico Weigelt wrote:
>>> * Rob Landley <rob@landley.net> 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, etc) tends to have about 200 packages that cross
>>>> compile more or less easily, another 400 or so that can be made to
>>>> cross compile with _lot_ of effort and a large enough rock, and
>>>> then the project stalls at about that size.
>>>>
>>>
>>> The problem is: most embedded projects don't make really
>>> general-purpose
>>> fixes (instead strange things like hacking up autogenerated files),
>>> so they can't feed back to upstream.
>>>
>>> IMHO, a huge waste of working time.
>>>
>> 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. I also have a fairly broad scope, so I'm in on code
>> reviews for a number of open source components. At each such review,
>> one of my criteria is whether the change is suitable for pushing back
>> to the appropriate community. This is not necessarily a short-term
>> way to make friends, but the long-term effects will be good both for
>> the company and for the open source community in general.
>>
>> Now, if we can only get the time to actually push all the backlogged
>> fixes out...
>
> 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!
>
I guess I'm making a distinction that wasn't clear. We *have* to make
the code available, and I can assure you that Cisco is very aware of our
obligations in this area and I spend a fair amount of my time trying to
ensure they are met.
I used the term "push" to mean getting patches ready, posting them to the
appropriate mailing lists, revising them in light of comments, and doing
everything else necessary to get them incorporated into the kernel source base.
"Pushing" is a lot more work than just making source available, but also yield
much more productive long term results for everyone.
--
David VomLehn, dvomlehn@cisco.com
The opinions expressed herein are likely mine, but might not be my employer's...
- - - - - Cisco - - - - -
This e-mail and any attachments may contain information which is confidential,
proprietary, privileged or otherwise protected by law. The information is solely
intended for the named addressee (or a person responsible for delivering it to
the addressee). If you are not the intended recipient of this message, you are
not authorized to read, print, retain, copy or disseminate this message or any
part of it. If you have received this e-mail in error, please notify the sender
immediately by return e-mail and delete it from your computer.
^ permalink raw reply
* about size optimizations (Re: Not as much ccache win as I expected)
From: Oleg Verych @ 2008-06-13 21:52 UTC (permalink / raw)
To: linux-embedded, linux-kbuild
>> 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
build with something like "whole-kernel-at-time" optimising
compiler option:
for file in $all_core_files
do gcc $opt -E $file >>core_kernel.c
done && gcc $opt code_kernel.c -o vmlinux.c.o
# same for some special parts and asm
do_foo
# do final link
do_vmlinux
I've had something like that once for `dash` and had few
percents of size reduction. It would be interesting to
implement and check this in linux.
Also i've many things to point-tune/point-remove based on
usage patterns/source patterns, which can be easily removed by
stream text editor from sources. These like not needed
* syscalls,sysctl, ioctls
* fields in data structures/sources for handling them
* code branches or code blocks which are known (in particular
board / embedded case) to be useless etc. etc.
But all this requires non trivial source text editor or visual tools
for easy analysis, navigation, marking, RE generation and
build + run testing.
With mid-70 command line and `make` (even kbuild version)
or 20++ years old technology of text editors, it's not that trivial
to accomplish.
Some kind of IDE for kernel development is needed. Here
one will have all whitespace and code style policy, static
checks for stupid security holes, C mis-use, kernel API
mis-use, all those crutches in linux/scripts/* in one place
and applied right away.
Sorry, for this rant, but i see no developemnt here at all.
New schedulers, slab allocators, file systems are great.
But all this has nothing to do with fundamental developent
of the tools. Hardware is quite fast and have pretty much
of RAM/ROM/caches now, yet software just bloats.
The streaming, pre-cc text editing is the key, fine GCC is not.
--
sed 'sed && sh + olecom = love' << ''
-o--=O`C
#oo'L O
<___=E M
^ permalink raw reply
* Re: Not as much ccache win as I expected
From: Tim Bird @ 2008-06-13 21:10 UTC (permalink / raw)
To: Oleg Verych; +Cc: linux-embedded, linux-kbuild
In-Reply-To: <8499950a0806131354u7d2431b2n2df50b7b6c98f18d@mail.gmail.com>
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 build area
before the start of each test.
> (any versions, e.g. localversion, .version, aren't important, they are for
> modules ko and vmlinux, afaik)
Ok - this is helpful.
> kbuild is `ccache` on itself. Every *.o.cmd is kind of info `ccache`
> hashes (except things like stderr, gcc version) to check repeated
> rebuilds.
Yeah, I'm pretty impressed with how well kbuild avoids rebuilding
stuff in the first place.
Maybe I should just be grateful for any ccache hits I get.
Thanks,
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: Not as much ccache win as I expected
From: Oleg Verych @ 2008-06-13 20:54 UTC (permalink / raw)
To: Tim Bird; +Cc: linux-embedded, linux-kbuild
In-Reply-To: <4852C51D.30206@am.sony.com>
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 of source/kconfig changes are made for every build?
(any versions, e.g. localversion, .version, aren't important, they are for
modules ko and vmlinux, afaik)
[...]
> Is there anything else obvious which is prevents ccache from
> working well with a kernel build (that is, anything else that
> would, for otherwise identical C files with a similar build,
> cause a difference?)
kbuild is `ccache` on itself. Every *.o.cmd is kind of info `ccache`
hashes (except things like stderr, gcc version) to check repeated
rebuilds. Also kconfig<->kbuild link via header magic may confuse
general-purpose `ccache`.
For rebuilds of the same codebase, it's better to use separate
kbuild object output directories.
> Any tips would be appreciated.
Just my handwaving, but test with couple core config symbols
toggling, shows only one `ccache` hit.
olecom@flower:/mnt/zdev0/blinux$ CCACHE_DIR=_ccache/ ccache -s
cache directory _ccache/
cache hit 1133
cache miss 1141
called for link 28
not a C/C++ file 64
no input file 282
files in cache 2282
cache size 15.7 Mbytes
max cache size 976.6 Mbytes
olecom@flower:/mnt/zdev0/blinux$ make menuconfig # toggle
olecom@flower:/mnt/zdev0/blinux$ diff -u1 .config.old .config
--- .config.old 2008-06-13 22:52:37.000000000 +0200
+++ .config 2008-06-13 23:01:07.000000000 +0200
@@ -3,3 +3,3 @@
# Linux kernel version: 2.6.24
-# Fri Jun 13 22:52:37 2008
+# Fri Jun 13 23:01:07 2008
#
@@ -67,3 +67,4 @@
CONFIG_POSIX_MQUEUE=y
-# CONFIG_BSD_PROCESS_ACCT is not set
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set
olecom@flower:/mnt/zdev0/blinux$
olecom@flower:/mnt/zdev0/blinux$ CCACHE_DIR=_ccache/ ccache -s
cache directory _ccache/
cache hit 1134
cache miss 1879
called for link 33
not a C/C++ file 79
no input file 401
files in cache 3758
cache size 28.1 Mbytes
max cache size 976.6 Mbytes
olecom@flower:/mnt/zdev0/blinux$
--
sed 'sed && sh + olecom = love' << ''
-o--=O`C
#oo'L O
<___=E M
^ permalink raw reply
* Re: Kernel boot problem on IXP422 Rev. A
From: Tim Bird @ 2008-06-13 20:05 UTC (permalink / raw)
To: Rob Landley; +Cc: Glenn Henshaw, linux-embedded
In-Reply-To: <200806131233.50360.rob@landley.net>
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 developers are several versions behind, with
no easy way to use the current kernel version. For example, a
common scenario is starting with a kernel that comes with a board
(with source mind you), where the kernel came from the semi-conductor
vendor, who paid a Linux vendor to do a port, and it was
released in a time-frame relative to the Linux vendor's
product schedule.
This is how you end up having people STARTING projects today
using a 2.6.11 kernel. (I know of many).
The real difficulty, when a developer finds themselves in
this position, is how to forward-port the BSP code necessary to
reproduce the bug in the current kernel. Often, the code
is not isolated well enough (this is a vendor problem that
really needs attention. If you have the BSP in patches, it
is usually not too bad to forward port even across several
kernel versions. But many vendors don't ship stuff this way.)
The fact is, that by a series of small steps and delays by
the linux vendor, chip vendor, board vendor,
and product developer the code is out-of step.
It's easy to say "don't get in this position", but
this even happens when everyone is playing nice and actively
trying to mainline stuff. BSP support in arch trees often
lag mainline by a version or two.
The number of parties involved here is why, IMHO, it has
taken so long to make improvements in this area.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Johannes Stezenbach @ 2008-06-13 19:43 UTC (permalink / raw)
To: Tim Bird
Cc: Bill Traynor, David Woodhouse, linux-embedded-owner, Rob Landley,
Robert P. J. Day, Mike Frysinger, Greg Ungerer, Sam Ravnborg,
Leon Woestenberg, linux-embedded
In-Reply-To: <4852C026.8060203@am.sony.com>
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 stopped, though.
http://sourceforge.net/projects/bashdb/
Johannes
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Rob Landley @ 2008-06-13 19:14 UTC (permalink / raw)
To: Alexander Neundorf; +Cc: linux-embedded
In-Reply-To: <200806131106.18487.neundorf@eit.uni-kl.de>
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 deployment that signal handling in the mips version of
perl is using the x86 signal numbers and they're not the same: priceless.
> > The only simple solution so far (without diving into the implementation
> > and searching for root causes) were AFAICS:
> > - do not use libtool for linking (as the link line as such without
> > libtool works as expected)
>
> Yes, libtool sucks, it's the wrong solution to the problem.
> (and CMake doesn't use it).
Nothing on Linux really _uses_ libtool. It's supposed to act as a NOP wrapper
around the linker on any Linux target. (It's there for things like Sparc and
HPUX).
The fact that libtool manages to do its nothing _wrong_ so often would be
hilarious if it wasn't such a pain. Just uninstall libtool before trying to
build for a Linux target, this should never cause any problems and will save
you lots of headaches.
> > 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)".
According to the LP64 standard which pretty much all modern Unixes adhere to
(including both Linux and MacOS X) sizeof(int) is always 4. Guaranteed.
The LP64 standard:
http://www.unix.org/whitepapers/64bit.html
The LP64 rationale:
http://www.unix.org/version2/whatsnew/lp64_wp.html
The insane legacy reasons windows doesn't do this, but in fact sizeof(int)
will still be 4 there anyway:
http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx
Just FYI. :)
> But this was not the point. My point was: testing something by running an
> executable can be _a lot_ easier than testing the same without running
> something.
I think building natively under qemu is the easy way, yes. :)
> Alex
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: cross-compiling alternatives
From: Robert Schwebel @ 2008-06-13 19:10 UTC (permalink / raw)
To: Bernd Petrovitsch; +Cc: weigelt, Linux Embedded Maillist
In-Reply-To: <1213382709.17853.79.camel@tara.firmix.at>
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 prefix via env on the pkg-config call.
Ah, great, must be a new feature. Will have to integrate that into
ptxdist... at the moment we fix it with a wrapper script.
> The problem is that the build-time (cross-)linker needs to find the
> (cross-compiled) lib under
> /my/build/host/target/environment/opt/foo/lib at link time and the
> shared linker under /opt/foo/lib at run-time.
pkg-config is fixable (our wrapper in PTXdist does the right thing wrt.
buildtime vs. runtime paths).
> Hmm, after digging into that old project, it seems that libtool and
> the .la files were the problem.
Right, libtool's paths are critical: libtools isn't sysroot aware, and
it seems to be not easily fixable.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: Kernel boot problem on IXP422 Rev. A
From: Marcus Tangermann @ 2008-06-13 19:07 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <4851BC65.4030501@snapgear.com>
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.
> Enable the kernels CONFIG_DEBUG_LL and it may give you some
> early debug output (like an id not supported message). That
> assumes a serial console...
Will try that,
Today I downloaded the snapgear distribution and tried whether i can
generate a kernel image that works with it...and it boots (2.4 and 2.6)
:-) Then I downloaded a fresh 2.6.25 kernel and compiled it with
toolchain from the snapgear homepage...and it does not boot. Are there
any special patches in the 2.6.19-uc1 from the snapgear distribution
that might have influence on a IXP422 based board?
Additionally, it seems that we may have a little problem in the
bootloader (uboot) when passing kernel parameters (e.g."setenv bootargs
console=ttyS0,115200"). Setting such a paramter causes the same problem
with a dying kernel. Maybe there is a relation.
Regards
Marcus
^ permalink raw reply
* Not as much ccache win as I expected
From: Tim Bird @ 2008-06-13 19:06 UTC (permalink / raw)
To: linux-embedded; +Cc: linux-kbuild
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 found that the hit rate on the cache was not very good.
$ ccache -s
cache directory /home/tbird/.ccache
cache hit 74416
cache miss 59400
called for link 87252
compile failed 21
not a C/C++ file 143449
no input file 49336
files in cache 42844
cache size 1.8 Gbytes
max cache size 2.0 Gbytes
Thinking that the problem might be having a unique version for
every build (and that this change flowed to every file via the
version.h file), I tried building without this change. I saw
an improvement, but not much.
Is there anything else obvious which is prevents ccache from
working well with a kernel build (that is, anything else that
would, for otherwise identical C files with a similar build,
cause a difference?)
Any tips would be appreciated.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Bill Traynor @ 2008-06-13 19:00 UTC (permalink / raw)
To: Tim Bird
Cc: Bill Traynor, David Woodhouse, linux-embedded-owner, Rob Landley,
Robert P. J. Day, Mike Frysinger, Greg Ungerer, Sam Ravnborg,
Leon Woestenberg, linux-embedded
In-Reply-To: <4852C026.8060203@am.sony.com>
> 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 Makefile to show
> you the values of certain things. It is helpful, but not an interactive
> debugger.
>
> However, the guy who wrote that article did indeed write a full
> Makefile debugger. I took it for a spin, and found that it worked as
> advertised on a simple Makefile. I tried it on the kernel Makefile, but
> without success (but I didn't try very hard).
>
> YMMV. I put some of the resources and info I found at:
> http://elinux.org/Debugging_Makefiles
>
> The link from the package's README doesn't work, but here's a link
> I found to an article about the debugger:
> http://www.cmcrossroads.com/content/view/6479/120/
The links in the README worked fine for me. FWIW, the authors homepage is
here: http://gmd.sf.net He's written a self-published book on GNU Make, it
would seem.
>
> -- Tim
>
> =============================
> Tim Bird
> Architecture Group Chair, CE Linux Forum
> Senior Staff Engineer, Sony Corporation of America
> =============================
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Sam Ravnborg @ 2008-06-13 18:55 UTC (permalink / raw)
To: Tim Bird
Cc: Bill Traynor, David Woodhouse, linux-embedded-owner, Rob Landley,
Robert P. J. Day, Mike Frysinger, Greg Ungerer, Leon Woestenberg,
linux-embedded
In-Reply-To: <4852C026.8060203@am.sony.com>
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=true
>
> The article above shows some macros you can add to your Makefile to show
> you the values of certain things. It is helpful, but not an interactive
> debugger.
>
> However, the guy who wrote that article did indeed write a full
> Makefile debugger. I took it for a spin, and found that it worked as
> advertised on a simple Makefile. I tried it on the kernel Makefile, but
> without success (but I didn't try very hard).
>
> YMMV. I put some of the resources and info I found at:
> http://elinux.org/Debugging_Makefiles
>
> The link from the package's README doesn't work, but here's a link
> I found to an article about the debugger:
> http://www.cmcrossroads.com/content/view/6479/120/
Quite impressive what he got out of the make features.
The kernel does a few unusual tricks so I do understand
why it does not work there.
Speaking about the kernel...
Try "make V=2" one day to see why a target are build. It is quite useful
when a small change results in much more being build than you expected.
But this is kernel specific and not a general feature.
Sam
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Robert Schwebel @ 2008-06-13 18:51 UTC (permalink / raw)
To: Alexander Neundorf; +Cc: linux-embedded
In-Reply-To: <200806130830.52734.neundorf@eit.uni-kl.de>
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 install' plus the usuall
--enable-foo / --disable-foo / --with-bla=blub semantics is simply *the*
standard way of configuring stuff for unix systems. You don't need fancy
tools, you get cross compiling almost for free and unix people simply
know how to use it.
All the cool kids out there who think they know everything better
usually start with "I hate autotools", then invent something which
solves 0.1% of the problems (including their very special problem) and
tell the rest of the world that their shiny new tools is *soooo cooool*.
Been there, seen that. I maintain > 500 packets in PTXdist and guess
which ones make 90% of the problems. Hint: they are not related to
autotools ...
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Robert Schwebel @ 2008-06-13 18:47 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Rob Landley, Tim Bird, David Woodhouse, Greg Ungerer,
Leon Woestenberg, linux-embedded
In-Reply-To: <20080613031104.GA29667@uranus.ravnborg.org>
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 solely using GNU make
> features -- no preprocessing is required.
Last time I looked it had *at least* 0.1% of the autotools features
supported :-)
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Robert Schwebel @ 2008-06-13 18:45 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: Linux Embedded Maillist
In-Reply-To: <20080612183735.GE7423@nibiru.local>
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
spent your time for improving libtool ...
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: cross-compiling alternatives
From: Bernd Petrovitsch @ 2008-06-13 18:45 UTC (permalink / raw)
To: weigelt; +Cc: Linux Embedded Maillist
In-Reply-To: <20080613151634.GJ11760@nibiru.local>
On Fre, 2008-06-13 at 17:16 +0200, Enrico Weigelt wrote:
> * Bernd Petrovitsch <bernd@firmix.at> 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
> > > software project is not trivial.
> >
> > Yes, you get used to find the relevant lines in config.log and similar
> > with `grep` and similar tools;-)
>
> Which are different on each package. So you have to configure each package
ACK.
> for each target manually, which leads the whole point of autoconf
> ad absurdum ;-o
Yup.
[...]
> > pkg-config generated (and generates? - I didn't check recently)
> > references to libraries including the full absolute path (which is the
> > one at build time. And at run-time there is usually
> > no /home/bernd/src/... or where some build may just run).
>
> Recent pkg-config supports sysroot.
FC-6 has "only" 0.21.
> So you simply build your .pc files as usual (w/o sysroot prefix) and
> set the sysroot prefix via env on the pkg-config call.
From a quick glance over the man page of 0.23, yes.
> > > Can you please explain ? How do the generated pkg_config files look like ?
> > > Ahh, you mean they contain e.g -L/my/build/host/target/environment/opt/foo/lib
> > > instead of just -L/opt/foo/lib ?
>
> Then you've got a broken .pc file ;-P
The problem is that the build-time (cross-)linker needs to find the
(cross-compiled) lib under /my/build/host/target/environment/opt/foo/lib
at link time and the shared linker under /opt/foo/lib at run-time.
Hmm, after digging into that old project, it seems that libtool and
the .la files were the problem.
> > Yes. And even worse the compiled lib "foo" had explicit dependencies (on
> > lib "bar") on
> > "/my/build/host/target/environment/opt/bar/lib/libbar.so.1.2.3.4".
>
> And that's even more broken.
Yup. Maybe it was a result of my trial to make libtool work somehow ..
> > And BTW pkg-config didn't support the concept of a "DESTDIR" variable
> > (and I don't care about the name of that variable).
>
> No, why should it ?! It does not install anything.
But it may "use" installed files.
> Probably you're looking for sysroot ?
Yes, very probably.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Tim Bird @ 2008-06-13 18:44 UTC (permalink / raw)
To: Bill Traynor
Cc: David Woodhouse, linux-embedded-owner, Rob Landley,
Robert P. J. Day, Mike Frysinger, Greg Ungerer, Sam Ravnborg,
Leon Woestenberg, linux-embedded
In-Reply-To: <2a5b3cfbb9eccd7885735ea46b115541.squirrel@www.geekisp.com>
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 Makefile to show
you the values of certain things. It is helpful, but not an interactive
debugger.
However, the guy who wrote that article did indeed write a full
Makefile debugger. I took it for a spin, and found that it worked as
advertised on a simple Makefile. I tried it on the kernel Makefile, but
without success (but I didn't try very hard).
YMMV. I put some of the resources and info I found at:
http://elinux.org/Debugging_Makefiles
The link from the package's README doesn't work, but here's a link
I found to an article about the debugger:
http://www.cmcrossroads.com/content/view/6479/120/
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Rob Landley @ 2008-06-13 18:01 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded
In-Reply-To: <48515978.8040603@billgatliff.com>
[-- Attachment #1: Type: text/plain, Size: 3389 bytes --]
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
> > itself. Autoconf/libtool damage is an entirely different problem :-)
>
> At first glance, it seems like checkincludes.pl could be duplicated by
> egrep | uniq | wc vs. egrep | wc. Not quite sure what checkversion.pl is
> trying to do.
There's a difference between "this is a development tool used while modifying
source code" and "this is needed to build".
There are situations where it's ok to have a dependency on X11/qt/gtk, such
as "make xconfig". This is _not_ the same as adding such dependency to "make
modules".
So far, none of the perl dependencies prevent you from building the kernel on
a system that didn't have perl (or didn't have the right version of perl).
> So maybe we could _reduce_ dependency on perl, if there's any advantage to
> gain by doing so. But the kernel build machinery isn't dependent on very
> many other systems (just tcl, bash and gcc-core),
There's no tcl dependency in the build. (Yes, I actually know this.)
Part of my FWL work involves getting the system to rebuild itself under
itself. (The packages you need to make a minimal self-bootstrapping system
are gcc, binutils, make, bash, uClibc, linux, and busybox/toybox). I'm seven
commands away from doing this.
I know this because I made a horrible little wrapper (attached, it really is
sad) which touched a file with the name it was called as and then exec()ed
the actual executable out of another directory. Then I populated a directory
with symlinks to every executable in $PATH (for i in `echo $PATH |
sed 's/:/ /g'`;do for j in `ls $i`; do ln -s $i/$j $j; done; done), and
another directory of similar symlinks to my wrapper. I then ran my build
with that wrapper directory at the start of $PATH and let the wrapper
populate a directory with all the executables that actually got called during
the build. Then I filled up a directory with those executables, tried to run
the build, and figured out why it broke. (The above approach won't find
calls to /bin/bash and a few other things, but it's a good start.)
Most of the point of my ./host-tools.sh wrapper in the FWL build is to
populate a directory with the command line utilities mini-native will have in
it (specifically the busybox/toybox versions, not the ones in the host
system), and set $PATH equal to that directory and only that directory. This
way I know the system will build under itself because that's how it's
building in the first place.
Currently, I need to grab the following out of the host system:
for i in ar as nm cc gcc make ld bzip2 find install od sort diff wget
do
[ ! -f "${HOSTTOOLS}/$i" ] && (ln -s `which $i` "${HOSTTOOLS}/$i" || dienow)
done
The first seven are the needed bits of the host toolchain (you'd think "strip"
would be in there, but it turns out those packages only ever use
$TARGET-strip). The last seven are the ones that are either missing or had
various bugs in the version of busybox I'm using that prevented the build
from working right.
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
[-- Attachment #2: wrappy.c --]
[-- Type: text/x-csrc, Size: 909 bytes --]
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <fcntl.h>
char blah[65536];
#define ROOTPATH "/home/landley/firmware/firmware"
int main(int argc, char *argv[], char *env[])
{
char *p, *p2;
int i, fd;
p2 = strrchr(*argv, '/');
if (!p2) p2=*argv;
else p2++;
p=blah + sprintf(blah, "%s ",p2);
for (i=1; i<argc; i++) {
p += sprintf(p, "\"%s\" ",argv[i]);
}
p[-1]='\n';
// Log the command line
fd=open(ROOTPATH "/loggy.txt",O_WRONLY|O_CREAT|O_APPEND,0777);
write(fd, blah, strlen(blah));
close(fd);
// Touch the file that got used.
sprintf(blah,ROOTPATH "/used/%s", p2);
close(open(blah, O_WRONLY|O_CREAT, 0777));
// Hand off control to the real executable
sprintf(blah, ROOTPATH "/handoff/%s", p2);
execve(blah, argv, env);
// Should never happen, means handoff dir is set up wrong.
dprintf(2,"Didn't find %s\n", *argv);
exit(1);
}
^ permalink raw reply
* Re: Kernel boot problem on IXP422 Rev. A
From: Rob Landley @ 2008-06-13 17:33 UTC (permalink / raw)
To: Glenn Henshaw; +Cc: linux-embedded
In-Reply-To: <17882748-2E1B-4DB4-82FD-C5D5C4E62CC8@logicaloutcome.ca>
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 translates to:
There's a decent chance whatever bug you're encountering is one we've already
fixed. As volunteers, we're not really interested in reinventing the wheel.
We're trying to come up with a better kernel, and debugging old version may
help you but it doesn't help us.
If you try the current version and the problem persists, we're happy to help
you debug it, because this makes the kernel better for all of us. If you
have your own reason to want to stick with an old version, there are plenty
of vendors happy to take your money to make this work for you, but you've
sacrificed the support of the volunteer community in doing so.
> Many embedded devices can't upgrade kernels easily because of
> customer requirements and certifications.
I'm aware of this. That's what vendors are for.
> For example, I have worked
> on Linux based applications in the financial industry. A kernel
> upgrade here is viewed as equivalent to switching from Windows XP to
> Vista, and requires significant effort in certification testing from
> the customer's perspective. This doesn't make economic sense for
> either party.
Making economic sense and making sense to open source volunteers are two
different sets of criteria. Part of "making economic sense" is realizing
that you must replace volunteer effort with paid effort to do it that way.
The procedure is:
1) Try to reproduce the bug under a current kernel. (Set up a _test_ system.)
If you can't reproduce it:
Git bisect to find the fix, then backport it to your kernel if possible.
If you can reproduce it:
Demonstrate the bug to the community in the current kernel, get help
debugging the problem, then backport the fix to your kernel if possible.
> Often developers not working in the embedded space don't understand
> this reality.
Often developers who _are_ working in the embedded space don't understand how
and why volunteers collaborate through the internet in this thing
called "open source development".
> Helpful responses on what does/does not work would be more
> appreciated.
He did give a helpful response. You didn't understand it. I elaborated.
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Makefile debugger
From: linux-embedded-owner @ 2008-06-13 17:30 UTC (permalink / raw)
To: linux-embedded-owner
Cc: David Woodhouse, Rob Landley, Robert P. J. Day, Mike Frysinger,
Tim Bird, Greg Ungerer, Sam Ravnborg, Leon Woestenberg,
linux-embedded
In-Reply-To: <20080613100231.btmn0xgmqog884cs@localhost>
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
Tel.: (+30) 697 593 3428
Fax.:(+30 210) 684 7881
URL: www.reliableembeddedsystems.com
Quoting linux-embedded-owner@reliableembeddedsystems.com:
> 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 Embedded Systems
> Consulting Training Engineering
> Tel.: (+30) 697 593 3428
> Fax.:(+30 210) 684 7881
> URL: www.reliableembeddedsystems.com
>
>
> Quoting David Woodhouse <dwmw2@infradead.org>:
>
>> 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 majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Firmware Linux (was Re: Cross Compiler and loads of issues)
From: Rob Landley @ 2008-06-13 17:24 UTC (permalink / raw)
To: Shaz; +Cc: linux-embedded
In-Reply-To: <7b740b700806121052n2f98dfa4hc96ebfc1be5b6bbf@mail.gmail.com>
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 issues and don't know which
> will be the best alternative.
Did you try my FWL project? :)
http://landley.net/code/firmware
To build from source, go to http://landley.net/code/firmware/downloads and
grab the latest version (firmware-0.4.0.tar.bz2). Extract it, cd into it,
and run "./build.sh". That should list the available platforms, and then run
with the platform you like as an argument (ala "./build.sh powerpc").
The build.sh wrapper runs the other scripts in sequence:
./download.sh - downloads source code if you haven't already got it.
./host-tools.sh - compiles stuff on the host platform, (mostly optional).
./cross-compiler.sh - build a cross compiler toolchain for your target.
./mini-native.sh - Compile a kernel and root filesystem for your target.
./package-mini-native.sh - Create an ext2 image out of mini-native.
The other interesting scripts in the directory are:
./forkbomb.sh - Build every target (--nofork in series, --fork in parallel).
Calling with --fork is faster, but needs about 4 gigabytes of ram.
./run-emulator.sh - Boot one of the system images you just built under qemu.
Also sets up the distcc trick (see below).
If you don't feel like compiling any of the above yourself, you can download
prebuilt binary images from the same downloads link. The cross-compiler
directory has the prebuilt cross compilers for each target (for i686 and
x86_64 hosts). The mini-native directory has the prebuilt root filesystem
images as tarballs. And the system-image.sh directory has a tarball with
that same mini-native root filesystem as an ext2 image, a kernel for qemu,
and shell scripts to invoke qemu appropriately for each one:
./run-emulator.sh - Run qemu, booting to a shell prompt.
./run-with-home.sh - Calls run-emulator with a second hard drive image
hooked up as /dev/hdb and mounted on /home. (If you haven't got an
hdb.img in the directory it'll create an empty 2 gigabyte image and
format it ext3.)
./run-with-distcc.sh - Calls run-with-home with the distcc trick set up.
The reason "mini-native" is called that is because it's a minimal native
development environment. It contains gcc, binutils, make, linux kernel
headers, uClibc for your C library, and standard susv3 command line tools
(provided by the busybox and toybox packages). This is theoretically enough
to build the whole of Linux From Scratch (http://www.linuxfromscratch.org) or
bootstrap your way up to being able to natively build gentoo or debian using
their package management systems. (If you don't _want_ development tools in
your root filesystem, set the environment variable "BUILD_SHORT=1" before
running ./mini-native.sh. That'll also move it out of /tools and up to the
top level.)
In practice, the environment is still missing seven commands (bzip2, find,
install, od, sort, diff, and wget) needed to rebuild itself under itself.
(The busybox versions were either missing or had a bug.) I'm working on that
for the next release.
The distcc trick is for speeding up native builds by using distcc to call out
to the cross compiler. Running the cross compiler on the host system is
faster, but cross compiling is very brittle. This approach does a native
build under the emulator, but escapes the emulator for the actual compiling
part. I did a quick bench test compling make 3.81 (I had it lying around)
and it sped up the actual compile by a factor of 7. (Alas, it didn't speed
up the "./configure" part at all, just the "make" part.)
The ./emulator-build.sh script sets up the distcc trick using the files left
in the "build" directory after you build it yourself. (The cross compiler is
left in there, and the kernel and ext2 system images that got tarred up are
also left in there.) The ./run-with-distcc.sh script does it for
cross-compiler and system-image tarballs. (It needs one argument: You have
to tell it the path where you extracted the cross-compiler tarball.)
> I also went through the material provided freely by Free Electron but
> still I am not successful to build a custom kernel. Next I am trying
> MontaVista's kit. I just wish I don't get lost.
I'm happy to answer any questions about the stuff I did... :)
> Anyways, I liked the idea of Qemu based cross compiler. Is it possible
> for the inexperienced to get it working and emulate the exact model
> and devices.
That's what I'm trying to do. I've got armv4l, armv5l, mips (big endian),
mipsel (little endian), powerpc (a prep variant), i586, i686, and x86_64
working. They all work fine. Run "./smoketest.sh $ARCH" on each $ARCH after
building it to see the sucker boot up and compile "hello world" using distcc.
That means qemu has bootable kernel, serial port, emulates a hard drive,
uClibc is configured right, there's a working native toolchain, working cross
toolchain, working virtual network...
I've also got sh4 building (but qemu doesn't quite have enough support to boot
it yet: it can't emulate any boards with a hard drive attached). And I've
got sparc building and mostly booting, but it hangs trying to read
from /dev/console for reasons I haven't been motivated to track down because
I don't really know anyone still using sparc. And I've got most of an m68k
build config together but gcc is giving me an "internal compiler error"
trying to build uClibc. I've also poked at Alpha and blackfin a bit, but
again lack of sufficient qemu support takes some of the fun out of it.
Oh, and the powerpc emulated prep board/kernel don't agree how to shutdown the
power to the virtual board, so the qemu process doesn't exit. You have to
kill it. :P
I can has TODO items...
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Bill Traynor @ 2008-06-13 17:12 UTC (permalink / raw)
To: David Woodhouse
Cc: linux-embedded-owner, Rob Landley, Robert P. J. Day,
Mike Frysinger, Tim Bird, Greg Ungerer, Sam Ravnborg,
Leon Woestenberg, linux-embedded
In-Reply-To: <1213376457.26255.281.camel@pmac.infradead.org>
> On Fri, 2008-06-13 at 10:02 -0500,
> linux-embedded-owner@reliableembeddedsystems.com 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 this what the link was supposed to be:
http://www.embedded.com/columns/technicalinsights/197003517?printable=true
or in non-printable format:
http://www.embedded.com/columns/technicalinsights/197003517?_requestid=145614
Man, I must be bored today ;)
>
> You got me all excited there...
>
> --
> dwmw2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox