Register Guidelines E-Books Search Today's Posts Mark Forums Read

Go Back   MobileRead Forums > E-Book Readers > Amazon Kindle > Kindle Developer's Corner

Notices

Reply
 
Thread Tools Search this Thread
Old 08-12-2012, 08:41 PM   #1
twobob
( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Tır
twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.
 
twobob's Avatar
 
Posts: 6,586
Karma: 6299991
Join Date: Jun 2012
Location: uti gratia usura (Yao ying da ying; Mo ying da yieng)
Device: PW-WIFI|K5-3G+WIFI| K4|K3-3G|DXG|K2| Rooted Nook Touch
Lightbulb Linking static statically is not just an issue for us.

It came as somewhat a revelation that linking statically (In the sense that I thought of it) was a real chore (it seemed) when x-compiling for the Kindle. The Kindle has older libraries - really very old in some instances - so being able to embed new function is obviously a bonus and in some cases critical.

Niluje, Knc1 and GM discuss one manifestation of such an issue and it may be too broad a problem to simply say DO THIS. But a collection of CHECK YOU DID THIS will not hurt.

Indeed, to some degree solutions have been found and discussed if only in concept.

Essentially: tips about the correct optimal runtime configuration and potential simple steps to prevent issues surrounding these types of builds are spread apart. It would be good to splat them here or on the wiki eventually.

As a side note:

Given our static complications (Indeed in some cases Codesourcery just fell over) I turned an eye to sets of tools that are alleged and expected to work-out-of-the-box. Other larger concerns would surely have ironed out such issues in a JUST WORK way I reasoned. The main tool I tested was Buildroot and I´ll briefly discuss my - now obvious I suppose, but surprising to me - findings.

After some attempts at full static builds; digging through docs and threads to check I wasn´t doing it wrong; consistent failures; In the end I was coming up with exactly the same issues in buildroot as we were experiencing with full statics.

I finally found THIS THREAD from about a month ago that confirms - and I quote

(The full article discusses relocatable chains - I highlighted the relevant part
Quote:

Beware however that, if the host systems are different (eg. you build the
toolchain on a recent distro, and you move the toolchain to an old distro,
or the other way around), you may get problems running the toolchain, as
it will depend on the host libraries to run (after all, gcc et al. are
just binaries that are linked to the host libraries!). Most notably, the
libstdc++ is known to be one of the most common issues.

If this is your case, then you may want to build the toolchain entirely
staticaly linked. AFAIK, in buildroot, only the crosstool-NG backend can
generate such a statically linked toolchain
.
Well knock me down with a feather.

I wish I had known that a few moons ago.

So this post is an aide-memoire and hopefully will underline that even the very big fish still are tousling with the self-same problems we little critters are managing to wrestle with - and in the main - win.

So I guess I am simply reserving this space for the moment when we can simply say AH, that old chestnut, just go see the STATIC STATIC thread (or hopefully the wiki and Index by the time you read this thread).

Either way I can report the major tools don´t fare better than the offerings we play with and that is an eye opener for me.

The grass is not always greener. (Although it may have a few more groundskeepers )

Insert Awesome explanations, Typical Fails and miraculous workarounds below. Kindle specific library known issues warmly welcomed.

Please indicate the exact Kindle Model (dx, 3, 5 etc) OS revision and toolchain for best results.
I don´t claim to have any answers but I can see a cohesive place for them would not hurt.

Many thanks.

Last edited by twobob; 08-12-2012 at 10:34 PM. Reason: whitebait
twobob is offline   Reply With Quote
Old 08-12-2012, 08:45 PM   #2
twobob
( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Tır
twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.
 
twobob's Avatar
 
Posts: 6,586
Karma: 6299991
Join Date: Jun 2012
Location: uti gratia usura (Yao ying da ying; Mo ying da yieng)
Device: PW-WIFI|K5-3G+WIFI| K4|K3-3G|DXG|K2| Rooted Nook Touch
Typical Static Static Fail. This one from Buildroot.

Typical Fail. This time through a buildroot one. But identical to the fail generated using the toolchain direct (well duh but I had to see it for myself)

Spoiler:
Code:
==========
debianutils/lib.a(mktemp.o): In function `mktemp_main':
mktemp.c:(.text.mktemp_main+0xcc): warning: the use of `tempnam' is dangerous, better use `mkstemp'
coreutils/lib.a(id.o): In function `get_groups':
id.c:(.text.get_groups+0x14): warning: Using 'getgrouplist' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
libbb/lib.a(change_identity.o): In function `change_identity':
change_identity.c:(.text.change_identity+0x10): warning: Using 'initgroups' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
loginutils/lib.a(addgroup.o): In function `addgroup_main':
addgroup.c:(.text.addgroup_main+0xa0): warning: Using 'getgrgid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
addgroup.c:(.text.addgroup_main+0x54): warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
libbb/lib.a(change_identity.o): In function `change_identity':
change_identity.c:(.text.change_identity+0x24): warning: Using 'endgrent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
loginutils/lib.a(adduser.o): In function `adduser_main':
adduser.c:(.text.adduser_main+0xe8): warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
adduser.c:(.text.adduser_main+0x17c): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
loginutils/lib.a(deluser.o): In function `deluser_main':
deluser.c:(.text.deluser_main+0x98): warning: Using 'getpwent_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
networking/lib.a(nslookup.o): In function `print_host':
nslookup.c:(.text.print_host+0x40): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
loginutils/lib.a(passwd.o): In function `passwd_main':
passwd.c:(.text.passwd_main+0xf0): warning: Using 'getspnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
libbb/lib.a(inet_common.o): In function `INET_rresolve':
inet_common.c:(.text.INET_rresolve+0xd8): warning: Using 'gethostbyaddr' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
util-linux/lib.a(mount.o): In function `nfsmount':
mount.c:(.text.nfsmount+0xf4): warning: Using 'gethostbyname' 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+0x7e4): 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+0x4c): warning: Using 'getservbyport' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
util-linux/lib.a(mount.o): In function `xdr_fhstatus':
mount.c:(.text.xdr_fhstatus+0xc): undefined reference to `xdr_u_int'
mount.c:(.text.xdr_fhstatus+0x34): undefined reference to `xdr_opaque'
util-linux/lib.a(mount.o): In function `xdr_mountres3':
mount.c:(.text.xdr_mountres3+0xc): undefined reference to `xdr_enum'
mount.c:(.text.xdr_mountres3+0x38): undefined reference to `xdr_bytes'
mount.c:(.text.xdr_mountres3+0x64): undefined reference to `xdr_array'
mount.c:(.text.xdr_mountres3+0x6c): undefined reference to `xdr_int'
util-linux/lib.a(mount.o): In function `xdr_dirpath':
mount.c:(.text.xdr_dirpath+0x4): undefined reference to `xdr_string'
util-linux/lib.a(mount.o): In function `nfsmount':
mount.c:(.text.nfsmount+0x894): undefined reference to `pmap_getmaps'
mount.c:(.text.nfsmount+0xa74): undefined reference to `clntudp_create'
mount.c:(.text.nfsmount+0xab8): undefined reference to `clnttcp_create'
mount.c:(.text.nfsmount+0xad4): undefined reference to `clnt_spcreateerror'
mount.c:(.text.nfsmount+0xae0): undefined reference to `authunix_create_default'
mount.c:(.text.nfsmount+0xb64): undefined reference to `clnt_sperror'
mount.c:(.text.nfsmount+0xb84): undefined reference to `clnt_sperror'
mount.c:(.text.nfsmount+0xd6c): undefined reference to `bindresvport'
mount.c:(.text.nfsmount+0xdb4): undefined reference to `pmap_getport'
collect2: ld returned 1 exit status
make[2]: *** [busybox_unstripped] Error 1
make[1]: *** [/home/me/BLDS/buildroot/build/busybox-1.20.2/.stamp_built] Error 2
make: *** [all] Error 2
twobob is offline   Reply With Quote
Advert
Old 08-12-2012, 08:46 PM   #3
knc1
Going Viral
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
PS: Those are some of the reasons Rob builds a fully static linked, relocatable toolchain.

Ah, maybe I didn't mention that in all of the posts about Emu image. It **IS** a statically linked tool-chain inside of the image.
knc1 is offline   Reply With Quote
Old 08-12-2012, 08:53 PM   #4
twobob
( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Tır
twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.
 
twobob's Avatar
 
Posts: 6,586
Karma: 6299991
Join Date: Jun 2012
Location: uti gratia usura (Yao ying da ying; Mo ying da yieng)
Device: PW-WIFI|K5-3G+WIFI| K4|K3-3G|DXG|K2| Rooted Nook Touch
Quote:
Originally Posted by knc1 View Post
PS: Those are some of the reasons Rob builds a fully static linked, relocatable toolchain.

Ah, maybe I didn't mention that in all of the posts about Emu image. It **IS** a statically linked tool-chain inside of the image.
Excellent. Point 1. Kek project provides a proper statically linked Environment.
That does currently come with a few caveats that are discussed in the KEK thread at greater length.

Thanks very much!

Last edited by twobob; 08-12-2012 at 09:03 PM.
twobob is offline   Reply With Quote
Old 08-12-2012, 09:11 PM   #5
twobob
( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Tır
twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.
 
twobob's Avatar
 
Posts: 6,586
Karma: 6299991
Join Date: Jun 2012
Location: uti gratia usura (Yao ying da ying; Mo ying da yieng)
Device: PW-WIFI|K5-3G+WIFI| K4|K3-3G|DXG|K2| Rooted Nook Touch
Not specifically about the static issue this is a decent place to look for interesting autotool guidance. http://www.flameeyes.eu/autotools-mythbuster/ and my personal interest is in the sections http://www.flameeyes.eu/autotools-my...f/finding.html and http://www.flameeyes.eu/autotools-my...compiling.html Noted here for posterity
twobob is offline   Reply With Quote
Advert
Old 08-12-2012, 10:26 PM   #6
NiLuJe
BLAM!
NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.
 
NiLuJe's Avatar
 
Posts: 13,477
Karma: 26012492
Join Date: Jun 2010
Location: Paris, France
Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E
@twobob: Note that a fully static host toolchain and fully statically linked target binaries are two different beasts. (By 'host' I'm referring to our native Linux distro or whatever you run your TC from, and 'target', the Kindle).

Checking if you actually *really* need a static toolchain is fairly easy, if you're missing some older/newer dependencies (and libstdc++ is indeed a fine exemple of this, in some cases), it will simply fail to *run*, you won't even have to hit *build* failures .

If you build your TC yourself, that should be of fairly minor concern to you, unless you intend to distribute your TC.

On the other hand, fully statically linked *target* binaries are not necessarily a good idea, especially with an (e)glibc based toolchain, like we discussed a few times with knc1 (your second post is a fine exemple a what happens when you try ^^ [well, not the undefined refs]). If for some reason you *really* want fully static binaries, better use an µcLibc TC. But like I said in the post you linked, it's not really necessary on the Kindle.

And I concur on reading up on flameeyes' blog (he's been a Gentoo dev for longer than I've been using Gentoo, FWIW) .

Last edited by NiLuJe; 08-12-2012 at 10:36 PM.
NiLuJe is offline   Reply With Quote
Old 08-12-2012, 10:54 PM   #7
geekmaster
Carpe diem, c'est la vie.
geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.
 
geekmaster's Avatar
 
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
If static-linked target binaries are not good, we need a set of rules on how to build portable apps that run on all eink kindles. Otherwise for my needs I will have to avoid using libraries that cannot be trusted across various models and firmware versions.
geekmaster is offline   Reply With Quote
Old 08-12-2012, 10:59 PM   #8
twobob
( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Tır
twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.
 
twobob's Avatar
 
Posts: 6,586
Karma: 6299991
Join Date: Jun 2012
Location: uti gratia usura (Yao ying da ying; Mo ying da yieng)
Device: PW-WIFI|K5-3G+WIFI| K4|K3-3G|DXG|K2| Rooted Nook Touch
Quote:
Originally Posted by NiLuJe View Post
@twobob: Note that a fully static host toolchain and fully statically linked target binaries are two different beasts. (By 'host' I'm referring to our native Linux distro or whatever you run your TC from, and 'target', the Kindle)...
Heh yeah I see my basic error. Still the principle is mungleable into the same Venn diagram : )

I think I do really want the ability to generate fully static bins going forward and I am going to try out the Crosslib-ng route via buildroot. why not : )

It has a custom skeleton that I am playing with getting something like and once I figure how to splat SYSROOT or/and --prefix / LD_LIBRARY_PATH and anything else I don´t know about yet but really need into it I will look into creating some tools that eventually free us from the need for it.

I´m into my nth (read over 20 30?) incorrect build of my tools but never let utter failure get you down I always think.

the flameeyes links I posted I hoped might provide the correct interim measures that could be a) applied to re-purpose the binaries created during the configure stage for the correct load paths for our target and then b) further process used to correctly seat the resultant created installs into said paths created by fs/skeleton.

True the configuration details are buildroot specific and perhaps no-one can help who hasn´t used it but that doesn´t stop me asking here, and of course continuing to dig on the buildroot site itself.

At least I didn´t embarrass myself by asking the question I was going to ask about x-compiling that had a known solution. I´m trying to save up my questions on that mailing list for the really important stuff. Should we find some. My inability to set basic compiler flags doesn´t qualify. Please someone point me at a man page and hopefully a guide? @___@

One would imagine the section marked PreProcessor Flags (The only section with any such argument entering capability) would be the one to splat stuff at. but --prefix=/mnt/us seems to go ignored - even with the relevant skeleton in place. Clearly PEBCAK.

Sigh, I wish I knew more so I can get stuff done faster, I would be of more use. Still that´s what this whole life thing is all about I suppose.

So yeah. Thanks for the tips. If anyone has a dumbasses guide to splatting stuff into the configures / compiler / etc that would be great. I´ll be pillaging Google in the meantime. Perhaps in the next couple of weeks a day could go by where I don´t have to learn a new skill.

Perhaps.

Further reading for me http://free-electrons.com/blog/buildroot-2011-11/

Last edited by twobob; 08-13-2012 at 01:37 PM. Reason: 30? 40? sigh + further reading
twobob is offline   Reply With Quote
Old 08-12-2012, 11:00 PM   #9
twobob
( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Tır
twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.
 
twobob's Avatar
 
Posts: 6,586
Karma: 6299991
Join Date: Jun 2012
Location: uti gratia usura (Yao ying da ying; Mo ying da yieng)
Device: PW-WIFI|K5-3G+WIFI| K4|K3-3G|DXG|K2| Rooted Nook Touch
^This.

Quote:
Originally Posted by geekmaster View Post
If static-linked target binaries are not good, we need a set of rules on how to build portable apps that run on all eink kindles. Otherwise for my needs I will have to avoid using libraries that cannot be trusted across various models and firmware versions.

^This. Bang on fella.
twobob is offline   Reply With Quote
Old 08-12-2012, 11:13 PM   #10
NiLuJe
BLAM!
NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.
 
NiLuJe's Avatar
 
Posts: 13,477
Karma: 26012492
Join Date: Jun 2010
Location: Paris, France
Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E
@GM: The easiest way is to simply use more or less the same TC as Amazon used on the K2/K3 (GCC 4.1/glibc 2.5/K 2.6.22 IIRC), and try to avoid ABI/API mismatches in bundled 3rd-party libs. If this is unavoidable, statically link *only* the 3rd-party libs. (Same thing if the 3rd-party lib is not bundled with the Kindle, or just ship the shared libs with your app, and tweak LD_LIBRARY_PATH at runtime).

If you're adventurous like me, you *can* use a newer GCC/glibc pair (I'm using Linaro GCC 4.7/glibc 2.9 for my k2/k3 tc), but know that you might have to tweak some C stuff/trick autotools to avoid pulling stuff from newer glibc, and that C++ stuff will probably be a no-go unless you're willing/can statically link libstdc++. (And you'll have to kill gcc's ssp and glibc's fortify support, which is usually a simple matter of correct CPP/CXX/CFLAGS).

If you're targeting the K4/K5, it's way, way neater, since the TC Amazon used is not so freaking ancient (don't remember exactly, but I'd say GCC 4.4/eglibc 2.12/K 2.6.31).

That's what I've been doing so far, without too much trouble .

And remember, readelf is your friend ^^.

Last edited by NiLuJe; 08-12-2012 at 11:59 PM.
NiLuJe is offline   Reply With Quote
Old 08-12-2012, 11:16 PM   #11
twobob
( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Tır
twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.
 
twobob's Avatar
 
Posts: 6,586
Karma: 6299991
Join Date: Jun 2012
Location: uti gratia usura (Yao ying da ying; Mo ying da yieng)
Device: PW-WIFI|K5-3G+WIFI| K4|K3-3G|DXG|K2| Rooted Nook Touch
Update. Even with Cross Tools NG

CVS refuses to build static static. Same error as before about dependencies.
Pkg-Config dies on lookup for Clock_t
sdl 1.2.15 refuses to install - stupid config error no doubt...
qt will not build without c++ support (not an error, merely an observation)

Others tools appear to be going through okay aside from the incorrect flags resulting in foolish install locations. I believe I can override that various stages of the build and inject my values there. I will read the manual again but it´s pretty lightweight on this subject. If I can get this detail cracked (and lib locations / referencing obviously) there is a very nice set of tools here just waiting to be unleashed.

Answers on a postcard. Or here. Thanks : )

Last edited by twobob; 08-12-2012 at 11:22 PM. Reason: added more deaths
twobob is offline   Reply With Quote
Old 08-12-2012, 11:24 PM   #12
twobob
( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Tır
twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.
 
twobob's Avatar
 
Posts: 6,586
Karma: 6299991
Join Date: Jun 2012
Location: uti gratia usura (Yao ying da ying; Mo ying da yieng)
Device: PW-WIFI|K5-3G+WIFI| K4|K3-3G|DXG|K2| Rooted Nook Touch
I have an additional. Possibly stupid. Question.

If an executable is built static static this is the sure-firest way of getting it to be able to be dropped on a device. I.E. when I get all this stuff finally built there is a very high chance most of it will work ; )

You can see why I might be interested : D

Anyways the build has completed. Letś see what I can salvage from this one
Please read relevant licensing for relevant packages.

I might add that these packages right here incorrectly used could probably DO DEVASTATING DAMAGE, well they might muck stuff up like access and where your files live so don´t mess about if you don´t know what they are. Cheers. I won´t be held responsible for you hitting yourself with the hammer I provide. Thanks.
Attached Files
File Type: gz file.tar.gz (84.4 KB, 257 views)
File Type: gz pivot_root.tar.gz (2.9 KB, 241 views)
File Type: gz sudos.tar.gz (501.0 KB, 259 views)
File Type: gz write.tar.gz (6.6 KB, 254 views)
File Type: gz switch_root.tar.gz (5.1 KB, 249 views)

Last edited by twobob; 08-13-2012 at 08:35 AM. Reason: added hammer thingy
twobob is offline   Reply With Quote
Old 08-12-2012, 11:59 PM   #13
NiLuJe
BLAM!
NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.
 
NiLuJe's Avatar
 
Posts: 13,477
Karma: 26012492
Join Date: Jun 2010
Location: Paris, France
Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E
@twobob: Well, unless it's targeted at the wrong arch or potentially CPU/FPU, yes . (I'm leaving the Kernel out of it, assuming we're using adequate kernel headers).
NiLuJe is offline   Reply With Quote
Old 08-13-2012, 12:03 AM   #14
twobob
( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Tır
twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.
 
twobob's Avatar
 
Posts: 6,586
Karma: 6299991
Join Date: Jun 2012
Location: uti gratia usura (Yao ying da ying; Mo ying da yieng)
Device: PW-WIFI|K5-3G+WIFI| K4|K3-3G|DXG|K2| Rooted Nook Touch
Quote:
Originally Posted by NiLuJe View Post
@twobob: Well, unless it's targeted at the wrong arch or potentially CPU/FPU, yes .
I have a whole host of great things here if I can just get the flags passed either at the beginning, during the process, before they install. Or all three.

--prefix=/mnt/us SYSROOT=/mnt/us LD_LIBARARY_PATH=/lib:/mnt/us/lib etc... Kinda thing.

Any clues what I should be reading. Don´t tell me, the man page right.

Anything a bit less sober out there? anyone : D

More specifically: how does one pass all that info into this ridiculous tiny box
answer I suspect is - you don´t
Attached Thumbnails
Click image for larger version

Name:	Selection_003.png
Views:	389
Size:	56.6 KB
ID:	90678  

Last edited by twobob; 08-13-2012 at 12:09 AM.
twobob is offline   Reply With Quote
Old 08-13-2012, 04:23 AM   #15
knc1
Going Viral
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
Quote:
Originally Posted by NiLuJe View Post
If you're adventurous like me, you *can* use a newer GCC/glibc pair (I'm using Linaro GCC 4.7/glibc 2.9 for my k2/k3 tc), but know that you might have to tweak some C stuff/trick autotools to avoid pulling stuff from newer glibc, and that C++ stuff will probably be a no-go unless you're willing/can statically link libstdc++. (And you'll have to kill gcc's ssp and glibc's fortify support, which is usually a simple matter of correct CPP/CXX/CFLAGS).
Using incremental linking stages in the overall construction of a run-time object can accomplish amazing things.

