ls -l on Android device

headers Rob Landley | 8 Feb 2010 21:12

On Saturday 06 February 2010 13:22:18 Denys Vlasenko wrote:
> 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've been maintaining an updated version of the old uClibc wrapper for years 
now as part of my FWL project.  (See attached, more complete revision history 
is at http://impactlinux.com/hg/firmware under "sources/toys".)

It fairly extensively parses gcc command lines and rewrites them from the 
ground up to allow the compiler to be moved around after it's built, link 
against a C library that didn't exist when it was built, and so on.  
(Basically all the things gcc _should_ be able to do, but can't due to its 
"special" FSF heritage.)

I haven't tested it with ay of the android stuff (probably a few lurking 
uClibc-isms in there, and I _know_ it has hardwired assumptions that the 
compiler's libraries and headers live in ../cc/lib and ../cc/include, and the 
system headers and libraries live in ../include and ../lib, and the other 
compiler binaries live in ../tools, all relative to wherever the wrapper 
binary currently lives.)

But it might be an easier starting point than trying to deal with perl.  And 
it does have a fairly deep understanding of the gcc command line as used by a 
largeish number of Linux package builds...

Rob
--

-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds

Re: ls -l on Android device