RPATHS - edit them by hand? a helpful tool

[twobob]

Buildroot has a tendency to embed unwanted rpaths.

so to fix this for now I have compiled this kindle tool.

Just dump the rpath somewhere on FAT to run it.

Code here:
http://gcc.gnu.org/ml/gcc/1999-04n/msg01105.html

root@kindle:root> rpath
Usage: rpath objectfile [newrpath]


Example of unwanted info:

root@kindle:root> readelf -d /mnt/us/usr/bin/glib-compile-schemas

Dynamic section at offset 0x72b4 contains 28 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libglib-2.0.so.0]
0x00000001 (NEEDED) Shared library: [librt.so.1]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000f (RPATH) Library rpath: [/home/you/GIT/buildroot/output/build/libglib2-2.30.2/glib/.libs]

root@kindle:root> rpath /mnt/us/usr/bin/glib-compile-schemas /mnt/us/usr/lib

/mnt/us/usr/bin/glib-compile-schemas:existing RPATH: /home/you/GIT/buildroot/output/build/libglib2-2.30.2/glib/.libs
/mnt/us/usr/bin/glib-compile-schemas:new RPATH: /mnt/us/usr/lib

now it's fixed. Simples. : )

root@kindle:root> readelf -d /mnt/us/usr/bin/glib-compile-schemas

Dynamic section at offset 0x72b4 contains 28 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libglib-2.0.so.0]
0x00000001 (NEEDED) Shared library: [librt.so.1]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000f (RPATH) Library rpath: [/mnt/us/usr/lib]

Enjoy.

[twobob]

This was built:

export ARCH_FLAGS="-march=armv6j -mtune=arm1136jf-s -mfpu=vfp"
export CFLAGS="-fno-stack-protector -O2 -ffast-math ${ARCH_FLAGS} -pipe -fomit-$
export CXXFLAGS="-fno-stack-protector" CPPFLAGS="-U_FORTIFY_SOURCE"
export HOST=i686-pc-linux
export BUILD=arm-unknown-linux-gnueabi

me@dev ~/src $ arm-none-linux-gnueabi-gcc -o rpath rpath.c

[twobob]

root@kindle:root> readelf -d /mnt/us/bin/rpath

Dynamic section at offset 0x1074 contains 24 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libc.so.6]

root@kindle:root> readelf -h /mnt/us/bin/rpath

ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x84f4
Start of program headers: 52 (bytes into file)
Start of section headers: 4956 (bytes into file)
Flags: 0x5000002, has entry point, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 8
Size of section headers: 40 (bytes)
Number of section headers: 30
Section header string table index: 27

[knc1]

Originally Posted by twobob

Buildroot has a tendency to embed unwanted rpaths.

so to fix this for now I have compiled this kindle tool.

Just dump the rpath somewhere on FAT to run it.

Code here:
http://gcc.gnu.org/ml/gcc/1999-04n/msg01105.html

root@kindle:root> rpath
Usage: rpath objectfile [newrpath]

Nice find.
I thought that function (editing rpath) was included in one of the standard tools, but I guess not.

Having an ARM build of the tool, like you make above, could be handy to fix-up library sickness after installation.

But...

Since you write that this routine is to fix-up the undesired rpath entry left in libraries by Buildroot...

Would it be practical to "hook" it into Buildroot?
I think there is a: "POST_INSTALL_HOOK" that could be used to call (a host version) of that routine on every library built after it is moved from staging into the install image.

- - - - -

PS: Don't lose track of that source code.
It may be just what we need, that with a bit of modification, could write the "AmazonHack" marker into the ELF header.

[twobob]

Yep - you are of course 100% right as per.

Didn't go into why this was handy for us.

Really should stop eliding things for the sake of clarity

Will indeedily keep my mitts on the SC
(and I have shoved it in the zip for good measure

Did my best to show my working out and configs.
Makes the job about 400% longer but meh, someone may actually need it one day.

Is it included in one of the standard thingies? possibly.
It's big world of thingies.

In other news - managed to hack together a working libglib2 - Will close the BR error. Basically it hates the older TC's. Will do a regression through the various chains until I find the break point and report it when the will to live is regained after 4 days of smashing my head against a brick wall.

On the plus side I HAVE learned a great deal about tracing through configure.ac's , configures and makefiles, also about gleaning lateral info from logs.

And, above all, observing the activities of and injecting automation into buildroot. Which was another "big" goal I have been working towards. It will be nice when I have enough understanding to compile a completed *solution* Like this (that's the real-life buildroots link) - ideally with a couple of kindles as choices and all the relevant "Best-practice" TC advice annotated.

It's a huge task when I stand back and look at it. But meh. It will bring US closer to the exact, flexible, deliverable, repeatable, tools and mechanisms we want/need.

right down to creating microkernels, missing modules, low level device tools, file system bits, up through the available networking modules, and higher level softwares and on into the GUI level components, injecting new software, etc etc.

As you say it is all right there, with enough work.
Ah well time to bite the bullet and report the BR error as pebcak.

Someone dig me a hole to crawl into. thanks.

[knc1]

Originally Posted by twobob

As you say it is all right there, with enough work.
Ah well time to bite the bullet and report the BR error as pebcak.

Someone dig me a hole to crawl into. thanks.

The folks on the BR M.L. are not like that, they will cheer that you found the dependency.

If you can locate the gcc version in which that library started to build, then (you or they) can invent a: "if gcc < version, then broke, else works" statement in the make file mess Buildroot system somewhere.

(Probably in the libglib2 config menu, a "depends on ..." statement or two.)

[twobob]

Fair enough. I closed the error with relevant grovelling.

https://bugs.busybox.net/show_bug.cgi?id=5486

: )

[knc1]

Originally Posted by twobob

Fair enough. I closed the error with relevant grovelling.

https://bugs.busybox.net/show_bug.cgi?id=5486

: )