Some Makefiles are constructed to do that from the ground up (usually for very large applications), most small application Makefiles do not have that organization.

But this is hardly a software 101 build subject.
Shoot, it isn't even a Makefile 101 subject.

- - - -

On a related topic (no pun intended) . . . .
Someone wrote a dynamic loader wrapper that allows you to run more than one loader/libc on the same machine.

I.E: at object load time, it checks the elf header, then uses the appropriate dynamic loader.

Translation: You can install and run uClibc linked applications on a glibc system.

If I can just find where I put that link (I was going to build that utility for the K3).

As in:
Code:
core2quad ~ $ /lib/ld-linux.so.2
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked `ld.so', the helper program for shared library executables.
This program usually lives in the file `/lib/ld.so', and special directives
in executable files using ELF shared libraries tell the system's program
loader to load the helper program from this file.  This helper program loads
the shared libraries needed by the program executable, prepares the program
to run, and runs it.  You may invoke this helper program directly from the
command line to load and run an ELF executable file; this is like executing
that file itself, but always uses this helper program from the file you
specified, instead of the helper program file specified in the executable
file you run.  This is mostly of use for maintainers to test new versions
of this helper program; chances are you did not intend to run this program.

  --list                list all dependencies and how they are resolved
  --verify              verify that given object really is a dynamically linked
            object we can handle
  --library-path PATH   use given PATH instead of content of the environment
            variable LD_LIBRARY_PATH
  --inhibit-rpath LIST  ignore RUNPATH and RPATH information in object names
            in LIST
  --audit LIST          use objects named in LIST as auditors
