* 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
* Re: cross-compiling alternatives
From: Bernd Petrovitsch @ 2008-06-13 13:28 UTC (permalink / raw)
To: Jamie Lokier; +Cc: Alexander Neundorf, linux-embedded
In-Reply-To: <20080613131753.GA19549@shareable.org>
On Fre, 2008-06-13 at 14:17 +0100, Jamie Lokier wrote:
> Bernd Petrovitsch wrote:
> > Actually the size of ints (or any other type) can be easily deduced
> > without running a (for the target) compiled binary:
> > - compile the binary (for the target) with an initialized variable with
> > that 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.
Good, I didn't know that.
> That seems more portable to me.
Yes, just using the compiler is better.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* Re: cross-compiling alternatives
From: Jamie Lokier @ 2008-06-13 13:17 UTC (permalink / raw)
To: Bernd Petrovitsch; +Cc: Alexander Neundorf, linux-embedded
In-Reply-To: <1213351433.17853.61.camel@tara.firmix.at>
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.
That seems more portable to me.
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.
And it requires the 'nm' tool, which you might not have for
cross-compilation, or might not find the right one.
-- Jamie
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Samuel Robb @ 2008-06-13 13:14 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <20080612220246.GB27513@sovereign.org>
On Thu, 2008-06-12 at 16:02 -0600, Jim Freeman wrote:
> Most vendors these days have finally gotten the clue that sources/changes
> have to be made available to downstream requesters, but far fewer
> are sufficiently self-enlightened to figure out that changes need to
> be accepted upstream for them to keep flowing back. And to make that
> happen, vendors have to take on substantially higher overhead to win
> acceptance of patches/changes upstream, an undertaking often sadly
> fraught with hassle, uncertainty, and even peril. So they mostly
> don't bother. To their (and their customers, and our) long-term
> detriment.
So - how do you reduce that overhead, then? Keep in mind that while
pushing kernel changes upstream is significant, there are other projects
as well. Most embedded developers are working not just with the kernel,
but with a constellation of packages related to their projects. In
order to "push changes upstream", they may end up having to work with
several different communities... each with their own model of
interaction, their own model of patch submission, and their own release
schedules. Figuring out how to deal with just one community (kernel)
doesn't help them in dealing with another (say, samba).
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?"
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.
-Samrobb
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Shaz @ 2008-06-13 12:00 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <20080613092449.GO27937@knossos.aleph1.co.uk>
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?
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
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: James Chapman @ 2008-06-13 11:28 UTC (permalink / raw)
To: Daniel THOMPSON
Cc: Mike Frysinger, Tim Bird, David VomLehn, weigelt,
Linux Embedded Maillist
In-Reply-To: <485237BF.3030204@st.com>
Daniel THOMPSON wrote:
> James Chapman wrote:
>> Mike Frysinger wrote:
>>> On Thu, Jun 12, 2008 at 5:53 PM, Tim Bird wrote:
>>>> Mike Frysinger wrote:
>>>>>> Er, is that GPL or LGPL code that you're modifying? If so, you
>>>>>> *have* to
>>>>>> push those code changes out (make them available to others),
>>>>>> whether you
>>>>>> think people will be interested or not!
>>>>> umm, not really. only if (1) he gives a binary to someone and (2)
>>>>> they ask him for the source. if he doesnt distribute or no one asks,
>>>>> he doesnt have to do squat.
>>>> This is closer to correct, but missing some important details.
>>>>
>>>> Start the GPL compliance tutorial/flameware in 3, 2, 1...
>>> yeah, i really dont think licensing things belong here. sorry for
>>> following up.
>>>
>>> how about this policy: if you want to make a statement, go pay a
>>> lawyer. but that statement still shouldnt be made here ;).
>>> -mike
>> Sorry, I didn't mean to provoke a GPL flame war. The point I was trying
>> to make (badly as it turns out) is that if a company really wants to see
>> its changes taken upstream, it could simply publish the work on its
>> website and let each relevant community know that it's there.
>
> Isn't this a lot of the problem with the way embedded companies and
> developers interact with upstream.
>
> In some cases it is in the embedded developers interests to see their
> code adopted upstream (i.e. so they don't have to maintain it).
Totally agree! And the best chance of having code accepted upstream is
to work with the community _while_ developing it, i.e. discussing the
code during implementation, rather than presenting it to the community
when it's done. All too often, companies get frustrated by feedback from
the community because changes are requested to code that the original
authors have spent time testing etc. Had early versions been submitted
for feedback, changes could be made with less chance of wasted effort.
> Just tossing some code over the wall will, in almost all circumstances,
> result in the code being ignored.
It depends. But it stands a better chance of being adopted than holding
on to the work until someone asks for it. There could be lots of
embedded developers out there who would be willing to take some code
from cisco, modify it and work with the community to have it adopted
upstream.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: cross-compiling alternatives
From: Alexander Neundorf @ 2008-06-13 11:24 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <1213351433.17853.61.camel@tara.firmix.at>
On Friday 13 June 2008 12:03:53 you wrote:
> On Fre, 2008-06-13 at 11:06 +0200, Alexander Neundorf wrote:
...
> > > - rewrite generated pkg_config files after generation.
> > > Yes, that's pretty ugly.
> > > But perhaps I was just too dumb to find the correct solutions.
> >
> > Can you please 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 ?
>
> 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
You mean the RPATH in the installed executable was wrong ?
> that is not trivially overridable at run-time AFAIK so that ld-linux
If RUNPATH is available in the binary (exists since a few years, so it should
be in your toolchain), then RPATH is ignored. RUNPATH can be overridden using
LD_LIBRARY_PATH. It can be enabled with the linker flag --enable-new-dtags I
think.
If there is RPATH but not RUNPATH, then it can't be overridden. But still if
it doesn't find the library in that place, it will continue searching in the
other directories, e.g. LD_LIBRARY_PATH.
There is also a tool "chrpath", which you can use to change the RPATH entry in
an existing executable.
It's a bit hard to find, you can get it e.g. from an older revision of kdesvn:
http://websvn.kde.org/trunk/kdesupport/chrpath/?pathrev=808076
(it was removed again in revision 808077).
It may have issues with endianness.
Alex
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Bart Van Assche @ 2008-06-13 11:22 UTC (permalink / raw)
To: Robert P. J. Day
Cc: Mike Frysinger, David Woodhouse, Tim Bird, Rob Landley,
Greg Ungerer, Sam Ravnborg, Leon Woestenberg, linux-embedded
In-Reply-To: <alpine.LFD.1.10.0806121208320.22877@localhost.localdomain>
On Thu, Jun 12, 2008 at 6:12 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
...
> meooowww! :-) but at the risk of dragging this even further
> off-topic, i am *constantly* asked by people how to set up makefiles
> for their software project, and what would be nice is a small
> collection of examples of a makefile (or makefiles) done *right*. as
> in, properly recursive, supports cross-compiling without having to
> remove your left nad, etc, etc.
...
Please read the essay "Recursive Make Considered Harmful"
(http://miller.emu.id.au/pmiller/books/rmch/).
Bart.
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: David Woodhouse @ 2008-06-13 11:17 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bill Gatliff, Paul Mundt, Tim Bird, Rob Landley, Greg Ungerer,
Sam Ravnborg, Leon Woestenberg, linux-embedded
In-Reply-To: <Pine.LNX.4.64.0806131315010.2141@vixen.sonytel.be>
On Fri, 2008-06-13 at 13:15 +0200, Geert Uytterhoeven wrote:
> > For minimal file systems with a select handful of tools which can be
> > tested exhaustively, it's not so bad. But for any 'full-featured'
> > userspace, I think cross-compilation is completely insane.
>
> So, how does OpenWRT manage to survive?
I don't consider that a 'full-featured' userspace.
Or particularly sane, for that matter :)
--
dwmw2
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Geert Uytterhoeven @ 2008-06-13 11:15 UTC (permalink / raw)
To: David Woodhouse
Cc: Bill Gatliff, Paul Mundt, Tim Bird, Rob Landley, Greg Ungerer,
Sam Ravnborg, Leon Woestenberg, linux-embedded
In-Reply-To: <1213288655.26255.168.camel@pmac.infradead.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1845 bytes --]
On Thu, 12 Jun 2008, David Woodhouse wrote:
> On Thu, 2008-06-12 at 11:28 -0500, Bill Gatliff wrote:
> > > If you opt to cross-compile, having to deal with those
> > > sorts of things is the price you pay.
> >
> > If the build system derives from autoconf, then a hacked-up config.cache (or
> > equivalent command-line args) often solves problems for me. Just give the cache
> > the answers that it would otherwise have to get by running code on the target
> > machine.
> >
> > That's how emdebian is doing a bunch of their stuff, and I have to admit that it
> > works pretty darned well. It's also handy for configuration management, since
> > the cache file itself is plaintext and therefore svn/git/bzr/cvs/...-friendly.
>
> Yeah, I was building Red Hat Linux packages for sh3 many years ago,
> using tricks like that. But there was always _something_ else going
> wrong, however much you hacked around it. And a lot of it would only
> turn up at runtime, not build time. I would never consider shipping a
> product with a large number of userspace packages cross-compiled.
>
> For minimal file systems with a select handful of tools which can be
> tested exhaustively, it's not so bad. But for any 'full-featured'
> userspace, I think cross-compilation is completely insane.
So, how does OpenWRT manage to survive?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Technology and Software Centre Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis 293-0376800-10 GEBA-BE-BB
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Geert Uytterhoeven @ 2008-06-13 11:14 UTC (permalink / raw)
To: Robert P. J. Day
Cc: Mike Frysinger, David Woodhouse, Tim Bird, Rob Landley,
Greg Ungerer, Sam Ravnborg, Leon Woestenberg, linux-embedded
In-Reply-To: <alpine.LFD.1.10.0806121208320.22877@localhost.localdomain>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1542 bytes --]
On Thu, 12 Jun 2008, Robert P. J. Day wrote:
> On Thu, 12 Jun 2008, Mike Frysinger wrote:
> > On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote:
> > > If we just made people write portable code and proper Makefiles,
> > > it would be less of an issue :)
> >
> > people cant even write proper *native* makefiles. mtd-utils for
> > example ;).
>
> meooowww! :-) but at the risk of dragging this even further
> off-topic, i am *constantly* asked by people how to set up makefiles
> for their software project, and what would be nice is a small
> collection of examples of a makefile (or makefiles) done *right*. as
> in, properly recursive, supports cross-compiling without having to
^^^^^^^^^^^^^^^^^^
Ugh?
> remove your left nad, etc, etc.
>
> so ... would anyone like to recommend a software package or two
> somewhere whose makefile(s) is/are, ITHO, done well? that i/we could
> just point at and say, "do it like that!" anyone? anyone? bueller?
The kernel, except that it's still recursive?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Technology and Software Centre Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis 293-0376800-10 GEBA-BE-BB
^ permalink raw reply
* Re: cross-compiling alternatives
From: Bernd Petrovitsch @ 2008-06-13 10:03 UTC (permalink / raw)
To: Alexander Neundorf; +Cc: linux-embedded
In-Reply-To: <200806131106.18487.neundorf@eit.uni-kl.de>
On Fre, 2008-06-13 at 11:06 +0200, Alexander Neundorf wrote:
> On Friday 13 June 2008 10:38:36 you wrote:
> > On Fre, 2008-06-13 at 08:43 +0200, Alexander Neundorf wrote:
> ...
> > > Well, IMO this makes it sound too easy.
> > > If you write portable software, you have to do platform checks.
> > > Basically they can be done by
> > > -checking for the existence of files
> >
> > That can be done as - sooner or later - one must install the compiled
> > stuff anyway. So one has root directory somewhere and one can tell the
> > tools.
>
> Yes.
>
> > > -checking if something builds
> > > -checking the output of running something you just built
> >
> > And the above are not really a big problem -
>
> "checking if something builds" is no problem, this just works. Running
> something is a problem, as in "it doesn't just work" (...because you cannot
> run it).
ACK. AC_TRY_RUN() must die completely.
> > embedded people usually know such details and can tell the autoconf tools.
>
> 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;-)
But most embedded projects haven't that much number of "large tools" -
mainly because the space is limited.
> > Even worse is (or at least were) tools like pkg_config and libtool,
> > which generate directories to the build time library.
>
> What do you mean with "generate directories" ? RPATH ?
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).
[...]
> > - rewrite generated pkg_config files after generation.
> > Yes, that's pretty ugly.
> > But perhaps I was just too dumb to find the correct solutions.
>
> Can you please 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 ?
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 is not trivially overridable at run-time AFAIK so that ld-linux
finds "/opt/bar/lib/libbar.so.1.2.3.4" instead.
For real world names: glib is pretty commonly used by other libs. Voila,
an indirect dependency.
And BTW pkg-config didn't support the concept of a "DESTDIR" variable
(and I don't care about the name of that variable).
> > > The last one is the problem for cross compiling.
> > > Example: detecting the size of ints
> >
> > Why on earth does someone need this explicitly during the build?
> > If you have portable software, all of that should be hidden in the code
> > and use "sizeof(int)".
>
> From the "developer of a buildsystem" POV: there will be users who will need
> it.
If there is at least one valid technical reason: Yes.
If the only reasons are "we had it since 10 years with the old system"
or "we don't want to fix the code because it takes us too much time":
well, tough decision.
> But this was not the point. My point was: testing something by running an
> executable can be _a lot_ easier than testing the same without running
> something.
Of course. But *that's* in general possible for cross-compiling. And
having a 100% binary compatible qemu installation for every ARM and MIPS
core out there is IMHO also not feasible.
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.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Alexander Neundorf @ 2008-06-13 9:32 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <1213348320.26255.231.camel@pmac.infradead.org>
On Friday 13 June 2008 11:12:00 you wrote:
> On Fri, 2008-06-13 at 11:06 +0200, Alexander Neundorf wrote:
> > > Why on earth does someone need this explicitly during the build?
> > > If you have portable software, all of that should be hidden in the code
> > > and use "sizeof(int)".
> >
> > From the "developer of a buildsystem" POV: there will be users who will
> > need it.
>
> I think that epitomises what's wrong with autoconf. Sometimes, the best
Actually I think autoconf itself is not that bad. What is bad is "autotools",
i.e. that you get a combination of several tools which have to work together,
all huge shell scripts, all using different syntax, etc.
> thing to do is tell your users that they _don't_ need whatever it is
> they're asking you for.
We agree that if possible, tests which run something should be avoided.
But seriously, sometimes this is really very hard.
I don't dare to say impossible, but I'm tempted.
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).
Alex
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Wookey @ 2008-06-13 9:24 UTC (permalink / raw)
To: Shaz; +Cc: linux-embedded
In-Reply-To: <7b740b700806121052n2f98dfa4hc96ebfc1be5b6bbf@mail.gmail.com>
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/
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: David Woodhouse @ 2008-06-13 9:12 UTC (permalink / raw)
To: Alexander Neundorf; +Cc: linux-embedded
In-Reply-To: <200806131106.18487.neundorf@eit.uni-kl.de>
On Fri, 2008-06-13 at 11:06 +0200, Alexander Neundorf wrote:
> > Why on earth does someone need this explicitly during the build?
> > If you have portable software, all of that should be hidden in the code
> > and use "sizeof(int)".
>
> From the "developer of a buildsystem" POV: there will be users who will need
> it.
I think that epitomises what's wrong with autoconf. Sometimes, the best
thing to do is tell your users that they _don't_ need whatever it is
they're asking you for.
--
dwmw2
^ permalink raw reply
* Re: cross-compiling alternatives
From: Alexander Neundorf @ 2008-06-13 9:11 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <1213347028.17853.40.camel@tara.firmix.at>
On Friday 13 June 2008 10:50:28 you wrote:
> On Don, 2008-06-12 at 19:25 -0500, Rob Landley wrote:
...
> > in C (anybody remember X11's imake?) KDE switched to cmake:
>
> That generated "only" a Makefile IIRC.
Yes, cmake doesn't actually build the stuff itself, it generates input files
for the actual build tool you want to use.
For KDE4 all buildtools supported by cmake are working: the various makes,
XCode, MSVC projects.
Alex
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Alexander Neundorf @ 2008-06-13 9:06 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <1213346316.17853.28.camel@tara.firmix.at>
On Friday 13 June 2008 10:38:36 you wrote:
> On Fre, 2008-06-13 at 08:43 +0200, Alexander Neundorf wrote:
...
> > Well, IMO this makes it sound too easy.
> > If you write portable software, you have to do platform checks.
> > Basically they can be done by
> > -checking for the existence of files
>
> That can be done as - sooner or later - one must install the compiled
> stuff anyway. So one has root directory somewhere and one can tell the
> tools.
Yes.
> > -checking if something builds
> > -checking the output of running something you just built
>
> And the above are not really a big problem -
"checking if something builds" is no problem, this just works. Running
something is a problem, as in "it doesn't just work" (...because you cannot
run it).
> embedded people usually know such details and can tell the autoconf tools.
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.
> Even worse is (or at least were) tools like pkg_config and libtool,
> which generate directories to the build time library.
What do you mean with "generate directories" ? RPATH ?
> The only simple solution so far (without diving into the implementation
> and searching for root causes) were AFAICS:
> - do not use libtool for linking (as the link line as such without
> libtool works as expected)
Yes, libtool sucks, it's the wrong solution to the problem.
(and CMake doesn't use it).
> - rewrite generated pkg_config files after generation.
> Yes, that's pretty ugly.
> But perhaps I was just too dumb to find the correct solutions.
Can you please 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 ?
> > The last one is the problem for cross compiling.
> > Example: detecting the size of ints
>
> Why on earth does someone need this explicitly during the build?
> If you have portable software, all of that should be hidden in the code
> and use "sizeof(int)".
From the "developer of a buildsystem" POV: there will be users who will need
it.
But this was not the point. My point was: testing something by running an
executable can be _a lot_ easier than testing the same without running
something.
Alex
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Daniel THOMPSON @ 2008-06-13 9:02 UTC (permalink / raw)
To: James Chapman
Cc: Mike Frysinger, Tim Bird, David VomLehn, weigelt,
Linux Embedded Maillist
In-Reply-To: <48523254.2070507@katalix.com>
James Chapman wrote:
> Mike Frysinger wrote:
>> On Thu, Jun 12, 2008 at 5:53 PM, Tim Bird wrote:
>>> Mike Frysinger wrote:
>>>>> Er, is that GPL or LGPL code that you're modifying? If so, you
>>>>> *have* to
>>>>> push those code changes out (make them available to others),
>>>>> whether you
>>>>> think people will be interested or not!
>>>> umm, not really. only if (1) he gives a binary to someone and (2)
>>>> they ask him for the source. if he doesnt distribute or no one asks,
>>>> he doesnt have to do squat.
>>> This is closer to correct, but missing some important details.
>>>
>>> Start the GPL compliance tutorial/flameware in 3, 2, 1...
>>
>> yeah, i really dont think licensing things belong here. sorry for
>> following up.
>>
>> how about this policy: if you want to make a statement, go pay a
>> lawyer. but that statement still shouldnt be made here ;).
>> -mike
>
> Sorry, I didn't mean to provoke a GPL flame war. The point I was trying
> to make (badly as it turns out) is that if a company really wants to see
> its changes taken upstream, it could simply publish the work on its
> website and let each relevant community know that it's there.
Isn't this a lot of the problem with the way embedded companies and
developers interact with upstream.
In some cases it is in the embedded developers interests to see their
code adopted upstream (i.e. so they don't have to maintain it).
Just tossing some code over the wall will, in almost all circumstances,
result in the code being ignored.
> A diff of
> the changes would be ideal. This is above and beyond what they have to
> do under GPL terms of course. There's no need for a company to filter
> out changes that it thinks others won't be interested in.
This is a legal concern, not a practical one. All companies *should*
comply with the law. Really it is more useful to convince people that it
is in their own self-interest to do more than this.
--
Daniel Thompson (STMicroelectronics) <daniel.thompson@st.com>
1000 Aztec West, Almondsbury, Bristol, BS32 4SQ. 01454 462659
If a car is a horseless carriage then is a motorcycle a horseless horse?
^ permalink raw reply
* Re: cross-compiling alternatives
From: Bernd Petrovitsch @ 2008-06-13 8:50 UTC (permalink / raw)
To: Rob Landley
Cc: Robert P. J. Day, Mike Frysinger, David Woodhouse, Tim Bird,
Greg Ungerer, Sam Ravnborg, Leon Woestenberg, linux-embedded
In-Reply-To: <200806121925.35883.rob@landley.net>
On Don, 2008-06-12 at 19:25 -0500, Rob Landley wrote:
> On Thursday 12 June 2008 11:12:13 Robert P. J. Day wrote:
> > On Thu, 12 Jun 2008, Mike Frysinger wrote:
> > > On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote:
> > > > If we just made people write portable code and proper Makefiles,
> > > > it would be less of an issue :)
> > >
> > > people cant even write proper *native* makefiles. mtd-utils for
> > > example ;).
> >
> > meooowww! :-) but at the risk of dragging this even further
> > off-topic, i am *constantly* asked by people how to set up makefiles
> > for their software project, and what would be nice is a small
> > collection of examples of a makefile (or makefiles) done *right*. as
> > in,
>
> Make doesn't scale.
>
> 99% of the builds in the open source world are "make all", and most of the
> smaller projects build natively on modern dual processor 2ghz laptops in
> under 10 seconds anyway.
>
> The larger projects with significant build times usually find that make
> doesn't suit their needs, so that they write some other build system.
> Sometimes they do it on top of make, such as the kernel's kbuild. Sometimes
> they use another language like apache's ANT. Sometimes they roll their own
"ant" is also only "make reimplemented in Java" (or did I miss
something). I see no win here.
> in C (anybody remember X11's imake?) KDE switched to cmake:
That generated "only" a Makefile IIRC.
[...]
> 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".
>
> The first question you should be asking when doing a new build system from
> scratch is probably "should I really be using make"?
>
> > properly recursive,
>
> Recursive make considered harmful:
> http://aegis.sourceforge.net/auug97.pdf
ACK.
> How is needing to call make recursively _not_ just another way of sayng "the
> dependency checking make does, which was the central idea behind its design,
> is a lost cause and we need to jettison it to do builds"?
The problem is that build systems have (at least) two layers:
- the lower are the usual apps and libs and kernel ... bringing their
working Makefile's with them.
- the upper layer needs to build the kernel, libs and apps.
This needs usually a defined sequence and set of consistent
parameters.
But the lower layer doesn't "export" it's local available rule base so
the `make` (or shell script) on the upper layer can't use it and one
must therefore `make -C $tooldir` - even if there is absolutely nothing
to do.
Of course the upper layer may remember if an lib/app has been build to
avoid 60% of all "obviously" useless `make -C` calls. But that doesn't
solve any problem really.
> I just did a "make distclean" on a qemu tree I had lying around. On my 1.7
> ghz 64 bit laptop, it took 9.2 seconds to figure out it had nothing to do,
> just because it had to recurse into so many subdirectories to do it.
"Recursive make considered harmful"
Or you need more RAM and faster disks;-)
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: James Chapman @ 2008-06-13 8:39 UTC (permalink / raw)
To: Mike Frysinger; +Cc: Tim Bird, David VomLehn, weigelt, Linux Embedded Maillist
In-Reply-To: <8bd0f97a0806121456y7a79649bp41d02fee6ae89b@mail.gmail.com>
Mike Frysinger wrote:
> On Thu, Jun 12, 2008 at 5:53 PM, Tim Bird wrote:
>> Mike Frysinger wrote:
>>>> Er, is that GPL or LGPL code that you're modifying? If so, you *have* to
>>>> push those code changes out (make them available to others), whether you
>>>> think people will be interested or not!
>>> umm, not really. only if (1) he gives a binary to someone and (2)
>>> they ask him for the source. if he doesnt distribute or no one asks,
>>> he doesnt have to do squat.
>> This is closer to correct, but missing some important details.
>>
>> Start the GPL compliance tutorial/flameware in 3, 2, 1...
>
> yeah, i really dont think licensing things belong here. sorry for following up.
>
> how about this policy: if you want to make a statement, go pay a
> lawyer. but that statement still shouldnt be made here ;).
> -mike
Sorry, I didn't mean to provoke a GPL flame war. The point I was trying
to make (badly as it turns out) is that if a company really wants to see
its changes taken upstream, it could simply publish the work on its
website and let each relevant community know that it's there. A diff of
the changes would be ideal. This is above and beyond what they have to
do under GPL terms of course. There's no need for a company to filter
out changes that it thinks others won't be interested in.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Bernd Petrovitsch @ 2008-06-13 8:38 UTC (permalink / raw)
To: Alexander Neundorf; +Cc: linux-embedded
In-Reply-To: <200806130843.05704.neundorf@eit.uni-kl.de>
On Fre, 2008-06-13 at 08:43 +0200, Alexander Neundorf wrote:
> On Thursday 12 June 2008 17:50:31 you wrote:
> > On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote:
> > > Rob Landley wrote:
> > > > However, having one or more full-time engineers devoted to debugging
> > > > cross-compile issues is quite a high price to pay too. Moore's law
> > > > really doesn't help that one.
> > > >
> > > > I'm not saying either solution is perfect, I'm just saying the "build
> > > > under emulation" approach 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 agree with much that you have said, Rob, and I understand the argument
> > > for getting the most gain from the least resources, but I have a
> > > philosophical problem with working around the cross-compilation problems
> > > instead of fixing them in the upstream packages (or in the autoconf
> > > system itself).
> > >
> > > Once someone fixes the cross-compilation issues for a package, they
> > > usually stay fixed, if the fixes are mainlined.
> >
> > I don't think that's true, unfortunately. Autoconf makes it _easy_ to do
> > the wrong thing, and people will often introduce new problems.
> >
> > If we just made people write portable code and proper Makefiles, it
> > would be less of an issue :)
ACK. And proper build time tools.
> 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
That can be done as - sooner or later - one must install the compiled
stuff anyway. So one has root directory somewhere and one can tell the
tools.
> -checking if something builds
> -checking the output of running something you just built
And the above are not really a big problem - embedded people usually
know such details and can tell the autoconf tools.
Even worse is (or at least were) tools like pkg_config and libtool,
which generate directories to the build time library.
The only simple solution so far (without diving into the implementation
and searching for root causes) were AFAICS:
- do not use libtool for linking (as the link line as such without
libtool works as expected)
- rewrite generated pkg_config files after generation.
Yes, that's pretty ugly.
But perhaps I was just too dumb to find the correct solutions.
> The last one is the problem for cross compiling.
> Example: detecting the size of ints
Why on earth does someone need this explicitly during the build?
If you have portable software, all of that should be hidden in the code
and use "sizeof(int)".
IMHO the code (or whatever piece uses it) should be fixed and the build
time stuff removed.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: David Woodhouse @ 2008-06-13 7:04 UTC (permalink / raw)
To: Rob Landley
Cc: Robert P. J. Day, Mike Frysinger, Tim Bird, Greg Ungerer,
Sam Ravnborg, Leon Woestenberg, linux-embedded
In-Reply-To: <200806121925.35883.rob@landley.net>
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
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Alexander Neundorf @ 2008-06-13 6:55 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <200806121925.35883.rob@landley.net>
On Friday 13 June 2008 02:25:34 you wrote:
> On Thursday 12 June 2008 11:12:13 Robert P. J. Day wrote:
> > On Thu, 12 Jun 2008, Mike Frysinger wrote:
> > > On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote:
> > > > If we just made people write portable code and proper Makefiles,
> > > > it would be less of an issue :)
> > >
> > > people cant even write proper *native* makefiles. mtd-utils for
> > > example ;).
> >
> > meooowww! :-) but at the risk of dragging this even further
> > off-topic, i am *constantly* asked by people how to set up makefiles
> > for their software project, and what would be nice is a small
> > collection of examples of a makefile (or makefiles) done *right*. as
> > in,
>
> Make doesn't scale.
>
> 99% of the builds in the open source world are "make all", and most of the
> smaller projects build natively on modern dual processor 2ghz laptops in
> under 10 seconds anyway.
>
> The larger projects with significant build times usually find that make
> doesn't suit their needs, so that they write some other build system.
> Sometimes they do it on top of make, such as the kernel's kbuild.
> Sometimes they use another language like apache's ANT. Sometimes they roll
> their own in C (anybody remember X11's imake?) KDE switched to cmake:
> http://lwn.net/Articles/188693/
CMake can create Makefiles on all platforms (including complete dependencies,
i.e. if you build an app which depends even indirectly on some lib then that
lib will be rebuilt before), additionally XCode projects and MSVC projects
(and Eclipse, KDevelop3 and CodeBlocks projects, but these use makefiles
too).
So, we at KDE are still using make mainly, I don't really see how it doesn't
scale (at least it scales much better than scons).
> 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".
We support that in KDE since a long time, with KDE 2.x to 3.x
this "include-all" file was created via autotools, now with KDE 4 it's
created by cmake. It makes compilation of the whole project faster, certainly
not if you are building only a few files.
So, there is not really a roadblock to this.
> The first question you should be asking when doing a new build system from
> scratch is probably "should I really be using make"?
>
> > properly recursive,
>
> Recursive make considered harmful:
> http://aegis.sourceforge.net/auug97.pdf
>
> How is needing to call make recursively _not_ just another way of sayng
> "the dependency checking make does, which was the central idea behind its
> design, is a lost cause and we need to jettison it to do builds"?
>
> I just did a "make distclean" on a qemu tree I had lying around. On my 1.7
> ghz 64 bit laptop, it took 9.2 seconds to figure out it had nothing to do,
> just because it had to recurse into so many subdirectories to do it.
I'm quite sure for a sufficiently large project this will always be the case.
There are thousands of files which have to be checked whether they are
up-to-date, so this takes some time.
> > supports cross-compiling without having to
> > remove your left nad, etc, etc.
>
> Can of worms. Answering that question would be a longer post than the rest
> of this combined, but I've pointed out that I don't think going there is
> worth it anymore for most packages.
>
> > so ... would anyone like to recommend a software package or two
> > somewhere whose makefile(s) is/are, ITHO, done well? that i/we could
> > just point at and say, "do it like that!" anyone? anyone? bueller?
Use CMake >= 2.6.0 (http://www.cmake.org).
It supports cross compiling (... and of course everything else you might ever
need ;-)
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.
Basically only the last one is problematic (but IMO still less problematic
than running a virtual system on the host just to build something).
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.
So really the hard part is getting rid of running stuff to check the platform.
If the project does that, all the build tool can do is support the developer
in finding these spots and caring for them.
Did I mention that getting started with cmake is easy ?
A file CMakeLists.txt containing the following command is all you need for
a "hello world":
add_executable(hello main.c)
Alex
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Alexander Neundorf @ 2008-06-13 6:43 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <1213285831.26255.152.camel@pmac.infradead.org>
On Thursday 12 June 2008 17:50:31 you wrote:
> On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote:
> > Rob Landley wrote:
> > > However, having one or more full-time engineers devoted to debugging
> > > cross-compile issues is quite a high price to pay too. Moore's law
> > > really doesn't help that one.
> > >
> > > 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 agree with much that you have said, Rob, and I understand the argument
> > for getting the most gain from the least resources, but I have a
> > philosophical problem with working around the cross-compilation problems
> > instead of fixing them in the upstream packages (or in the autoconf
> > system itself).
> >
> > Once someone fixes the cross-compilation issues for a package, they
> > usually stay fixed, if the fixes are mainlined.
>
> I don't think that's true, unfortunately. Autoconf makes it _easy_ to do
> the wrong thing, and people will often introduce new problems.
>
> If we just made people write portable code and proper Makefiles, it
> would be less of an issue :)
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
The last one is the problem for cross compiling.
Example: detecting the size of ints
Easy way:
...
printf("%d\n", sizeof(long));
...
and then building and running that code and checking the output. Converting
checks like this, which seem perfectly fine for native builds, to something
which doesn't need to run an executable is not always trivial (but the way to
go if you want to make your package cross-compilable).
(and yes, we converted this test in cmake 2.6 to a build-only test)
Alex
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Alexander Neundorf @ 2008-06-13 6:30 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <8bd0f97a0806121829o6138cb30se025fa3c29cdd1a8@mail.gmail.com>
On Friday 13 June 2008 03:29:52 Mike Frysinger wrote:
> On Thu, Jun 12, 2008 at 9:25 PM, Rob Landley wrote:
> > He recently converted Battle for Wesnoth to use something called "scons"
> > as its build system,
Battle of Wesnoth is currently converted to both Scons and CMake, and in the
end they will decide about the winner.
(since Eric is good at arguing I guess it will be scons).
> > and apparently the resulting make stuff was 1/17th
> > the size of the original.
>
> probably because scons has ~1/17th the functionality of autotools.
> seriously, it's terrible.
I saw the presentation about scons by the main scons developer at FOSDEM this
year and it felt more like a library which you can use to create a
buildsystem, not like a ready-to-use buildsystem itself.
Alex
--
TU-Kaiserslautern
Lehrstuhl für Echtzeitsysteme
Postfach 3049
D-67653 Kaiserslautern
Germany
Tel: +49 (0)631 205 3644
Fax: +49 (0)631 205 4199
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox