User login
Main Menu
New forum topics
We Accept:
5Man Partners
Adventures in root filesystems and cross toolchains!
The real idea is this: It's a pain in the ass to figure out what packages you need and what configuration you need to get a working toolchain for a target board, and it's not easy to fit together the pieces. I mean, really. What version of binutils, with which options in conjunction with what version of gcc and uclibc?
Buildroot has documentation here.
Per the documentation, I fetch the latest code via svn (svn co svn://uclibc.org/trunk/buildroot), and after a few moments of download, I'm the proud owner of revision 19195.
I proceed to 'make menuconfig':
I'm working with a dev-board from www.kwikbyte.com, so I pick arm, and arm920t for the architecture and variant, respectively.
Per this article I opt for EABI.
I enable fortran, c++, java (hey, you never know, I could break down and start writing OO code....)
I also enable "Use software floating point by default".
I enable bash shell, bzip2 diffutils, and a slew of development stuff, including fakeroot...
I enable some audio, and network stuff, and flag perl and python to be enabled.
I enable arm and atmel support, and then I decide it's time to give this baby a try, so I exit, and I 'make'
I'm prompted by the "uClibc Configuration" and I select option 6, arm920t, and I select 'n' for the BX in function return.
and then.... I wait. This would seem a good time to take a break.
(Note, that I couldn't get mpfr.org to respond, so I couldn't download the sources that were necessary. I found them hiding here.
And... BAM!
The build errors in compiling gcc-- "internal segmentation fault" while building libgfortran.
To try and simplify errors, I turn off fortran, as well as java. Note, that you must explicity disable gmp, and mpfr, or these will cause trouble also.
CVS also failed to build, so I disabled this.
After disabling, and trying to re-build, I found that the toolset is still trying to compile things that I de-selected (gmp, mpfr) and unfortunately, failing on mpfr. I ended up svn'ing a fresh copy of the source, copying over my .config file and my dl directory, and running again. This time, it actually completed, claiming to have built a working platform.
I'll test it and find out, and then I'll post testdrive comments here.
Dan Kegel (of crosstool fame) has a good matrix of toolchain build results. For me, the major point of note is that ARM with soft float is entirely "fail" for gcc 4.0.2 and above. This indicates some trouble, eh?
This is only a real problem if you have some need to have the latest compilers running your little arm-softloat chip. I have no such *need* but the geek in me wants to see if it can be made to work....
LD libuClibc-0.9.29.so
libc/libc_so.a(difftime.os): In function `difftime':
difftime.c:(.text+0x8): undefined reference to `__floatsidf'
difftime.c:(.text+0x2c): undefined reference to `__subdf3'
libc/libc_so.a(_fpmaxtostr.os): In function `_fpmaxtostr':
_fpmaxtostr.c:(.text+0xe0): undefined reference to `__nedf2'
_fpmaxtostr.c:(.text+0x104): undefined reference to `__eqdf2'
_fpmaxtostr.c:(.text+0x120): undefined reference to `__divdf3'
_fpmaxtostr.c:(.text+0x12c): undefined reference to `__ltdf2'
_fpmaxtostr.c:(.text+0x1e0): undefined reference to `__muldf3'
_fpmaxtostr.c:(.text+0x394): undefined reference to `__gedf2'
_fpmaxtostr.c:(.text+0x424): undefined reference to `__floatunsidf'
libc/libc_so.a(__psfs_do_numeric.os): In function `__psfs_do_numeric':
__psfs_do_numeric.c:(.text+0x548): undefined reference to `__truncdfsf2'
libc/libc_so.a(strtof.os): In function `strtof':
strtof.c:(.text+0x1c): undefined reference to `__extendsfdf2'
libc/libc_so.a(__strtofpmax.os): In function `__strtofpmax':
__strtofpmax.c:(.text+0x158): undefined reference to `__adddf3'
Seems to be a popular problem without any source giving a good solution....
For this particular issue, it seems that there's a patch that can be readily applied...
In buildroot, if you add a patch in your buildroot/toolchain/gcc/4.2.1/ directory (I'm trying to build 4.2.1)
--- gcc/gcc/config/arm/t-linux +++ gcc/gcc/config/arm/t-linux @@ -4,7 +4,10 @@ LIBGCC2_DEBUG_CFLAGS = -g0 LIB1ASMSRC = arm/lib1funcs.asm -LIB1ASMFUNCS = _udivsi3 _divsi3 _umodsi3 _modsi3 _dvmd_lnx +LIB1ASMFUNCS = _udivsi3 _divsi3 _umodsi3 _modsi3 _dvmd_lnx \ + negdf2 _addsubdf3 _muldivdf3 _cmpdf2 _unorddf2 _fixdfsi _fixunsdfsi \ + _truncdfsf2 _negsf2 _addsubsf3 _muldivsf3 _cmpsf2 _unordsf2 \ + _fixsfsi _fixunssfsi # MULTILIB_OPTIONS = mhard-float/msoft-float # MULTILIB_DIRNAMES = hard-float soft-float
I originally found this solution here which seems to indicate the issue is years old...
Unfortunately, I still can't test the system to see if I've produced a "working" toolchain-- because I'm also trying to use NPTL it turns out I can't use uClibc-0.9.29, as it lacks NPTL support...
Digging extensively to try and find an "official" nptl patch against uClibc, I came across a recent discussion regarding development of uClibc, the prospects for nptl support, etc.
It's discouraging to say the least, as I've also seen discussions regarding issues building this rig without nptl-- but I'll give it a shot. If I can make it work without NPTL, that might work until the uClibc catches up with the word. If not, I'll either have to find another library or increase my target system's storage space.
This site is optimized for Mozilla Firefox. The 5Man logo and Five Man Conspiracy are registered trademarks of Five Man Conspiracy Corporation. © 2011