* Re: Not as much ccache win as I expected
From: Jörn Engel @ 2008-06-15 17:58 UTC (permalink / raw)
To: Tim Bird; +Cc: Oleg Verych, linux-embedded, linux-kbuild
In-Reply-To: <4852E245.4020502@am.sony.com>
On Fri, 13 June 2008 14:10:29 -0700, Tim Bird wrote:
>
> Maybe I should just be grateful for any ccache hits I get.
ccache's usefulness depends on your workload. If you make a change to
include/linux/fs.h, close to 100% of the kernel is rebuilt, with or
without ccache. But when you revert that change, the build time differs
dramatically. Without ccache, fs.h was simply changed again and
everything is rebuild. With ccache, there are hits for the old version
and all is pulled from the cache - provided you have allotted enough
disk for it.
If you never revert to an old version or do some equivalent operation,
ccache can even be a net loss. On a fast machine, the additional disk
accesses are easily more expensive than the minimal cpu gains.
Jörn
--
Public Domain - Free as in Beer
General Public - Free as in Speech
BSD License - Free as in Enterprise
Shared Source - Free as in "Work will make you..."
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" 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: about size optimizations (Re: Not as much ccache win as I expected)
From: Oleg Verych @ 2008-06-15 16:56 UTC (permalink / raw)
To: Jamie Lokier; +Cc: David Woodhouse, linux-embedded, linux-kbuild, segher
In-Reply-To: <20080615160049.GA2991@shareable.org>
> You can do this without changin the Makefile, if you provide suitable
> scripts on $PATH for the make.
I want to add here whole issue of kbuild's way of dependency
calculation and rebuild technique.
1) This whole infrastructure is needed only for developers. But
developer while writing/updating some code must know what is changed
and how it impacts all dependent/relevant code. Thus, one must create
list of all files *before* doing edit/build/run cycles (even with
git/quilt aid). And this list must be fed to build system to make sure
everything needed is rebuilt, and anything else is not (to save time).
This is matter of organizing tools and ways of doing things -- a very
important feature of doing anything effectively.
2) OTOH user needs no such thing at all. New kernel -- new build from
scratch. Distros are same. Also blind belief for correct rebuild using
old object pool is a naive thing.
3) Testers applying and testing patches. OK, now it's a rule to have
diffstat, thus list of changed files. But one can filter out them from
diff/patch with `sed` easily. It can be done even rejecting pure
whitespace/comment changes.
Now you have list of files, feed them to build system, like in (1). No
`make` (recursive or not, or whatever) is needed (use ccache-like
thing in general case to save build time). Its key-thing -- timestamps
-- is a lock for development somehow overcame by `make`-based kbuild
2.6. What an irony.
Problems:
* more flexible source-usage (thus dependency) tracking is needed
(per-variable, per-function, per-file). This must not be a random
comments near #include, it must be natural part of source files
themselves. Filenames are not subject to frequent changes. Big ones
can be split, but main prefix must be the same, thus no need of
changing it in all users. Small "ENOENT || prefix*" heuristics is
quite OK here.
* implemented features and their options must be described and
documented in-place in sources (distributed configuration). Licence
blocks are not needed, one has top file with it or MODULE_LICENSE().
Describe your source in a form, that will be easily parse-able for
creating dependency and configuration items/options.
* once all this in place, creating specific config sets by end users
must not be so painful for both sides as it now is.
#include's && #ifdef's are proven PITA; flexible text processing
(analysis, transformations) with basic tools like `sed` (or `perl`) is
the right way IMHO. On this stage no `gcc -E` for working `cat $all
>linux.c` is needed.
(My another stone to "The art of thinking in `make` and C". Hope, it's
constructive. Again all this i see as handled with very small set of
universal scripts.)
--
sed 'sed && sh + olecom = love' << ''
-o--=O`C
#oo'L O
<___=E M
^ permalink raw reply
* Re: about size optimizations (Re: Not as much ccache win as I expected)
From: Jamie Lokier @ 2008-06-15 16:00 UTC (permalink / raw)
To: David Woodhouse; +Cc: Oleg Verych, linux-embedded, linux-kbuild, segher
In-Reply-To: <1213437917.26255.335.camel@pmac.infradead.org>
David Woodhouse wrote:
> On Sat, 2008-06-14 at 10:56 +0100, Oleg Verych wrote:
> > I saw that. My point is pure text processing. But as it seems doing
> > `make` is a lot more fun than to do `sh` && `sed`.
>
> The problem is that it _isn't_ pure text processing. There's more to
> building with --combine than that, and we really do want the compiler to
> do it.
>
> _Sometimes_ you can just append C files together and they happen to
> work. But not always. A simple case where it fails would be when you
> have a static variable with the same name in two different files.
I suspect the simplest way to adapt an existing makefile is:
1. Replace each compile command "gcc args... file.c -o file.o"
with "gcc -E args... file.c -o file.o.i".
2. Replace each incremental link "ld -r -o foo.o files..." with
"cat `echo files... | sed 's/$/.i/'` > foo.o.i".
3. Similar replacement for each "ar" command making .a files.
4. Replace the main link "ld -o vmlinux files..." with
"gcc -o vmlinux --combine -fwhole-program `echo files... | sed 's/$/.i/'`".
You can do this without changin the Makefile, if you provide suitable
scripts on $PATH for the make.
-- Jamie
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Leon Woestenberg @ 2008-06-15 15:39 UTC (permalink / raw)
To: Rob Landley; +Cc: Greg Ungerer, Sam Ravnborg, David Woodhouse, linux-embedded
In-Reply-To: <200806111941.51221.rob@landley.net>
Hello all,
On Thu, Jun 12, 2008 at 2:41 AM, Rob Landley <rob@landley.net> 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 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.
>
Agreed, OpenEmbedded has a few thousands, but your point is valid.
However, fleeing to target-native compilation is not the way to
improve the situation IMHO.
Moore's law on hardware also goes for the host, I think the progress
is even bigger on big iron.
Also, how much of the 30000 packages are useful for something like
your own firmware Linux?
> Distcc can take advantage of smp, but that won't help the ./configure stage
> and I need to do some work on distcc to teach it to understand more gcc
>
If you want to build 1000+ packages, you don't need to run configure
itself multithreaded. There are enough jobs available to keep 16/32
processors busy (beyond that, you probably end up in
inter-package-dependencies stalling the build). This is just a guess
from what I see during a multi-threaded bake and multi-threaded make
on OpenEmbedded.
> 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.
>
How about 30+ volunteers.
> I'm not saying either solution is perfect, I'm just saying the "build under
> emulation" approach is a viable alternative that gets more attractive as time
> passes, both because of ongoing development on emulators and because of
> Moore's law on the hardware.
>
I cannot follow your reasoning - Moore's law will help you more on the
big iron side of things.
That said, I welcome any effort (such as yours) to help improve the
embedded Linux domain, I rather try to fix the cross-compile stuff of
the few thousand packages I am interested in.
Yes it hurts my brain.
Regards,
--
Leon
^ permalink raw reply
* Re: modules.dep and depmod.pl
From: Linus Walleij @ 2008-06-14 19:38 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <loom.20080614T092033-823@post.gmane.org>
2008/6/14 Matthieu castet <castet.matthieu@free.fr>:
> What's wrong with using your host depmod to build it.
> When I build a crosscompilation kernel, and I do make module_install,
> modules.dep are generated.
Well I do believe that works for you because you're lucky to
have a host with a recent kernel and module-init-tools.
However I believe that creates an unsound relation between the
host depmod and any cross compilation.
Currently I try to cross-compile a 2.6.25 kernel on an old good
workhorse with a 2.4.x kernel & likewise antique depmod. It
just won't work.
I tried to cross-compile all module-init-tools with --build=i386,
--host=i386, --target=arm-linux,
but that still fails: it checks what version of the kernel it's working
on, and determines that since that is a 2.4.x version it needs
to execute depmod.old instead :-P (Perhaps this is bug?)
I'd _really_ prefer cross-compilation to use the cross compiler
and in-kernel tools only, and currently I think it is actually
only depmod that deviates from that. (OK some scripts may
need a recent version of perl or so, that was just discussed in
another thread.)
Do you think an attempt to patch busybox:s depmod.pl into
scripts/ for the benefit of cross-compilation would be frowned
upon?
Linus Walleij
^ permalink raw reply
* Re: modules.dep and depmod.pl
From: Linus Walleij @ 2008-06-14 19:23 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <c32efac40806132351t150259e3oc0214e3ccd5eb6c@mail.gmail.com>
2008/6/14 Dave Hylands <dhylands@gmail.com>:
> When we were using 1.01 I think I had to patch the kernel Makefile. I
> think I had to undo my patch when we upgraded to the 1.10 version of
> busybox.
OK I'll see if there is a newer version which is good for this.
> You can also run the busybox depmod.pl after you've built the kernel,
> but before you make the file system.
Yeah that's what I do currently....
Linus Walleij
^ permalink raw reply
* Re: modules.dep and depmod.pl
From: Bernhard Fischer @ 2008-06-14 17:00 UTC (permalink / raw)
To: Mike Frysinger; +Cc: Linus Walleij, linux-embedded
In-Reply-To: <8bd0f97a0806131645l69d9c3c8x727c3edd0cad5975@mail.gmail.com>
On Fri, Jun 13, 2008 at 07:45:58PM -0400, Mike Frysinger wrote:
>On Fri, Jun 13, 2008 at 7:33 PM, Linus Walleij wrote:
>> 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?
>
>seems like a worthwhile step to me
Using the perl-script to create a modules.dep is one option. If you do
not have a perl interpreter on your host, then you can build busybox'
recently added depmod for your host and use that to create a
modules.dep. Alternatively you can create a modules.dep via busybox on
the fly when booting.
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Robert Schwebel @ 2008-06-14 11:26 UTC (permalink / raw)
To: Jamie Lokier; +Cc: Alexander Neundorf, linux-embedded
In-Reply-To: <20080614000749.GA30652@shareable.org>
On Sat, Jun 14, 2008 at 01:07:49AM +0100, Jamie Lokier wrote:
> Kernels, uclibc, busybox. All combinations can't be tested. But it's
> still _very_ useful to compile in only those parts wanted.
Kernel (and thus kconifg) is a critical mass project of it's own;
however, kconfig does only solve the "configuration" problem. Autotools
is much more. However, I was talking about userspace software. Core
components have usually much different needs.
> Media players with lots of optional formats and drivers are another.
> (They also have considerable problems with their Autoconf in my
> experience).
Send patches :-)
> Generally, anything with lots of parts that different applications
> might not use, and space or library dependencies are an issue.
According to my experience, the configure part of autotools is not it's
problem. Its more
- configure scripts are slow
- libtool isn't sysroot/destdir aware
- complex cross scenarios are not well supported (i.e. ace/tao, where
the IDL compiler needs most of libace and has to be compiled for both,
the "build" and "host" system)
> > 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).
>
> I agree. (And it proved about not being able to test more
> combinations: last time I tried to build ptxdist, an up to date
> version (at the time), it failed in several places.)
Did you tell the development team? We are known to fix 95% of the
problems in this universe in less than 10 minutes :-)
However, we have a stable policy in the meantime (1.0.x is in
maintenance only mode, regularly tested and quickly fixed), and the team
is really responsive. So it may be time to try it out again :-)
> > autotools need only a shell and make
>
> No, that's true only for very simple packages.
Ok, plus normal unix tools like sed and awk ...
> Most packages need lots of additional libraries installed - and the
> development versions of those libraries, for that matter. Too often
> the right development version - not too recent, not too old. With the
> wrong versions, there are surprises.
Right. But this is the downside of being able to deal with all this
complexity: every other build system would have the same problem.
> You said about too many user-selectable options. Many large packages
> _check_ for many installed libraries. Get them wrong, and you have the
> same problems of untested combinations.
Yup, auto-testing is usually a problem if you build cross stuff.
> Sure, autotools by themselves don't need much. But that's not
> interesting: Autotools are not used only by themselves.
They don't need a special runtime environment other than shell. Other
systems like Perl, Python, Java or whatever has the problem that
anything other than the very core is not very well defined and ends up
in the version hell.
We have once tried to write our automated test system for embedded
boards with python and xml; the idea was to have something fancy, new
and with good code-reuse. In the end it failed because the pexpect
package we used to do the pattern matching bitrotted so quickly that
four months later all the fancy tests didn't work any more, because it
is not part of the python core.
In the meantime we have migrated our automatic testing stuff to use
shell, ssh/rsh and kermit. It is rock solid, and the code reuse factor
is at least as good as with anything else.
> Have you felt uncomfortable shipping a package that does use Autoconf,
> Automake and Libtool, knowing that the scripts generated by those
> tools are huge compared with the entire source of your package?
No :-)
> Have you _written_ Autoconf tests recently?
Yea, all our packages are autotoolized.
> Made any shell / shellutils non-portability mistakes in the tests?
Yea, it happens in ptxdist all the time. People report about problems,
we add new tests and the next revision works even on Ubuntu :)
> Have you _read_ a portable Makefile lately? Have you tried writing
> one for a complex package, confident that it's portable to different
> quirky makes, quirky shells and quirky tools, outside the parts which
> you might use Automake for?
>
> That's a rationale for the project which is rewriting Autotools in GNU
> Make, assuming that to be ubiquitous now, imho. (Not all interesting
> systems have a shell either.)
I have no problems with people writing fancy new things. It's just that
most people who try to do something better than autotools have only a
fraction of the features.
Open Source is darwinism: if there is something better, let's use it.
But compare apples with apples.
> If you're going to rewrite Autotools using GNU Make, why not ask if
> another tool would be better, perhaps a tool specially designed for
> the job?
Go ahead.
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: about size optimizations (Re: Not as much ccache win as I expected)
From: Oleg Verych @ 2008-06-14 10:27 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-embedded, linux-kbuild, segher
In-Reply-To: <1213437917.26255.335.camel@pmac.infradead.org>
> _Sometimes_ you can just append C files together and they happen to
> work. But not always. A simple case where it fails would be when you
> have a static variable with the same name in two different files.
Afaik in the kernel global static variables are not appreciated much. In any
case file scope can be easily added by s/// to its name in text compile
stage.
There are much more problems with conditional includes and other source
configuration crutches.
> The compiler will do the right thing there., while naïve concatenation
> of C files will not.
That was an example, of course there must be pre-cc text processing stage.
> Of course, it's _possible_ to have external text processing cope with
> this case somehow -- you'd probably feed it through the preprocessor,
> then look at the output of the preprocessor and make the variable names
> unique, perhaps?
Even before cpp. But twisted includes/ifdef's cannot be handled without it.
> And then move on to the next case which is already handled in gcc...
To gain size reduction, some register-wide static variables (ints), which are
usually for some state-handling, can be glued together, if whole picture
permits: all flags fit in limited bit range, needed shift is added textually.
Again developer doing clear/documented semantics, text-based
transformations is needed. Can it be done by GCC optimizing stages?
(However Rusty may try to do that with cpp :)
> But really, I'd rather just leave it to the compiler. And it's not
> because I have some masochistic fascination with makefiles :)
--
sed 'sed && sh + olecom = love' << ''
-o--=O`C
#oo'L O
<___=E M
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" 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: about size optimizations (Re: Not as much ccache win as I expected)
From: David Woodhouse @ 2008-06-14 10:05 UTC (permalink / raw)
To: Oleg Verych; +Cc: linux-embedded, linux-kbuild, segher
In-Reply-To: <8499950a0806140256o45d3696o505c02b2f34d90db@mail.gmail.com>
On Sat, 2008-06-14 at 10:56 +0100, Oleg Verych wrote:
> I saw that. My point is pure text processing. But as it seems doing
> `make` is a lot more fun than to do `sh` && `sed`.
The problem is that it _isn't_ pure text processing. There's more to
building with --combine than that, and we really do want the compiler to
do it.
_Sometimes_ you can just append C files together and they happen to
work. But not always. A simple case where it fails would be when you
have a static variable with the same name in two different files.
The compiler will do the right thing there., while naïve concatenation
of C files will not.
Of course, it's _possible_ to have external text processing cope with
this case somehow -- you'd probably feed it through the preprocessor,
then look at the output of the preprocessor and make the variable names
unique, perhaps? And then move on to the next case which is already
handled in gcc...
But really, I'd rather just leave it to the compiler. And it's not
because I have some masochistic fascination with makefiles :)
--
dwmw2
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" 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: about size optimizations (Re: Not as much ccache win as I expected)
From: Oleg Verych @ 2008-06-14 9:56 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-embedded, linux-kbuild, segher
In-Reply-To: <1213429403.26255.298.camel@pmac.infradead.org>
David Woodhouse:
> On Fri, 2008-06-13 at 22:52 +0100, Oleg Verych wrote:
>> Using same `gcc -E` principle, I once had a dream to create
>> build with something like "whole-kernel-at-time" optimising
>> compiler option:
>
> Doing it for the whole kernel probably doesn't buy you a whole lot more
> than doing it a bit more selectively, which is what I was doing in
> http://lkml.org/lkml/2006/8/24/212
I saw that. My point is pure text processing. But as it seems doing
`make` is a lot more fun than to do `sh` && `sed`. Latter, however, is basic
tool (`make` is system), which requires knowledge, experience and
commitment. Original `compilercache` (from its ideas ccache was
implemented in C) was simple shell script, and it beats `make` very hard in
general case. Even flex-based C semi-parser there is simple task for `sed`.
Understanding of non trivial `sed` scripts is also an issue as well as
maintaining. But if this creating and maintaining of let's say
"source profiles" is off-loaded for users, in the realm kernel developers
call the "wild", then things can be much easier.
If there was more than one kbuild developer or wide and skilled
community, then same ccache scheme with some kconfig fixes in form
of simple shell script could be available for kernel builds, including
external modules. If fact this is how up-to-date kbuild+kconfig can be
used and developed easily by other projects (klibc, busybox, ...).
It's nice to see how big Makefile now is going to be split, however.
> I think Segher has been playing with it a bit recently, and confirms my
> suspicion that combining kernel/ with arch/$ARCH/kernel, and mm/ with
> arch/$ARCH/mm, is also a big win.
The C with dumb #includes and #ifdef's is very-very obsolete technology.
Much more flexibility can be achieved with text processing, if size-
optimizing source annotations/transformation schemes, based on
human-developer knowledge, user's source profiles can be used.
> The GCC problems should mostly be fixed now, I think -- we just need to
> have another go at doing the Kbuild side of it properly.
One don't need to beg GCC developers for every feature, bug fix, that
kernel developers can actually use. Now almost nothing can be done without
compiler support.
One example: returning values && error codes using CPU/GPIO flags, thus
reducing size and CPU load.
--
sed 'sed && sh + olecom = love' << ''
-o--=O`C
#oo'L O
<___=E M
^ permalink raw reply
* Re: about size optimizations (Re: Not as much ccache win as I expected)
From: Adrian Bunk @ 2008-06-14 9:48 UTC (permalink / raw)
To: David Woodhouse; +Cc: Oleg Verych, linux-embedded, linux-kbuild, segher
In-Reply-To: <1213429403.26255.298.camel@pmac.infradead.org>
On Sat, Jun 14, 2008 at 08:43:23AM +0100, David Woodhouse wrote:
> On Fri, 2008-06-13 at 22:52 +0100, Oleg Verych wrote:
> > Using same `gcc -E` principle, I once had a dream to create
> > build with something like "whole-kernel-at-time" optimising
> > compiler option:
>
> Doing it for the whole kernel probably doesn't buy you a whole lot more
> than doing it a bit more selectively, which is what I was doing in
> http://lkml.org/lkml/2006/8/24/212
For the interesting CONFIG_MODULES=n case it most likely can give you
much smaller code.
But Denys had section garbage collection patches, and combining the
per-module compilation with section garbage collection might get near
at the results of compiling the whole kernel at once?
> I think Segher has been playing with it a bit recently, and confirms my
> suspicion that combining kernel/ with arch/$ARCH/kernel, and mm/ with
> arch/$ARCH/mm, is also a big win.
>...
The big problem I see here is that we lose the link order.
Not unfixable, but quite nasty to sort out.
> dwmw2
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Shaz @ 2008-06-14 9:44 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linux-embedded
In-Reply-To: <20080612181902.ACEBF240E8@gemini.denx.de>
On Thu, Jun 12, 2008 at 11:19 PM, Wolfgang Denk <wd@denx.de> wrote:
> In message <7b740b700806121052n2f98dfa4hc96ebfc1be5b6bbf@mail.gmail.com> 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 don't know which
>> will be the best alternative.
>>
>> 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.
>
> For completeness, there is also the (free) ELDK. Some people are using it.
>
I got a toolchain giving an output. Going to test some stuff with
Qemu. I hope it works. ELDK seems to be a smooth tool. Now got to get
it working with my kernel, eclipse and target board :)
> [And yes, I'm obviously biased :-) ]
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> A list is only as strong as its weakest link. -- Don Knuth
>
--
Shaz
^ permalink raw reply
* Re: modules.dep and depmod.pl
From: Matthieu castet @ 2008-06-14 9:26 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <63386a3d0806131633g4721216al566c8b6959e4631@mail.gmail.com>
Hi,
Linus Walleij <linus.ml.walleij <at> gmail.com> writes:
>
> 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.
What's wrong with using your host depmod to build it.
When I build a crosscompilation kernel, and I do make module_install,
modules.dep are generated.
--
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: about size optimizations (Re: Not as much ccache win as I expected)
From: David Woodhouse @ 2008-06-14 7:43 UTC (permalink / raw)
To: Oleg Verych; +Cc: linux-embedded, linux-kbuild, segher
In-Reply-To: <8499950a0806131452j5dc9574dk336e9e06ee9e1785@mail.gmail.com>
On Fri, 2008-06-13 at 22:52 +0100, Oleg Verych wrote:
> Using same `gcc -E` principle, I once had a dream to create
> build with something like "whole-kernel-at-time" optimising
> compiler option:
Doing it for the whole kernel probably doesn't buy you a whole lot more
than doing it a bit more selectively, which is what I was doing in
http://lkml.org/lkml/2006/8/24/212
I think Segher has been playing with it a bit recently, and confirms my
suspicion that combining kernel/ with arch/$ARCH/kernel, and mm/ with
arch/$ARCH/mm, is also a big win.
The GCC problems should mostly be fixed now, I think -- we just need to
have another go at doing the Kbuild side of it properly.
--
dwmw2
^ permalink raw reply
* Re: Kernel boot problem on IXP422 Rev. A
From: Greg Ungerer @ 2008-06-14 7:17 UTC (permalink / raw)
To: Marcus Tangermann; +Cc: linux-embedded
In-Reply-To: <4852C582.9000508@web.de>
Hi Marcus,
Marcus Tangermann wrote:
> 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?
I don't recall any specific fixes as such. There is support
for a few extra IXPxxx based boards.
Do a quick diff against a stock 2.6.19. There may be a number of
changes related to non-mmu arm in there, they won't have any impact
on IXP4xx support though.
> 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.
Kernel dying, not just no console?
Is your serial console on ttyS0 or ttyS1?
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Greg Ungerer @ 2008-06-14 6:57 UTC (permalink / raw)
To: Jamie Lokier; +Cc: Bill Traynor, Shaz, linux-embedded
In-Reply-To: <20080614015707.GB32232@shareable.org>
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 different sets of
>>> patches on top of mainline tools. Central authorities you might
>>> believe in existed, but they were always a few patches behind what you
>>> actually needed.
>> I disagree with respect to ARM. GNU toolchains for ARM have for the last
>> four or five years been relatively up to date for ARM hardware. This is a
>> direct result of ARM paying for this support to be added.
>
> I believe you, but they were difficult to _find_. A couple of years
> ago I looked for up to date ARM GNU tools. The first few pages from
> Google lead to a small number of places where you could download
> toolchains at least a year out of date, possibly more, and none to get
> anything current in a straightforward format (i.e. not an entire dev
> kit with IDEs etc.).
>
> That situation has improved greatly since then.
>
> But, to be honest, ARM-nommu toolchain support is still second class.
>
> There's no shared library / dynamic loader support for ARM-nommu, and
> no apparent plans to implement it. (I'd help but I don't have time to
> do it all). NPTL threads are coming along, but not yet ready; it's
> been quite slow. C++ sometimes crashes at the linking stage.
Nobody is willing to put in the new effort here required to
make this work. So the "no plans" really means no person power
to make it happen.
>>> When I last needed a toolchain, Google led to confusing results, and I
>>> had to try more than one. I still use mutiple GCC versions (from
>>> different people) to compile different programs for the same
>>> architecture: each one fails some things in a different way, including
>>> run-time failures in the precompiled toolchains.
>> You didn't have to try more than one, you chose to try more than one.
>
> I found significant problems with the first. Fixing obscure looking
> register allocation crash bugs in the compiler was more than I thought
> I had time for - looking for another was less work than that,
> therefore I rationally chose it.
>
> I figured that bug was fixed in a newer version, and it was. Then I
> found run-time problems with threads (crashing and impossible to trap
> in GDB - probably distributed libc mismatched my kernel - wtf?), and
> incompatibilities with binary libraries I had to link with. (That's
> why I use two different toolchain versions in my project now).
>
> Eventually, for some applications, what worked was a combination:
> tools from one place but headers and libraries from the other.
>
> To solve this properly, requires that I delve into the toolchain code,
> or find _another_ newer one which might fix these problems.
>
> It's a substantial time sink to do any of these things.
>
>> You could have just as easily chosen to use only the current
>> mainline GNU toolchain and worked through your issues with the
>> community, thereby allowing mainline to benefit from your fixes, and
>> you to benefit by getting to use the most current toolchain.
>
> I agree that is good. However, my issues were rather specific to my
> application setup and third party commercial dependencies (typical of
> some embedded projects), and depended on older tools and kernels, so I
> wouldn't expect the community to have much interest. The lack of
> interest in 2.4 kernels is pretty explicit (understandably - I don't
> like using it either), and for GCC 2.old/3.old I'm assuming it.
>
> The lack of backed-by-action interest in making ARM-nommu tools
> support current GCC features like C++ properly, shared libraries, and
> modern threads, adds to the sense that, while it's good to be in touch
> with the community, there isn't a lot of readiness to work on obscure
> things which don't affect a lot of people, and on hardware which isn't
> the future.
>
> Eventually I might forward port enough to follow mainline kernels and
> tools. But that's a substantial time sink too - don't underestimate
> it. I'm told that mainline current 2.6 doesn't build let alone work
> on ARM-nommu (yet); that does not make forward-porting including local
I am down to 3 or 4 patches for mainline to work on arm non-mmu.
It could be made to work on almost all 2.6.x kernels with only a
few patches - and those have always been available from uclinux.org.
That is not a barrier. I am working out the wrinkles in these last
changes, they will get in sooner or later.
> drivers and architecture quirks sound like it will be quick. If slow,
> it's not worth the effort to me alone.
>>> Just Google for "uclinux toolchain" and the top hits lead to very old
>>> releases, with bugs that have long been fixed elsewhere. "uclinux arm
>>> toolchain" is no better.
>> 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.
>
> I agree. I would like to do that, and with a thriving, interested
> community I will. I'm hoping linux-embedded@vger.kernel.org might
> help catalyse it - perhaps by creating the perception of it to people
> like me.
>
> It only really works if lots of people do that together, and it seems
> to be particularly _not_ the culture in some segments of the embedded
> development community.
>
> I base this on Google leading to lots of pages with old announcements
> of compilers, cross-compilation scripts and so on. Why aren't those
> pages links to a few standard "good" places which are actively kept up
> to date? It appears to be (or have been) a fragmented community - and
> so who to work with, that's a question.
>
>>> Perhaps current versions (e.g. from Codesourcery?) are more dependable
>>> for embedded architectures, but I don't have the time to thoroughly
>>> test them, and my last experience warns me to be careful.
>> I know from experience, having worked for CodeSourcery that their
>> toolchains are exhaustively tested. And any problems reported to their
>> public mailing lists are fixed, if legitimate. These fixes are typically
>> submitted upstream to the FSF very quickly when the bugs exist in mainline
>> as well.
>
> I know from experience that "bugs" are fixed, but feature requests
> like reliable C++, shared libraries and NPTL threads are long in
> coming to some architectures, if they ever will be before those
> architectures are no longer manufactured.
>
>>> It seems people release tools, release patches, publish on an obscure
>>> web page, then forget about the page. More authoritative-sounding
>>> uclinux web pages tend to be out of date. Google isn't finding good
>>> current authorities in this area, which suggests the space is rather
>>> fragmented with people pulling in different directions and not working
>>> together enough to create stable, common places for these things.
>> But isn't the FSF repositories for the GNU Tools, and the uClinux projects
>> repositories the stable, common place for these things?
>
> You can't even build an ARM-nommu executable with GNU tools from FSF!
Thats true of any of the non-mmu architectures that rely on
elf2flt. So arm is no different.
Like many open source projects uClinux isn't a finished "thing".
It is actively being developed. Not everything works, not everything
works well. The quality of what is there now depends very much
on the amount of effort input...
> It needs an extra tool. I'm not even sure which version of that is
> the recommended one - the C one or the shell script both have issues
> outstanding. By the way, neither work with some C++ programs on
> ARM-nommu: they crash with messages about unfixable relocations. More
> often with GCC 4 than GCC 3. See what I mean about things not being
> in great shape?
Well, what can I say, you are welcome to fix them :-)
Sometimes you need to be the one to step up and make
things better, especially if you want to use them :-)
>>> 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.
>> IMHO, the same is true for the GNU tool.
>
> If that's true for ARM-nommu support, it has improved dramatically. I
> will try again, in time, but prior experience tells me not to spend
> too long on it. It's much better use of time to find some patched
> combination that is working well for someone else. But who to
> ask/trust? Even the pre-built toolchains don't always work right.
> (See my earlier mention of undebuggable thread problems in executables
> built with a googd-distributed.)
Regards
Greg
--
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: modules.dep and depmod.pl
From: Dave Hylands @ 2008-06-14 6:51 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-embedded
In-Reply-To: <63386a3d0806131633g4721216al566c8b6959e4631@mail.gmail.com>
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 think it depends on which version of busybox you use.
When we were using 1.01 I think I had to patch the kernel Makefile. I
think I had to undo my patch when we upgraded to the 1.10 version of
busybox.
I'll have to wait until I get back to work on Monday to check.
> 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?
You can also run the busybox depmod.pl after you've built the kernel,
but before you make the file system.
--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Greg Ungerer @ 2008-06-14 6:43 UTC (permalink / raw)
To: Jamie Lokier; +Cc: Bill Traynor, Shaz, linux-embedded
In-Reply-To: <20080613144658.GA21071@shareable.org>
Jamie Lokier wrote:
> 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 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 of
> patches on top of mainline tools. Central authorities you might
> believe in existed, but they were always a few patches behind what you
> actually needed.
>
> When I last needed a toolchain, Google led to confusing results, and I
> had to try more than one. I still use mutiple GCC versions (from
> different people) to compile different programs for the same
> architecture: each one fails some things in a different way, including
> run-time failures in the precompiled toolchains.
>
> Just Google for "uclinux toolchain" and the top hits lead to very old
> releases, with bugs that have long been fixed elsewhere. "uclinux arm
> toolchain" is no better.
The uClinux arm toolchain case can be put down to noone
having an interest in actually doing the work. There has been
some work over the years, but no coordinated effort for quite
a while now.
> Perhaps current versions (e.g. from Codesourcery?) are more dependable
> for embedded architectures, but I don't have the time to thoroughly
> test them, and my last experience warns me to be careful.
>
> It seems people release tools, release patches, publish on an obscure
> web page, then forget about the page. More authoritative-sounding
> uclinux web pages tend to be out of date. Google isn't finding good
> current authorities in this area, which suggests the space is rather
> fragmented with people pulling in different directions and not working
> together enough to create stable, common places for these things.
Yep, there is a lack of "working together" when it comes to the
uclinux tool chains. You can't force people to work together.
At the very least the packages on uclinux.org give you the build
instructions, and scripts used to build them. You can try to get
newer tool versions working (with fixes if required).
> 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.
I don't know that comparison exactly holds. kernel.org is source,
just like gnu.org is the source of gcc/binutils/etc. Are you not
talking about binary toolchain packages above?
Regards
Greg
--
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Jamie Lokier @ 2008-06-14 1:57 UTC (permalink / raw)
To: Bill Traynor; +Cc: Shaz, linux-embedded
In-Reply-To: <c109f779883bf249397752373f3606d9.squirrel@www.geekisp.com>
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 of
> > patches on top of mainline tools. Central authorities you might
> > believe in existed, but they were always a few patches behind what you
> > actually needed.
>
> I disagree with respect to ARM. GNU toolchains for ARM have for the last
> four or five years been relatively up to date for ARM hardware. This is a
> direct result of ARM paying for this support to be added.
I believe you, but they were difficult to _find_. A couple of years
ago I looked for up to date ARM GNU tools. The first few pages from
Google lead to a small number of places where you could download
toolchains at least a year out of date, possibly more, and none to get
anything current in a straightforward format (i.e. not an entire dev
kit with IDEs etc.).
That situation has improved greatly since then.
But, to be honest, ARM-nommu toolchain support is still second class.
There's no shared library / dynamic loader support for ARM-nommu, and
no apparent plans to implement it. (I'd help but I don't have time to
do it all). NPTL threads are coming along, but not yet ready; it's
been quite slow. C++ sometimes crashes at the linking stage.
> > When I last needed a toolchain, Google led to confusing results, and I
> > had to try more than one. I still use mutiple GCC versions (from
> > different people) to compile different programs for the same
> > architecture: each one fails some things in a different way, including
> > run-time failures in the precompiled toolchains.
>
> You didn't have to try more than one, you chose to try more than one.
I found significant problems with the first. Fixing obscure looking
register allocation crash bugs in the compiler was more than I thought
I had time for - looking for another was less work than that,
therefore I rationally chose it.
I figured that bug was fixed in a newer version, and it was. Then I
found run-time problems with threads (crashing and impossible to trap
in GDB - probably distributed libc mismatched my kernel - wtf?), and
incompatibilities with binary libraries I had to link with. (That's
why I use two different toolchain versions in my project now).
Eventually, for some applications, what worked was a combination:
tools from one place but headers and libraries from the other.
To solve this properly, requires that I delve into the toolchain code,
or find _another_ newer one which might fix these problems.
It's a substantial time sink to do any of these things.
> You could have just as easily chosen to use only the current
> mainline GNU toolchain and worked through your issues with the
> community, thereby allowing mainline to benefit from your fixes, and
> you to benefit by getting to use the most current toolchain.
I agree that is good. However, my issues were rather specific to my
application setup and third party commercial dependencies (typical of
some embedded projects), and depended on older tools and kernels, so I
wouldn't expect the community to have much interest. The lack of
interest in 2.4 kernels is pretty explicit (understandably - I don't
like using it either), and for GCC 2.old/3.old I'm assuming it.
The lack of backed-by-action interest in making ARM-nommu tools
support current GCC features like C++ properly, shared libraries, and
modern threads, adds to the sense that, while it's good to be in touch
with the community, there isn't a lot of readiness to work on obscure
things which don't affect a lot of people, and on hardware which isn't
the future.
Eventually I might forward port enough to follow mainline kernels and
tools. But that's a substantial time sink too - don't underestimate
it. I'm told that mainline current 2.6 doesn't build let alone work
on ARM-nommu (yet); that does not make forward-porting including local
drivers and architecture quirks sound like it will be quick. If slow,
it's not worth the effort to me alone.
> > Just Google for "uclinux toolchain" and the top hits lead to very old
> > releases, with bugs that have long been fixed elsewhere. "uclinux arm
> > toolchain" is no better.
>
> 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.
I agree. I would like to do that, and with a thriving, interested
community I will. I'm hoping linux-embedded@vger.kernel.org might
help catalyse it - perhaps by creating the perception of it to people
like me.
It only really works if lots of people do that together, and it seems
to be particularly _not_ the culture in some segments of the embedded
development community.
I base this on Google leading to lots of pages with old announcements
of compilers, cross-compilation scripts and so on. Why aren't those
pages links to a few standard "good" places which are actively kept up
to date? It appears to be (or have been) a fragmented community - and
so who to work with, that's a question.
> > Perhaps current versions (e.g. from Codesourcery?) are more dependable
> > for embedded architectures, but I don't have the time to thoroughly
> > test them, and my last experience warns me to be careful.
>
> I know from experience, having worked for CodeSourcery that their
> toolchains are exhaustively tested. And any problems reported to their
> public mailing lists are fixed, if legitimate. These fixes are typically
> submitted upstream to the FSF very quickly when the bugs exist in mainline
> as well.
I know from experience that "bugs" are fixed, but feature requests
like reliable C++, shared libraries and NPTL threads are long in
coming to some architectures, if they ever will be before those
architectures are no longer manufactured.
> > It seems people release tools, release patches, publish on an obscure
> > web page, then forget about the page. More authoritative-sounding
> > uclinux web pages tend to be out of date. Google isn't finding good
> > current authorities in this area, which suggests the space is rather
> > fragmented with people pulling in different directions and not working
> > together enough to create stable, common places for these things.
>
> But isn't the FSF repositories for the GNU Tools, and the uClinux projects
> repositories the stable, common place for these things?
You can't even build an ARM-nommu executable with GNU tools from FSF!
It needs an extra tool. I'm not even sure which version of that is
the recommended one - the C one or the shell script both have issues
outstanding. By the way, neither work with some C++ programs on
ARM-nommu: they crash with messages about unfixable relocations. More
often with GCC 4 than GCC 3. See what I mean about things not being
in great shape?
> > 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.
>
> IMHO, the same is true for the GNU tool.
If that's true for ARM-nommu support, it has improved dramatically. I
will try again, in time, but prior experience tells me not to spend
too long on it. It's much better use of time to find some patched
combination that is working well for someone else. But who to
ask/trust? Even the pre-built toolchains don't always work right.
(See my earlier mention of undebuggable thread problems in executables
built with a googd-distributed.)
-- Jamie
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Jamie Lokier @ 2008-06-14 1:46 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: Linux Embedded Maillist
In-Reply-To: <20080613151942.GK11760@nibiru.local>
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 some
> folks wanted to stop this and leave all the QM works to individual
> distros. I'm glad this plan was dropped.
I'm glad too. I've had to do the reverse: cherry-pick through 2000
patches from distro kernel source packages, to find the good ones for
my kernel - bug fixes, driver fixes. It took a long time, and I had
to give up before finishing, it was simply too much work.
That was 2.4, back when distros did a lot of their own patches, kept
outside the mainline kernel. Thankfully, the 2.6 process is much better.
-- Jamie
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Jamie Lokier @ 2008-06-14 0:31 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: Linux Embedded Maillist
In-Reply-To: <20080613152854.GM11760@nibiru.local>
Enrico Weigelt wrote:
> * Alexander Neundorf <neundorf@eit.uni-kl.de> 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 sw engineering from ground up.
Oh? The alternative I see is to do the test at run-time. But that
adds to executable size and run-time slowdown on most platforms.
Doing it at build time is an improvement, for those people who don't
care about cross-compilation. (Not me, you understand.)
-- Jamie
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Jamie Lokier @ 2008-06-14 0:07 UTC (permalink / raw)
To: Robert Schwebel; +Cc: Alexander Neundorf, linux-embedded
In-Reply-To: <20080613231932.GW13599@pengutronix.de>
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, because the more options you have, the more
> difficult it becomes to test all the combinations.
Kernels, uclibc, busybox. All combinations can't be tested. But it's
still _very_ useful to compile in only those parts wanted.
Most packages have far fewer. But some have enough that the command
line is unwieldy and Kconfig would fit. I'm thinking libcurl - one
configure option for each protocol supported. iptables (userspace)
would be a candidate, when you have to link statically and save space.
Media players with lots of optional formats and drivers are another.
(They also have considerable problems with their Autoconf in my
experience).
Generally, anything with lots of parts that different applications
might not use, and space or library dependencies are an issue.
> > 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).
I agree. (And it proved about not being able to test more
combinations: last time I tried to build ptxdist, an up to date
version (at the time), it failed in several places.)
> 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.
I agree with you. There's no need to disagree, and who's whining?
We're trying to think of realistic improvments.
Reality is that Kconfig front end to autotools does work - as you've
proved. It's a good idea. :-)
> > 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.
Me neither.
> > Lots of packages need special tools or other software installed to
> > build them; this is no different.
>
> autotools need only a shell and make
No, that's true only for very simple packages.
Most packages need lots of additional libraries installed - and the
development versions of those libraries, for that matter. Too often
the right development version - not too recent, not too old. With the wrong versions, there are surprises.
You said about too many user-selectable options. Many large packages
_check_ for many installed libraries. Get them wrong, and you have
the same problems of untested combinations.
Quite a lot of packages require extra tools to build, beyond shell,
make, GCC and Binutils. Perl, Python are common.
Sure, autotools by themselves don't need much. But that's not
interesting: Autotools are not used only by themselves.
> > 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?
Have you felt uncomfortable shipping a package that does use Autoconf,
Automake and Libtool, knowing that the scripts generated by those
tools are huge compared with the entire source of your package?
Have you _written_ Autoconf tests recently? Made any shell /
shellutils non-portability mistakes in the tests?
Have you _read_ a portable Makefile lately? Have you tried writing
one for a complex package, confident that it's portable to different
quirky makes, quirky shells and quirky tools, outside the parts which
you might use Automake for?
That's a rationale for the project which is rewriting Autotools in GNU
Make, assuming that to be ubiquitous now, imho. (Not all interesting
systems have a shell either.)
If you're going to rewrite Autotools using GNU Make, why not ask if
another tool would be better, perhaps a tool specially designed for
the job?
-- Jamie
^ permalink raw reply
* Re: modules.dep and depmod.pl
From: Mike Frysinger @ 2008-06-13 23:45 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-embedded
In-Reply-To: <63386a3d0806131633g4721216al566c8b6959e4631@mail.gmail.com>
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/<version>/modules.dep
> during compile-time?
it's used in the uClinux distribution and works fine for me. only had
problems when there are multiple kernel versions, but never had a
problem with a single.
> 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?
seems like a worthwhile step to me
-mike
^ permalink raw reply
* 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
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