This may be necessary for some work I want to do.

You might be interested in glandium's patches in Bug 584474.

Seems to work. A little messy because android needs to be detected by OS_TARGET.

Comment on attachment 489985 [details] [diff] [review] Turn on fakelibs on android Assuming this actually works, r=me. ;-)

what is the testing situation for fakelibs? how can we be sure this doesn't regress anything?

(In reply to comment #4) > what is the testing situation for fakelibs? how can we be sure this doesn't > regress anything? I've been using it for the last few days and it seems to work fine. Requesting approval now so we can get additional testing in the nightlies. I'm not sure what sort of regressions fakelibs could introduce.

If it builds you should be fine. We didn't have any fallout on Windows on m-c other than build/linkage errors.

Yeah, I'd expect the problems to all show up at build time. There could be problems with symbol collisions or something but those directories shouldn't have fakelibs turned on.

Comment on attachment 489985 [details] [diff] [review] Turn on fakelibs on android a=blassey

backed out per mwu's request http://hg.mozilla.org/mozilla-central/rev/829307640234

http://tinderbox.mozilla.org/showlog.cgi?log=Mobile/1289946979.1289951119.31415.gz&fulltext=1 make[5]: execvp: /tools/android-ndk/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/arm-eabi-ar: Argument list too long make[5]: *** [libgklayout.a] Error 127 make[5]: Leaving directory `/builds/slave/mozilla-central-mobile-browser-android-r7-build/build/mozilla-central/objdir/layout/build' Apparently the systems we're building on are ancient and probably don't have support for unlimited length arg lists. Not sure why this would trigger with fakelibs on.. didn't we have pretty long lists of objects to link before?

For some reason you're getting absolute paths passed to ar. That's almost certainly what's killing you.

Not actively working on this.

Did bug 584474 fix this?

Subsumed, perhaps.