and
Code:
(armv6l:1) /home # /lib/ld-uClibc.so.0
Standalone execution is not enabled
Ah, s..., another thing Rob left out of his configuration and build.

And for those who may have forgotten, glibc is also an executable:
Code:
core2quad ~ $  /lib/i386-linux-gnu/libc-2.13.so
GNU C Library (Ubuntu EGLIBC 2.13-20ubuntu5.1) stable release version 2.13, by Roland McGrath et al.
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled by GNU CC version 4.6.1.
Compiled on a Linux 3.0.17 system on 2012-03-07.
Available extensions:
    crypt add-on version 2.1 by Michael Glad and others
    GNU Libidn by Simon Josefsson
    Native POSIX Threads Library by Ulrich Drepper et al
    BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.
knc1 is offline   Reply With Quote
Reply

Tags
compiling, development, issues, kindle, tools

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Is there anyway to set a static IP address on the Kobo Wifi? saladasalad Kobo Reader 3 07-11-2012 07:22 AM
Content Download a static website to the kindle? scotter Amazon Kindle 1 03-07-2011 06:52 PM
Static screensaver kindle79 Amazon Kindle 2 11-17-2010 02:51 PM
Free Book (Kindle) - The Static of the Spheres koland Deals and Resources (No Self-Promotion or Affiliate Links) 3 06-21-2010 06:24 AM
Static IP grey out rushkk enTourage Archive 1 06-04-2010 11:23 AM


All times are GMT -4. The time now is 05:20 PM.


MobileRead.com is a privately owned, operated and funded community.