> I guess I don't follow that logic. Why would someone > unfamiliar with > uClinux not choose a toolchain from the links on that > page?
If you go to the arm website and look for uclinux you find the following page http://www.arm.com/products/os/linux_download.html Which references codesourcery 'Source and binary versions of the GNU GCC compiler are available from www.codesourcery.com' so I guess people download the uclinux source from you and then try and compile with codesourcery, I was thinking about doing the same thing. I would like to try and port uclinux to a Actel cortex-M1 FPGA to make a start on this I need a gcc compiler with the -mcpu=cortex-m1 target switch (ie gcc 4.4.2). Anyone how needs / wants to run uclinux on Arms new cortex chips needs to use a newer compile (minimum 4.3.0). How much work would it be to upgrade the uClinux Arm tool chain to use a newer version of gcc? (sorry if this question is a bit basic never really played around with tool chains before) --- On Mon, 11/23/09, Greg Ungerer <g...@snapgear.com> wrote: > From: Greg Ungerer <g...@snapgear.com> > Subject: Re: [uClinux-dev] ARM support > To: "uClinux development list" <uclinux-dev@uclinux.org> > Date: Monday, November 23, 2009, 5:36 AM > > Hi, > > ucli...@browserseal.com > wrote: > > On 11/18/2009, "Greg Ungerer" <g...@snapgear.com> > wrote: > >> ucli...@browserseal.com > wrote: > >>> I'm trying to compile the latest version of > uClinux on ARM and the > >>> multitude of errors that I'm getting leads me > to believe that this > >>> architecture simply is not supported anymore, > hence the first question - > >>> what happened to ARM support and uClinux in > general ? Last time I > >>> checked, i.e. about two years ago, it was > probably the most popular > >>> embedded distro, at least for ARM - and now it > does not even compile ! > >> You are wrong, it does compile. I have an > automated build system that > >> builds approximately 150 board/kernel/lib > combinations(*) each night. > >> Every release is run through this. It compiles > GDB/ARMulator with > >> linux-2.4.x and linux-2.6.x kernels and both > little and big endian > >> and the GDB/Skyeye target with 2.4.x and 2.6.x > kernels (using my > >> arm-linux- toolchains). > >> > >> (* of course the whole uClinux-dist tree has way > more than 150 possible > >> combinations of board/kernel/lib. With the > resources I have that is > >> about as much as I can cover in a single day. I > have just chosen a > >> variety of interesting targets on a variety of CPU > types to test > >> compile for). > >> > >> > >>> I will send a separate email with compilation > errors, I just think that > >>> it would be better to have a separate thread > for this general > >>> discussion. Provided there is anybody out > there interested in discussing > >>> ARM, which I seriously doubt. > >> Are you serious? > >> > >> The only conclusion I can draw from your problems > is that people who > >> choose to use various other toolchains with the > uClinux-dist don't > >> choose to send patches back to make them work > properly with the > >> dist. > > > > I believe I did provide a complete list of the changes > required to > > compile uClinux with this other, i.e. Codesourcery, > toolchain and you > > did say that you think it is the toolchain that has to > be changed. What > > did I miss ? > > Patches please. > > > > Please note that people new to uClinux are most likely > to use > > Codesourcery toolchain, rather than 2007 one from > uClinux web site. > > I guess I don't follow that logic. Why would someone > unfamiliar with > uClinux not choose a toolchain from the links on that > page? > > Sure I would like to see the dist code work with lots of > toolchains. > And I don't want to put a warning like "you must use these > toolchains" > on the download pages. > > Regards > Greg > > > > > P.S. I'm not here to blame anybody, but rather try to > make uClinux > > better. It did take me some time, a few days to be > exact, to find and > > summarize the solutions to all the issues with > these other toolchain. > > > >> Regards > >> Greg > >> > >> > >> > ------------------------------------------------------------------------ > >> Greg Ungerer -- Principal > Engineer EMAIL: > g...@snapgear.com > >> SnapGear Group, McAfee > > PHONE: +61 7 3435 2888 > >> 825 Stanley St, > > FAX: > +61 7 3891 3630 > >> Woolloongabba, QLD, 4102, Australia > WEB: http://www.SnapGear.com > >> _______________________________________________ > >> uClinux-dev mailing list > >> uClinux-dev@uclinux.org > >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > >> This message was resent by uclinux-dev@uclinux.org > >> To unsubscribe see: > >> http://mailman.uclinux.org/mailman/options/uclinux-dev > > _______________________________________________ > > uClinux-dev mailing list > > uClinux-dev@uclinux.org > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > > This message was resent by uclinux-dev@uclinux.org > > To unsubscribe see: > > http://mailman.uclinux.org/mailman/options/uclinux-dev > > > > > -- > ------------------------------------------------------------------------ > Greg Ungerer -- Principal Engineer > EMAIL: g...@snapgear.com > SnapGear Group, McAfee > PHONE: > +61 7 3435 2888 > 8 Gardner Close > > FAX: > +61 7 3217 5323 > Milton, QLD, 4064, Australia > WEB: http://www.SnapGear.com > _______________________________________________ > uClinux-dev mailing list > uClinux-dev@uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev@uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