You hit them at just the right time, the BR release is less that 24 hours old:
http://git.buildroot.net/buildroot/

What usually happens next, is that the branch buildroot-next will get merged to mainline ;
And then the things that accumulated while trying to get the release made will get a closer read.

If you are subscribed to the mailing list - you should be getting copies of all bug-report postings.

{brag}
That was my idea, to register the mailing list as a follower of all bug-reports.
{/brag}

EDIT:
Here is one patch already that would effect anyone using the Linaro tool chain posted in the DIY-KeK resource pool:
http://git.buildroot.net/buildroot/c...3d64d12b24469e

[twobob]

Well. I will see what happens. I see that there are already projects that define
certain boards. the beagle board for example maintained by this guy http://blog.galemin.com/ here https://github.com/MaxGalemin/buildr...2012.02-mg01.1

Possibly it may be appropriate to organise in this fashion, lets see what the future dictates.

Really have to get a more solid offering before I shove anything of merit into the BR tree. Sure I can add software and edit dependencies etc now but haven't really tied-down the correct supporting structures yet.

So there is a little job for another day.

I'm currently investigating the possibility of taming a more recent TC 2011.09 into producing natively executable bins, oddly the D/L and install TC's appear to be at odds with the operation of the identical TC configured as a custom TC. More on that if I figure it out...

Thanks for all your support mate.

Another little note for us...

Spoiler:

http://blog.galemin.com/2011/05/linu...3-41-continue/

This is for the A8 (not directly relevant) but the concepts discussed

"The default Linux kernel uses software handlers (traps) for unaligned memory loads."

are of merit to this forum I suspect in the medium term, depending on how far we go into actually replacing the kernel one day.

end of note.

[twobob]

I am currently going back through and compiling - with the *hopefully* relevant flags to tame the new stuff into thinking its old stuff...

Yep Qt, libglib2 back on the books. oddly BR wont build libgtk2 so clearly some squirreled away dependency is unmet in my new, lean "only build what is missing" config.

INSTALLLIBGLIB_TO_TARGET or something I think. I'll find it.. in the end

Ah well almost now compiled and run the entire buildroot offering tree on a kindle 3.
with the relevant headers and flags in place.

next steps: Test new built applications - with badly mismatched tc

Insert kindle version specific MAKE code to add video support for the FB capable packages.

Insert code and hooks to manage more sensible rpaths, initial prefix's, and post install locations.

organise the BR structure to the "proper" managed structure and push it up to our BuildrootKindle Git.

[twobob]

Hmm. Found it. libgtk2 now relies on building basic X support. meh.

so now webkit relies on those two as well.. hmm... I believe we use the awesome window manager. so that's a problem for a kickoff.

just how tough would it be to load a completely USEFUL kernal - i.e Direct FB maybe (okay okay I know its a huge memory suck) and other stuff like Tiny X support perhaps...

I forsee writing some very horrible drivers in my near future.

ah well I'll build it all and see what breaks like usual heh.

[knc1]

That should only be a temporary "fix" because no one had time to fix the problems with the libgtk2 -> frame buffer module.

We "know" it can be done - the K3 browser is a webkit browser running on the frame buffer device.

Just push it down on your to-do list, maybe the BR crew will find the fix before you need to use it.

[twobob]

Yeah. I'll build it anyway and see what that yields.

I get a vague sense that hung together correctly, with the awesome window manager kicked into touch for a spell, this could serve us well.

True we are a display driver definition in the hole but as you say its not a complete nightmare.

One interesting fact (I thought) if one side-by-sides the current QT with FB embedded source (2012) and the Qindle projects additions by "nemo" (2009) you will note they are MIGHTY similar...

Who knew the qt project could be affected by we mere kindle hackers.

Somewhat encouraging.

Onward. I say.

[twobob]

Originally Posted by knc1

{brag}
That was my idea, to register the mailing list as a follower of all bug-reports.
{/brag}

That was a ruddy good idea. thanks for that.

[twobob]

Tested as working on a 5. As is.

[root@kindle root]# rpath /mnt/us/usr/bin/fftw-wisdom

/mnt/us/usr/bin/fftw-wisdom:existing RPATH: /home/me/GIT/brk5/output/build/fftw-3.3/.libs

[root@kindle root]# rpath /mnt/us/usr/bin/fftw-wisdom /mnt/us/usr/libs

/mnt/us/usr/bin/fftw-wisdom:existing RPATH: /home/me/GIT/brk5/output/build/fftw-3.3/.libs

/mnt/us/usr/bin/fftw-wisdom:new RPATH: /mnt/us/usr/libs
[root@kindle root]# rpath /mnt/us/usr/bin/fftw-wisdom

/mnt/us/usr/bin/fftw-wisdom:existing RPATH: /mnt/us/usr/libs