* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Enrico Weigelt @ 2008-06-12 20:55 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <20080612185525.7770F24035@gemini.denx.de>
* Wolfgang Denk <wd@denx.de> schrieb:
> In message <20080612181806.GA7423@nibiru.local> you wrote:
> >
> > Perl never was crosscompile-capable.
> > I've rewrote much of the buildscripts, but not finished yet.
>
> Note that Perl is included with our ELDK, and we do cross-compile it.
> It's not exactly trivial, but not really difficult either.
URL ?
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: Kernel boot problem on IXP422 Rev. A
From: Mike Frysinger @ 2008-06-12 20:04 UTC (permalink / raw)
To: Marcus Tangermann; +Cc: linux-embedded
In-Reply-To: <1522484831@web.de>
On Thu, Jun 12, 2008 at 3:35 PM, Marcus Tangermann wrote:
> we currently try to boot a 2.6.21 kernel
time to upgrade
> on a custom IXP422 based board.
you'll have better luck asking on the arm kernel mailing lists. they
process this stuff every day.
-mike
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: George G. Davis @ 2008-06-12 19:54 UTC (permalink / raw)
To: Shaz; +Cc: weigelt, Linux Embedded Maillist
In-Reply-To: <7b740b700806121202w73c7f442k1bf8625e375b83df@mail.gmail.com>
On Fri, Jun 13, 2008 at 12:02:06AM +0500, Shaz wrote:
> On Thu, Jun 12, 2008 at 11:49 PM, Enrico Weigelt <weigelt@metux.de> wrote:
> > * Bill Traynor <wmat@naoi.ca> schrieb:
> >
> >> 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'd also like to mention Yann's crosstool-ng :)
> I guess I have to reconsider cross-tool because earlier I visited this
> http://www.kegel.com/crosstool/crosstool-0.43/buildlogs/ and I want to
> get the latest kernel up and running on OSK OMAP5912, arm9. The board
> is in process of shipment but I started out with a qemu
> (arm-generic/versatilepb) based test run.
>
> I am in the middle of a confused experience :-)
I've used this to build cross compilers (which worked ok for me : ):
http://code.google.com/p/jicknan/source/browse/trunk/bin/toolchain-eglibc.sh
As usual, YMMV, good luck, HTH!
--
Regards,
George
^ permalink raw reply
* Kernel boot problem on IXP422 Rev. A
From: Marcus Tangermann @ 2008-06-12 19:35 UTC (permalink / raw)
To: linux-embedded
Hello,
we currently try to boot a 2.6.21 kernel on a custom IXP422 based board. The boot loader (U-Boot) works fine so far, memory and flash test run successfully, the NPE is also able to ping a host. So we assume the board itself is more or less working at least.
When we try to boot a 2.6.21 kernel after uncompressing the kernel the boot process dies somehow. We've figured out so far that the kernel dies somewhere between the gunzip and start_kernel.
I would be glad for any hint to be able to solve the problem.
Thank you a lot in advance.
Best regards
Marcus
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Glenn Henshaw @ 2008-06-12 19:30 UTC (permalink / raw)
To: Shaz; +Cc: linux-embedded
In-Reply-To: <7b740b700806121052n2f98dfa4hc96ebfc1be5b6bbf@mail.gmail.com>
On 12-Jun-08, at 1:52 PM, 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.
I've built compiler chains for clients using buildroot.
From my notes:
* download buildroot and expand it in your home directory
* make menuconfig - select kernel, compiler, and uclibc versions.
(2.4.27, 3.4.3, and 0.9.28 respectively), set target to final
destination ,i.e., /opt/armeb as you can't move the compiler once built
* make - this will download compiler, etc and build it. It will most
likely fail the first time.
* patches to apply (http://bugs.uclibc.org/view.php?id=51 - fix LFS
requirements)
* make - again to finish
... Glenn
--
Glenn Henshaw Logical Outcome Ltd.
e: thraxisp@logicaloutcome.ca w: www.logicaloutcome.ca
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Mike Frysinger @ 2008-06-12 19:02 UTC (permalink / raw)
To: Josh Boyer
Cc: David Woodhouse, Tim Bird, Rob Landley, Greg Ungerer,
Sam Ravnborg, Leon Woestenberg, linux-embedded
In-Reply-To: <625fc13d0806121129h23eb919dt3661016f82aad266@mail.gmail.com>
On Thu, Jun 12, 2008 at 2:29 PM, Josh Boyer wrote:
> On Thu, Jun 12, 2008 at 12:05 PM, Mike Frysinger wrote:
>> On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse 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 :)
>>
>> 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 ...
-mike
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Shaz @ 2008-06-12 19:02 UTC (permalink / raw)
To: weigelt; +Cc: Linux Embedded Maillist
In-Reply-To: <20080612184927.GA8363@nibiru.local>
On Thu, Jun 12, 2008 at 11:49 PM, Enrico Weigelt <weigelt@metux.de> wrote:
> * Bill Traynor <wmat@naoi.ca> schrieb:
>
>> 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'd also like to mention Yann's crosstool-ng :)
I guess I have to reconsider cross-tool because earlier I visited this
http://www.kegel.com/crosstool/crosstool-0.43/buildlogs/ and I want to
get the latest kernel up and running on OSK OMAP5912, arm9. The board
is in process of shipment but I started out with a qemu
(arm-generic/versatilepb) based test run.
I am in the middle of a confused experience :-)
>
>
> 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/
> ---------------------------------------------------------------------
> --
> 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
Security Engineering Research Group,
Institute of Management Sciences,
Peshawar, Pakistan
Group: http://serg.imsciences.edu.pk
Email: shazalive@gmail.com
cell: +92 300 5944647
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Bill Gatliff @ 2008-06-12 19:00 UTC (permalink / raw)
To: weigelt; +Cc: Linux Embedded Maillist
In-Reply-To: <20080612183421.GD7423@nibiru.local>
Enrico Weigelt wrote:
> * Bill Gatliff <bgat@billgatliff.com> schrieb:
>
>> If the build system derives from autoconf, then a hacked-up
>> config.cache (or equivalent command-line args) often solves
>> problems for me.
>
> Only if you're working on *one specific* target for a long time.
> I, for example, have to support lots of different targets, so your
> approach does not work for me.
I'm not exactly a one-specific-target kinda guy, either. I routinely move
between MIPS, ARM, PPC and x86.
Yea, that means target-specific config.cache files. But that works for me.
> Ah, and it's not *solving* any problem,
> just deferring it to some other day.
If "solving" means helping the tool get the answer it needs, even when running
in an environment/configuration it wasn't intended for, without breaking
compatibility with everyone else out there still using the same tool, then I
disagree.
But hey, I never said you had to do it my way. :)
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Wolfgang Denk @ 2008-06-12 18:57 UTC (permalink / raw)
To: weigelt; +Cc: Linux Embedded Maillist
In-Reply-To: <20080612183057.GC7423@nibiru.local>
In message <20080612183057.GC7423@nibiru.local> you wrote:
>
> > Since perl was mentioned, it also makes a good example. Embedded distros
> > have been cross-compiling perl for pretty much the last decade, yet even
>
> Now I'm curious: where can I find a patch ?
See for example:
http://git.denx.de/?p=eldk/build.git;a=tree;f=target_rpms/perl;h=fd830dd2e6bf86703fab84b83922eea8c10f0310;hb=3e5c010c91e17e819048937eb4105d762c7e1497
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Nothing is easier than to denounce the evildoer; nothing is more
difficult than to understand him. - Fyodor Dostoevski
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Bill Gatliff @ 2008-06-12 18:56 UTC (permalink / raw)
To: Shaz; +Cc: linux-embedded
In-Reply-To: <7b740b700806121052n2f98dfa4hc96ebfc1be5b6bbf@mail.gmail.com>
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.
I like running emdebian's toolchains on a Debian box, myself.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Wolfgang Denk @ 2008-06-12 18:55 UTC (permalink / raw)
To: weigelt; +Cc: Linux Embedded Maillist
In-Reply-To: <20080612181806.GA7423@nibiru.local>
In message <20080612181806.GA7423@nibiru.local> you wrote:
>
> Perl never was crosscompile-capable.
> I've rewrote much of the buildscripts, but not finished yet.
Note that Perl is included with our ELDK, and we do cross-compile it.
It's not exactly trivial, but not really difficult either.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I have a theory that it's impossible to prove anything, but I can't
prove it.
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Bernhard Fischer @ 2008-06-12 18:50 UTC (permalink / raw)
To: Mike Frysinger
Cc: Paul Mundt, Bill Gatliff, David Woodhouse, Tim Bird, Rob Landley,
Greg Ungerer, Sam Ravnborg, Leon Woestenberg, linux-embedded
In-Reply-To: <8bd0f97a0806120938m4ee781e5v7c68f5a777c948a8@mail.gmail.com>
On Thu, Jun 12, 2008 at 12:38:42PM -0400, Mike Frysinger wrote:
>On Thu, Jun 12, 2008 at 12:31 PM, Paul Mundt wrote:
>> On Thu, Jun 12, 2008 at 11:28:10AM -0500, Bill Gatliff wrote:
>>> 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.
>>
>> Yes, that's the easy case. It's things like perl that are the corner
>> cases, and my objection comes from the fact that people think we ought to
>> not have the kernel depend on perl rather than just fixing the package
>> itself. Autoconf/libtool damage is an entirely different problem :-)
>
>of the core packages, perl and openssl tend to be heavily damaged.
>openssl because it depends on perl instead of a real build system.
It's also a pity that automake doesn't work with microperl. And even for
the most simple .pm you have to do perlward^Wawkward stuff like
ifeq ($(BR2_PACKAGE_AUTOMAKE),y)
# we need to build a perl for the host just for Errno.pm
(cd $(MICROPERL_DIR); ./Configure -de; \
$(MAKE) CC="$(HOSTCC)"; \
$(SHELL) ext/util/make_ext nonxs Errno MAKE="$(firstword $(MAKE))"; \
)
endif
(cd $(MICROPERL_DIR); chmod u+w uconfig.h; . ./uconfig.sh; \
$(MAKE) -f Makefile.micro regen_uconfig; \
[snip rest of the misery]
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Enrico Weigelt @ 2008-06-12 18:49 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <402b1f4b315f572ac6459f78fa8b5ee4.squirrel@www.geekisp.com>
* Bill Traynor <wmat@naoi.ca> schrieb:
> 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'd also like to mention Yann's crosstool-ng :)
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-12 18:39 UTC (permalink / raw)
To: Shaz; +Cc: linux-embedded
In-Reply-To: <7b740b700806121052n2f98dfa4hc96ebfc1be5b6bbf@mail.gmail.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.
>
> 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
>
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Enrico Weigelt @ 2008-06-12 18:37 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <48514D77.4060007@am.sony.com>
* Tim Bird <tim.bird@am.sony.com> schrieb:
> If autoconf is the problem (and I think it is), then that's what
> should be fixed (see my original post).
ACK. One of the first things I did was replacing libtool and
kicked off broken-by-design macros like AC_TRY_RUN. This solved
at >80% of the problems for me.
> At a minimum, it would be nice if it had more built-in detection
> and warning of techniques that were dangerous for cross-compilation.
Meanwhile, autoconf warns on some broken macros like AC_TRY_RUN.
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-12 18:34 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <48514E9A.3080901@billgatliff.com>
* Bill Gatliff <bgat@billgatliff.com> schrieb:
> If the build system derives from autoconf, then a hacked-up
> config.cache (or equivalent command-line args) often solves
> problems for me.
Only if you're working on *one specific* target for a long time.
I, for example, have to support lots of different targets, so your
approach does not work for me. Ah, and it's not *solving* any problem,
just deferring it to some other day.
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-12 18:30 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <20080612160845.GB9327@linux-sh.org>
* Paul Mundt <lethal@linux-sh.org> schrieb:
> The other issue is that people that are working in this space tend to do
> very little beyond solving their immediate troubles.
Sad but true :(
> Since perl was mentioned, it also makes a good example. Embedded distros
> have been cross-compiling perl for pretty much the last decade, yet even
Now I'm curious: where can I find a patch ?
Upstream's build scripts are really far from being cross'able.
> You can either try to fix the packages in question, convince the package
> developers to rip out the parts that cause trouble for your environment,
> fix your own build environment to meet the needs of the packages, or
> whine about it on a mailing list. Empirically we already know which one
> of those options is going to win out. ;-)
I, personally, prefer to *solve* problems instead of trying to work
around somehow. In longer terms, this worked quite good for me.
Of course, fixing requires that you find out what's the problem
really is before ;-P
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: Josh Boyer @ 2008-06-12 18: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: <8bd0f97a0806120905u532ce5f9sf231e185173de791@mail.gmail.com>
On Thu, Jun 12, 2008 at 12:05 PM, Mike Frysinger <vapier.adi@gmail.com> wrote:
> On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse 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 :)
>
> people cant even write proper *native* makefiles. mtd-utils for example ;).
What's wrong with it? I'll fix it.
josh
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Matthias Kaehlcke @ 2008-06-12 18:26 UTC (permalink / raw)
To: Shaz; +Cc: linux-embedded
In-Reply-To: <7b740b700806121052n2f98dfa4hc96ebfc1be5b6bbf@mail.gmail.com>
El Thu, Jun 12, 2008 at 10:52:44PM +0500 Shaz ha dit:
> 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.
crosstool-ng looks like a promising option:
http://ymorin.is-a-geek.org/dokuwiki/projects/crosstool
--
Matthias Kaehlcke
Embedded Linux Engineer
Barcelona
Nationalism is an infantile disease. It is the measles of mankind
(Albert Einstein)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Enrico Weigelt @ 2008-06-12 18:25 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <200806111941.51221.rob@landley.net>
* Rob Landley <rob@landley.net> schrieb:
> Cross compiling breaks stuff, yes.
>
> Most packages don't cross compile at all. Debian has somewhere north of
> 30,000 packages. Every project that does large scale cross compiling
> (buildroot, gentoo embedded, timesys making fedora cross compile, etc) tends
> to have about 200 packages that cross compile more or less easily, another
> 400 or so that can be made to cross compile with _lot_ of effort and a large
> enough rock, and then the project stalls at about that size.
The problem is: most embedded projects don't make really general-purpose
fixes (instead strange things like hacking up autogenerated files), so
they can't feed back to upstream.
IMHO, a huge waste of working time.
Did someone ever hear of the OSS-QM project ?
> Some of the other build systems out there hook qemu application emulation up
> to the kernel's misc binary support so a ./configure that builds arm
> executables can run them.
WTF ?!
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: Wolfgang Denk @ 2008-06-12 18:19 UTC (permalink / raw)
To: Shaz; +Cc: linux-embedded
In-Reply-To: <7b740b700806121052n2f98dfa4hc96ebfc1be5b6bbf@mail.gmail.com>
In message <7b740b700806121052n2f98dfa4hc96ebfc1be5b6bbf@mail.gmail.com> you wrote:
>
> I have been following "Re: [PATCH 0/1] Embedded Maintainer(s)" and
> felt like asking that is there one good way to get a cross compiler
> work. I tried buildroot, scratchbox and even openMoko with
> openEmbedded but all of them had lots of issues and don't know which
> will be the best alternative.
>
> I also went through the material provided freely by Free Electron but
> still I am not successful to build a custom kernel. Next I am trying
> MontaVista's kit. I just wish I don't get lost.
For completeness, there is also the (free) ELDK. Some people are using it.
[And yes, I'm obviously biased :-) ]
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A list is only as strong as its weakest link. -- Don Knuth
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Enrico Weigelt @ 2008-06-12 18:18 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <200806110025.27575.rob@landley.net>
* Rob Landley <rob@landley.net> schrieb:
Hi,
> There's also qemu. You can native build under emulation.
did you ever consider that crosscompiling is not only good for
some other arch, but a few more things ?
> In addition, if you have a cross compiler but don't want to spend all your
> time lying to ./configure, preventing gcc from linking against the host's
> zlib or grabbing stuff out of /usr/include that your target hasn't got, or
#1: use a proper (sysroot'ed) toolchain
#2: fix broken configure.in's (and feed back to upstream or OSS-QM)
#3: replace libtool by unitool
> trying to figure out why on EARTH the perl build decided to use x86 signal
Perl never was crosscompile-capable.
I've rewrote much of the buildscripts, but not finished yet.
Just in case that anyone's interested in it, let me know.
> libraries are linked inside the emulator, anything that wants to look
> at /proc or sysinfo does it natively inside the emulator...)
Only crap sw looks at /proc at build time.
Yes, there's *much* crap sw out there :(
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
* Cross Compiler and loads of issues
From: Shaz @ 2008-06-12 17:52 UTC (permalink / raw)
To: linux-embedded
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.
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.
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
^ permalink raw reply
* [ANNOUNCE] ELCE 2008 Call for Presentations
From: Tim Bird @ 2008-06-12 17:47 UTC (permalink / raw)
To: linux-embedded
OK - at the extreme risk of burning up whatever karma I have on
this list, I'm posting this notice. I promise not to do this very often.
(maybe two or three times a year, and only for events I help run.)
--------------
EMBEDDED LINUX CONFERENCE EUROPE - November 6,7 2008, EDE, THE NETHERLANDS
I would like to invite you to make a presentation at CELF's
upcoming Embedded Linux Conference - Europe.
The conference will be held November 6 and 7 in Ede, The Netherlands, in
conjunction with the NLUUG Autumn Conference on Mobile Computing.
See http://www.embeddedlinuxconference.com/elc_europe08/ for general
information on the ELC-E event.
Details on the NLUUG conference, including the CfP will be availalable at
http://www.nluug.nl/events/nj08/
For details on submitting a proposal, please have a look at
http://tree.celinuxforum.org/CelfPubWiki/ELCE2008CallForPresentations
--------------
I'll be there, probably talking (program committee willing) about some
boot-up time improvements I hope to try and mainline before then.
-- Tim
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Sam Ravnborg @ 2008-06-12 17:23 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded
In-Reply-To: <48515978.8040603@billgatliff.com>
On Thu, Jun 12, 2008 at 12:14:32PM -0500, Bill Gatliff wrote:
> Paul Mundt wrote:
>
> > Yes, that's the easy case. It's things like perl that are the corner
> > cases, and my objection comes from the fact that people think we ought to
> > not have the kernel depend on perl rather than just fixing the package
> > itself. Autoconf/libtool damage is an entirely different problem :-)
> >
>
> At first glance, it seems like checkincludes.pl could be duplicated by egrep |
> uniq | wc vs. egrep | wc. Not quite sure what checkversion.pl is trying to do.
>
> The namespace.pl script looks optional, as does export_report.pl.
>
> So maybe we could _reduce_ dependency on perl, if there's any advantage to gain
> by doing so. But the kernel build machinery isn't dependent on very many other
> systems (just tcl, bash and gcc-core), so I don't really see the point unless
> you could completely eliminate perl. And I don't see how you might do *that*
> without dragging in a bunch of stuff to replace it, thereby increasing the
> number of dependencies.
All the noise about the perl dependency of the kernel build are
rooted in two things:
1) That we now have a mandatory part of the build that uses perl (see kernel/Makefile)
2) That I told that I consider rewriting the core of the build system in perl
As for 1) I have seen a patch submitted once. And I do not hear many complaint either,
albeit Rob Landley is a bit loud here (and he was also the one submitting the patch).
That patch was not acceptable as is - and noone has updated it.
As for 2) then let see if that ever happens ;-)
Sam
^ 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