Buildroot - new Processor Target options

[twobob]

Users of buildroot may note the recent addition of revisions for the arm1136jf_s processor targets.

(pictured)

[root@kindle root]# cat /proc/cpuinfo

Processor : ARMv6-compatible processor rev 3 (v6l)
BogoMIPS : 255.59
Features : swp half thumb fastmult vfp edsp java
CPU implementer : 0x41
CPU architecture: 6TEJ
CPU variant : 0x1
CPU part : 0xb36
CPU revision : 3

I think we are good to go with rev 1 therefore...

according to http://infocenter.arm.com/help/index.../I1022730.html

and http://infocenter.arm.com/help/index.../Babgbeed.html

Noted here for posterity and reference.

[twobob]

In addition to this... I will be trying the 2012.03 Toolchain with
CFLAGS="-mabi=aapcs-linux -mfloat-abi=softfp" for building on the earlier devices via buildroot today at some point.

See what breaks. I note QT5 has FINALLY made an appearance so possibly I'll chuck that in for kicks.

And why not "Prefer Static Libraries" to really try and break things. : )

[twobob]

And why not "Prefer Static Libraries" ??

networking/lib.a(inetd.o): In function `reread_config_file':
inetd.c:(.text.reread_config_file+0x988): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
networking/lib.a(netstat.o): In function `ip_port_str':
netstat.c:(.text.ip_port_str+0x48): warning: Using 'getservbyport' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
networking/lib.a(inetd.o): In function `reread_config_file':
inetd.c:(.text.reread_config_file+0x8e8): warning: Using 'getrpcbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

lol... that's why not... turning it off now then

[NullNix]

Originally Posted by twobob

And why not "Prefer Static Libraries" ??

networking/lib.a(inetd.o): In function `reread_config_file':
inetd.c:(.text.reread_config_file+0x988): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
networking/lib.a(netstat.o): In function `ip_port_str':
netstat.c:(.text.ip_port_str+0x48): warning: Using 'getservbyport' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
networking/lib.a(inetd.o): In function `reread_config_file':
inetd.c:(.text.reread_config_file+0x8e8): warning: Using 'getrpcbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

lol... that's why not... turning it off now then

Yeah, in general the glibc people *hate* static linking. There are no ABI guarantees between glibc releases for .o files and only limited guarantees for .a files: it produces huge binaries (not what you want on a Kindle), and, well, the problem you're seeing is because name resolution depends on dynamic linking anyway, to invoke the NSS libraries! So even a statically linked glibc program has to link in what amounts to a static version of /lib/ld-linux.so.2 anyway. (It's not quite the same as the normal dynamic loader -- it doesn't support dlmopen() for instance -- but it is built from the same source code and is mostly the same. Except that it takes up space in every binary.)

Static linking is for your /bin/busybox and /sbin/sln only (and the latter only because you need it to recover a b0rked glibc installation). Just forget about it for everything else, and you'll be happier.

[twobob]

the above quoted error was actually from the busybox build.
i ended up doing a make clean on the entire BR project to coax the pkg config into meaningful service.
thanks for the other points.

im still ending up with UND symbols. doh. >:|

EDIT trying to do some linker cramming but I know so very little...