Re: ls -l on Android device

Hi Tom, folks,

> On Tue, Feb 2, 2010 at 5:51 AM, Denys Vlasenko <vda.linux <at> googlemail.com> wrote:
> > On Tue, Feb 2, 2010 at 4:57 AM, Tom Spear <speeddymon <at> gmail.com> wrote:
> >> As requested: new errors attached.
> >
> > Ah, my half-assed socklen_t fix wasn't good enough -
> > it was sitting *before* system includes and therefore
> > they saw #defined name too. Need to move it.
> >
> > I committed a better fix to git, please clone it:
> >
> > git clone git://busybox.net/busybox.git
> >
> > and try again. In my local testing, it builds even if I force
> > socklen_t hack to be "erroneously" active.
> >
> >
> >> Denys, I have ssh setup with
> >> private keys and a domain name so that I can access the machine from
> >> my office. If you would like, I will be happy to grant you access so
> >> you can login to run tests, if you wish to speed the process up. The
> >> machine has nothing sensitive on it.
> >
> > Yes, this might be a way to do it. You can send me access data
> > via private email.

The summary of what I've seen on Tom's machine.

There is a toolchain for building binaries for Android.
On Tom's machine, it was in

/SOME/PATH/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1

with usual structure inside (e.g. the compiler driver was in bin/arm-eabi-gcc).

Also there was a perl script, agcc, which was trying
to supply this arm-eabi-gcc with needed -I, -L options
and the like.

"agcc" understandably was failing to do it properly.
sure, "agcc hello.c" works. If one tries something more complex -
-W options, ld -r, etc, agcc mishandles it.

I ran "arm-eabi-gcc -v" and from its output it's obvious that
it was built configure --prefix=/android/mathias/armdev/toolchain-eabi-4.2.1
and it looks the result is _not_ relocatable.

IOW: this toolchain is not really meant to be moved,
it has to be exactly in directory named
/android/mathias/armdev/toolchain-eabi-4.2.1
to work without "agcc" script.

Whoever was preparing this toolchain wasn't trying
(or failed) to make it easily usable.

If I would be trying to nevertheless make do with it,
I'd move it to that directory, and examined "agcc" script
trying to figure out where Android header files are now,
and where arm-eabi-gcc expected them to be.
Then I'd try to move them so that bare arm-eabi-gcc call
is able to find them. Same for libraries and object files
(.a and .o files).

The goal is to make bare "arm-eabi-gcc -c t.c" work
then make bare "arm-eabi-gcc t.c" work.
Or at least make them work with minimum amount of -options like
-Wl,-dynamic-linker,/system/bin/linker
(we can always stuff them in EXTRA_CFLAGS) -
as opposed to massive, and variable, number of options
like agcc attemps to do.

If this is possible, then resulting arm-eabi-gcc would work
like proper toolchain should, and it should be possible
to build busybox using it.
--

-- 
vda