* 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
* Re: Cross Compiler and loads of issues
From: Enrico Weigelt @ 2008-06-13 17:12 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <c109f779883bf249397752373f3606d9.squirrel@www.geekisp.com>
* Bill Traynor <wmat@naoi.ca> schrieb:
> The "fixed elsewhere" is the problem. If everyone used the most current
> release and worked through issues with the community, this problem would
> go away.
Yep, and here we're again at the point that opensource/community
development and just use open code to build something own are
different things ;-o
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: David Woodhouse @ 2008-06-13 17:00 UTC (permalink / raw)
To: linux-embedded-owner
Cc: Rob Landley, Robert P. J. Day, Mike Frysinger, Tim Bird,
Greg Ungerer, Sam Ravnborg, Leon Woestenberg, linux-embedded
In-Reply-To: <20080613100231.btmn0xgmqog884cs@localhost>
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.
You got me all excited there...
--
dwmw2
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Enrico Weigelt @ 2008-06-13 15:28 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <200806131132.55543.neundorf@eit.uni-kl.de>
* 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.
BTW: python is one of the packages didn't pass a single one of
my QM constraints (hey, not completely corrent, IMHO, install
prefix was passed ;-O)
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Bill Traynor @ 2008-06-13 15:28 UTC (permalink / raw)
To: Jamie Lokier; +Cc: Bill Traynor, Shaz, linux-embedded
In-Reply-To: <20080613144658.GA21071@shareable.org>
> Bill Traynor wrote:
>> Maybe I'm being dense, but what's specifically wrong with the current
>> toolchain universe?
>
> Back in ye olde days, you could download GCC and Binutils from
> gnu.org, configure for whatever is your architecture, and most times
> it just worked.
Yes, the difficulty is in the "configure" step. But the GNU Toolchain is
a complex beast but the benefit is it flexibility and numerous supported
architectures. Ye olde days perhaps was less complex, but also less
flexible and supporting less archs.
>
> 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.
>
> 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. 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.
>
> 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.
>
> 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.
>
> 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?
>
> 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 toolchain.
>
> -- Jamie
> --
> 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: Enrico Weigelt @ 2008-06-13 15:25 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <200806130843.05704.neundorf@eit.uni-kl.de>
* Alexander Neundorf <neundorf@eit.uni-kl.de> schrieb:
> Well, IMO this makes it sound too easy.
> If you write portable software, you have to do platform checks.
> Basically they can be done by
> -checking for the existence of files
> -checking if something builds
> -checking the output of running something you just built
Some concerete examples where you really *need* that ?
> The last one is the problem for cross compiling.
> Example: detecting the size of ints
>
> Easy way:
>
> ...
> printf("%d\n", sizeof(long));
> ...
Why not directly using sizeof() in your code ?
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Enrico Weigelt @ 2008-06-13 15:19 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <20080613144658.GA21071@shareable.org>
* Jamie Lokier <jamie@shareable.org> schrieb:
> For some reason, that stopped a while ago, and you had to go to
> different places to get working basic tools. And often, the place to
> go wasn't clear. Different people advertised their "ARM toolchain",
> "m68k toolchain" etc. and they were 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.
That's because many embedded build their toolchains completely on
their own, instead of just using an generic toolkit like ct.
> 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.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
^ permalink raw reply
* Re: cross-compiling alternatives
From: Enrico Weigelt @ 2008-06-13 15:16 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <1213351433.17853.61.camel@tara.firmix.at>
* 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
for each target manually, which leads the whole point of autoconf
ad absurdum ;-o
> But most embedded projects haven't that much number of "large tools" -
> mainly because the space is limited.
I'm probably not quite representative, but I'm using crosscompile
techniques also for building to the same arch - mainly for QM reasons.
> 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.
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.
> > 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
> 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.
> 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.
Probably you're looking for sysroot ?
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Shaz @ 2008-06-13 15:11 UTC (permalink / raw)
To: Bill Traynor; +Cc: linux-embedded
In-Reply-To: <0af6abe442d0b93a10a96b27153f04e9.squirrel@www.geekisp.com>
On Fri, Jun 13, 2008 at 7:13 PM, Bill Traynor <wmat@naoi.ca> wrote:
>> It's nice to see we have so many options and related people and pros
>> to it are available around.
>>
>> IMO there should be some sort of effort to standardize the tool-chains
>> and build environments coherently with the kernel. I think its a prime
>> time to work around all the possibilities and standardize so that a
>> collaborative effort similar to Linux kernel can be set ahead. I think
>> thats the objective of this list too. Any plans yet sorted out?
>
> I don't understand what you mean by "standardize the tool-chains and build
> environments", can you provide specifics? Similarly, what does "work
> around all the possibilities and standardize" mean?
>
Well, to put it clearly, there are many solutions to toolchains and
development kits but there must be work that can be stabilized by
streamlining and sorting out similarities, especially with the kernel
and libc. Simply, getting things done as smoothly as it would have
been with building linux from scratch.
This might not make sense as I am a new comer to embedded world so
pardon for any waste of time and thought process.
>> Maybe I'm being dense, but what's specifically wrong with the current
>>toolchain universe?
>>
>> On Fri, Jun 13, 2008 at 2:24 PM, Wookey <wookey@wookware.org> wrote:
>>>
>>> On 2008-06-12 22:52 +0500, Shaz wrote:
>>> > Hi,
>>> >
>>> > I have been following "Re: [PATCH 0/1] Embedded Maintainer(s)" and
>>> > felt like asking that is there one good way to get a cross compiler
>>> > work. I tried buildroot, scratchbox and even openMoko with
>>> > openEmbedded but all of them had lots of issues and don't know which
>>> > will be the best alternative.
>>>
>>> 'issues' are generally par for the course. It's a difficult problem.
>>> I've generally found buildroot the least-painful of the above, largely
>>> because it targets a relatively small section of the problem-space.
>>>
>>> For completeness I should also mention that Embedded Debian provides
>>> yet another option. I will not claim that it will have fewer issues
>>> than the above. http://www.emdebian.org/emdebian/intro.html
>>>
>>> I'm not sure if you are really asking about toolchains or build-systems?
>>> The former is fairly reliably solved. For a debian-based box just
>>> install pre-built cross toolchians from emdebian:
>>> http://www.emdebian.org/tools/crosstools.html
>>> (from i386, amd64, powerpc; to: nearly all debian-supported
>>> architectures, gcc3.3, 3.4, 4.1, 4.2, 4.3)
>>> http://www.emdebian.org/toolchains/search.php?section=devel gives more
>>> details.
>>>
>>> emdebian-tools also provides the debian equivalent of crosstool
>>> ('emchain' to build your own version of current current toolchain,
>>> should a suitable pre-built one not exist.
>>>
>>> For non-debian boxes other people seem to have listed the options so I
>>> won't repeat (and it's not my area of expertise).
>>>
>>> Wookey (Emdebian 'Chief bullshitter' - bias alert. The toolchains are
>>> great though, really.)
>>> --
>>> Principal hats: Balloonz - Toby Churchill - Aleph One - Debian
>>> http://wookware.org/
>>
>>
>>
>> --
>> Shaz
>> --
>> 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
>>
>
>
--
Shaz
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Enrico Weigelt @ 2008-06-13 15:06 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <200806130855.19609.neundorf@eit.uni-kl.de>
* Alexander Neundorf <neundorf@eit.uni-kl.de> schrieb:
> In general, cross compiling is not hard. You just have to call the cross
> toolchain, give it the correct parameters, search files in the right location
> and ... make sure you don't test stuff by running programs.
Same with carefully written makefiles ;-P
> Basically only the last one is problematic (but IMO still less problematic
> than running a virtual system on the host just to build something).
Yes, and that should be completely prohibited.
> How does cmake support that for cross compiling ?
> If it detects a try_run() (which is the command for building a test executable
> and then running it) in cross compiling mode (i.e. when it was told what the
> target platform is instead of just assuming it's the same as the build host),
> then it
> -issues a warning
> -stores the created executable in a place so the developer can find it
> -running some existing executable and checking its output
> -creates a file where the developer can enter the results which running the
> executable on the target host would have brought (includes comments where
> that command was found, the arguments, etc.,). The developer can then run the
> test executable manually on the target and enter the results. This seems to
> be similar to the config.cache somebody mentioned for debian.
Yes, introducing the problems as with autoconf. You'll have to maintain one
cachefile per package - there is *NO* standard on it's variables. And exactly
that's the key problem !
Therefore unitool has an generic platform database, where such generic
platform parameters can be set. These fields have to be standardized,
(adding new ones for some specific package is definitively the wrong way).
> So really the hard part is getting rid of running stuff to check the platform.
Isnt that hard. In all these years I had no case where it couldn't be
circumvented.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: linux-embedded-owner @ 2008-06-13 15:02 UTC (permalink / raw)
To: David Woodhouse
Cc: Rob Landley, Robert P. J. Day, Mike Frysinger, Tim Bird,
Greg Ungerer, Sam Ravnborg, Leon Woestenberg, linux-embedded
In-Reply-To: <1213340652.26255.224.camel@pmac.infradead.org>
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
>
^ permalink raw reply
* Re: cross-compiling alternatives
From: Enrico Weigelt @ 2008-06-13 14:55 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <20080613131753.GA19549@shareable.org>
* Jamie Lokier <jamie@shareable.org> schrieb:
> Relying on 'nm 'finding the variable, and not accidentally matching
> another variable with the wrong value, does not work for all C
> environments. E.g. some compile to compressed executables; some
> produce intermediate objects with incomplete or lazy compiles or
> symbolic, to be finished at link stage, and some are even more
> abstract.
ACK. And also think of preprocessor symbols (see glibc ;-P)
IIRC perl's buildsystem goes this way and so tends to fail.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
^ permalink raw reply
* Re: cross-compiling alternatives
From: Enrico Weigelt @ 2008-06-13 14:51 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <20080613144920.GB21071@shareable.org>
* Jamie Lokier <jamie@shareable.org> schrieb:
> Enrico Weigelt wrote:
> > But: the question is whether you'll need such a test at all
> > or if just using sizeof() at the right place won't do the trick ;-P
>
> It's best to do that if you can, and nearly always possible. There
> are a few coding techniques - especially performance sensitive - where
> that's not feasible.
Example ?
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Enrico Weigelt @ 2008-06-13 14:51 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <200806121925.35883.rob@landley.net>
* Rob Landley <rob@landley.net> schrieb:
> Current compilers have a "build at once" mode where they suck the whole
> project in and run the optimizer on it at once, resulting in noticeably
> smaller and faster output at the expense of needing buckets of memory to hold
> all the source code and intermediate structures in memory at once. The main
> roadblock to making use of this? Ripping out the existing makefiles and
> replacing them with a very small shell script that does something similar
> to "gcc *.c".
Yep, that's a fundamental problem with make that it works only on an
per-file basis (which is fine for many projects, but sometimes not).
That's why I prefer an purely descriptive paragidm (= subset of
delcarative, but practically no logic): a buildfile should only
describe the package's structure (eg.: "i have some executable foo
which consists of source [...] and imports libs [...]), so the
buildtool (and user's config) can cope with it all.
TreeBuild works this way: http://treebuild.metux.de/
BTW: does anyone known Plan9's mk ?
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
^ permalink raw reply
* Re: cross-compiling alternatives
From: Jamie Lokier @ 2008-06-13 14:49 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: linux-embedded
In-Reply-To: <20080613144118.GE11760@nibiru.local>
Enrico Weigelt wrote:
> But: the question is whether you'll need such a test at all
> or if just using sizeof() at the right place won't do the trick ;-P
It's best to do that if you can, and nearly always possible. There
are a few coding techniques - especially performance sensitive - where
that's not feasible.
-- Jamie
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Jamie Lokier @ 2008-06-13 14:46 UTC (permalink / raw)
To: Bill Traynor; +Cc: Shaz, linux-embedded
In-Reply-To: <0af6abe442d0b93a10a96b27153f04e9.squirrel@www.geekisp.com>
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.
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.
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.
-- Jamie
^ permalink raw reply
* Re: cross-compiling alternatives
From: Enrico Weigelt @ 2008-06-13 14:41 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <48527C96.4070404@parrot.com>
* Matthieu CASTET <matthieu.castet@parrot.com> schrieb:
> >How does it do that compile-time numeric comparison ?
> >
> for example you could do
>
> int test[my comparaison];
>
> if my comparaison < 0, the compilation should abort.
Cool trick :)
So, eg if you find out wether some type has an specific size:
int foo[(sizeof(int) == 4)?1:-1];
But: the question is whether you'll need such a test at all
or if just using sizeof() at the right place won't do the trick ;-P
(yes, I've came around lots of packages where this was the case!)
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Enrico Weigelt @ 2008-06-13 14:36 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <1213362895.13136.14.camel@samuelr.hq.netapp.com>
* Samuel Robb <sam@oneparticularharbor.net> schrieb:
> When you have a one- or two-line fix, and face Yet Another round of
> finding the right mailing list, identifying the right maintainers,
> figuring out the right way to submit a bug and a patch, and then have to
> spend the next 3 weeks explaining how no, you're not interested in being
> the PPC maintainer for libfoo... is it any wonder that developers (not
> to mention their management) eventually just gives up on the idea of
> "giving back to the community?"
ACK.
> One possible solution would be to provide a clearing house for these
> sorts of changes, maybe under the auspices of CELF or a similar
> organization. Instead of submitting patches to individual projects,
> submit them to the clearing house, and let interested individuals either
> gather together and push related patches upstream in individual
> projects, or give project maintainers a place to go and find embedded
> systems patches related to their projects.
See my last mail: that's exactly what the oss-qm project is for:
http://oss-qm.metux.de/
With OSS-QM and related tools you often even don't need your own
patching infrastructure - oss-qm provides complete patches against
virtually any package/release.
Perhaps a few words on the infrastructure:
* single patches are collected per package, each vendor may get his
own namespace/subdir, where he can feed in his patches.
* the single patches are automatically pulled together based on
"listfiles" - per package+release there is an simple text file
which just lists the single patches to be pulled together.
* each vendor may get it's own namespace for the listfiles.
In other words: if you fear somebody else breaks your already
tested/approved packages, just use your own (listfile) namespace.
BTW: CSDB does a similar thing for retrieving source tarballs.
Just query the DB, never ever care about individual URLs in
you local build system.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Enrico Weigelt @ 2008-06-13 14:26 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <20080612220246.GB27513@sovereign.org>
* Jim Freeman <jfree@sovereign.org> schrieb:
> And I'm just betting that when he said "push ... fixes ... out"
> he meant "work to get them incorporated back upstream", not just
> make them available to requesters.
Exactly.
That's the essence of opensource development:
Working together, instead of just taking someone else's work.
BTW: everyone here should know that maintaining own branches
(this actually happens if you have your own patches not fed
back to upstream) is an quite work intensive and sometimes
complex task. I doubt anyone here's really eager on doing that ;-P
I understand that not everyone can talk with every project's
upstream. Simply too much load. And not every project wants to
merge in your patches asap (think of how long it took until
expat team took in my really trivial $DESTDIR patch ;-o).
That's why I founded the OSS-QM project: it a kind of "overlay"
which provides fixes for a lot of packages in a strictly normalized
namespace (so 100% automatic applying is easy).
http://oss-qm.metux.de/
So, eg. if you've made some local changes, please at least feed
them to us :)
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Bill Traynor @ 2008-06-13 14:13 UTC (permalink / raw)
To: Shaz; +Cc: linux-embedded
In-Reply-To: <7b740b700806130500u17bf3adel3b2139e50d7b029f@mail.gmail.com>
> It's nice to see we have so many options and related people and pros
> to it are available around.
>
> IMO there should be some sort of effort to standardize the tool-chains
> and build environments coherently with the kernel. I think its a prime
> time to work around all the possibilities and standardize so that a
> collaborative effort similar to Linux kernel can be set ahead. I think
> thats the objective of this list too. Any plans yet sorted out?
I don't understand what you mean by "standardize the tool-chains and build
environments", can you provide specifics? Similarly, what does "work
around all the possibilities and standardize" mean?
Maybe I'm being dense, but what's specifically wrong with the current
toolchain universe?
>
> On Fri, Jun 13, 2008 at 2:24 PM, Wookey <wookey@wookware.org> wrote:
>>
>> On 2008-06-12 22:52 +0500, Shaz wrote:
>> > Hi,
>> >
>> > I have been following "Re: [PATCH 0/1] Embedded Maintainer(s)" and
>> > felt like asking that is there one good way to get a cross compiler
>> > work. I tried buildroot, scratchbox and even openMoko with
>> > openEmbedded but all of them had lots of issues and don't know which
>> > will be the best alternative.
>>
>> 'issues' are generally par for the course. It's a difficult problem.
>> I've generally found buildroot the least-painful of the above, largely
>> because it targets a relatively small section of the problem-space.
>>
>> For completeness I should also mention that Embedded Debian provides
>> yet another option. I will not claim that it will have fewer issues
>> than the above. http://www.emdebian.org/emdebian/intro.html
>>
>> I'm not sure if you are really asking about toolchains or build-systems?
>> The former is fairly reliably solved. For a debian-based box just
>> install pre-built cross toolchians from emdebian:
>> http://www.emdebian.org/tools/crosstools.html
>> (from i386, amd64, powerpc; to: nearly all debian-supported
>> architectures, gcc3.3, 3.4, 4.1, 4.2, 4.3)
>> http://www.emdebian.org/toolchains/search.php?section=devel gives more
>> details.
>>
>> emdebian-tools also provides the debian equivalent of crosstool
>> ('emchain' to build your own version of current current toolchain,
>> should a suitable pre-built one not exist.
>>
>> For non-debian boxes other people seem to have listed the options so I
>> won't repeat (and it's not my area of expertise).
>>
>> Wookey (Emdebian 'Chief bullshitter' - bias alert. The toolchains are
>> great though, really.)
>> --
>> Principal hats: Balloonz - Toby Churchill - Aleph One - Debian
>> http://wookware.org/
>
>
>
> --
> Shaz
> --
> 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: Josh Boyer @ 2008-06-13 13:59 UTC (permalink / raw)
To: Mike Frysinger
Cc: David Woodhouse, Tim Bird, Rob Landley, Greg Ungerer,
Sam Ravnborg, Leon Woestenberg, linux-embedded
In-Reply-To: <8bd0f97a0806121202t4b61bbd9x843cf9427318e9fd@mail.gmail.com>
On Thu, Jun 12, 2008 at 3:02 PM, Mike Frysinger <vapier.adi@gmail.com> wrote:
>>> people cant even write proper *native* makefiles. mtd-utils for example ;).
>>
>> What's wrong with it? I'll fix it.
>
> is linux-mtd@lists.infradead.org not the place to post ? that's where
> i sent the first fix yesterday ... not that i'm subscribed since i
> dont have a direct interest in mtd development ...
It is. I just missed it. I'll look closer today. Thanks.
josh
^ permalink raw reply
* Re: cross-compiling alternatives
From: Matthieu CASTET @ 2008-06-13 13:56 UTC (permalink / raw)
To: Alexander Neundorf; +Cc: linux-embedded
In-Reply-To: <200806131540.15558.neundorf@eit.uni-kl.de>
Alexander Neundorf wrote:
> On Friday 13 June 2008 15:17:54 you wrote:
>> Bernd Petrovitsch wrote:
>>> Actually the size of ints (or any other type) can be easily deduced
>>> without running a (for the target) compiled binary:
>>> - compile the binary (for the target) with an initialized variable with
>>> that value.
>>> - use cross nm (or a similar tool) to read it from there.
>> Or the method autoconf uses - binary search, using a compile-time
>> numeric comparison which resolves to a successful or failed compile.
>
> How does it do that compile-time numeric comparison ?
>
for example you could do
int test[my comparaison];
if my comparaison < 0, the compilation should abort.
Matthieu
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Bill Traynor @ 2008-06-13 13:52 UTC (permalink / raw)
To: Bill Traynor; +Cc: Shaz, linux-embedded
In-Reply-To: <402b1f4b315f572ac6459f78fa8b5ee4.squirrel@www.geekisp.com>
>> 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.
>
> There is no "one good way". I've had decent success building Dan Kegel's
> "crosstool" in the past: http://www.kegel.com/crosstool/
>>
>> I 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'd continue the search for prebuilt toolchains. CodeSourcery has a Lite
> version of it's ARM, Coldfire, MIPS, and Power toolchains.
I should have pointed this out before, but there is a useful Toolchains
wiki page here: http://elinux.org/Toolchains
Feel free to contribute findings to that page.
>
>>
>> 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.
>>
>> --
>>
>> Shaz
>> --
>> 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
* Re: cross-compiling alternatives
From: Alexander Neundorf @ 2008-06-13 13:40 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <20080613131753.GA19549@shareable.org>
On Friday 13 June 2008 15:17:54 you wrote:
> Bernd Petrovitsch wrote:
> > Actually the size of ints (or any other type) can be easily deduced
> > without running a (for the target) compiled binary:
> > - compile the binary (for the target) with an initialized variable with
> > that value.
> > - use cross nm (or a similar tool) to read it from there.
>
> Or the method autoconf uses - binary search, using a compile-time
> numeric comparison which resolves to a successful or failed compile.
How does it do that compile-time numeric comparison ?
Alex
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Josh Boyer @ 2008-06-13 13:29 UTC (permalink / raw)
To: Mike Frysinger
Cc: David Woodhouse, Tim Bird, Rob Landley, Greg Ungerer,
Sam Ravnborg, Leon Woestenberg, linux-embedded
In-Reply-To: <8bd0f97a0806121202t4b61bbd9x843cf9427318e9fd@mail.gmail.com>
On Thu, Jun 12, 2008 at 3:02 PM, Mike Frysinger <vapier.adi@gmail.com> wrote:
>>> people cant even write proper *native* makefiles. mtd-utils for example ;).
>>
>> What's wrong with it? I'll fix it.
>
> is linux-mtd@lists.infradead.org not the place to post ? that's where
> i sent the first fix yesterday ... not that i'm subscribed since i
> dont have a direct interest in mtd development ...
It is. I just missed it. I'll look closer today. Thanks.
josh
^ 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