NDK r6 and APP_ABI := x86 issue

[Derek]

Hi,

I've installed NDK r6 to have x86 support. I've updated my
Application.mk from:
APP_ABI := armeabi armeabi-v7a
to:
APP_ABI := armeabi armeabi-v7a x86

Build fails when running ndk-build under Cygwin. It reports the
following errors:
C:/java/android-ndk-r6/toolchains/x86-4.4.3/prebuilt/windows/bin/../
lib/gcc/i686
-android-linux/4.4.3/../../../../i686-android-linux/bin/ld.exe: C:/ide/
eclipse3.
6.2/workspace/MYPROJECT/obj/local/armeabi/objs/ext/custom.o:
Relocations in generic
ELF (EM: 40)
C:/ide/eclipse3.6.2/workspace/MYPROJECT/obj/local/armeabi/objs/ext/
custom.o: could
not read symbols: File in wrong format
collect2: ld returned 1 exit status
make: *** [/cygdrive/c/ide/eclipse3.6.2/workspace/MYPROJECT/obj/local/
armeabi/libex
t.so] Error 1

Everything works fine without x86. What could be the problem?

Thanks.

[Derek]

Hi again,

Additional note: Using APP_ABI := x86 works, Using APP_ABI := armeabi
works but using both such as APP_ABI := armeabi x86 fails.

Thanks.

[Christopher Van Kirk]

Are there any actual x86 Android devices shipping right now?

Hi again,

Thanks.

--
You received this message because you are subscribed to the Google Groups
"android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to
android-ndk...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/android-ndk?hl=en.

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1390 / Virus Database: 1516/3759 - Release Date: 07/11/11

[David Turner]

Damn, this is a serious bug. Can you file something at b.android.com for it. I can reproduce that under Linux.

In a nutshell, the build system tries to link the armeabi objects with the x86 toolchain.

Sorry about that.

Thanks in advance.

[Derek]

Just submit a bug in b.android.com #18436

Is it safe you run ndk-build with APP_ABI := x86 (and keep lib x86
generated) followed by a ndk-build with APP_ABI := armeabi? So
both .so are generated even if it required two ndk-build?

Thanks.

On Jul 12, 3:23 am, David Turner <di...@android.com> wrote:
> Damn, this is a serious bug. Can you file something at b.android.com for it.
> I can reproduce that under Linux.
> In a nutshell, the build system tries to link the armeabi objects with the
> x86 toolchain.
>
> Sorry about that.
>
> Thanks in advance.
>

[blindfold]

I'm having exactly the same problem with NDK r6: "APP_ABI := armeabi
x86" gives me a bunch of "Relocations in generic ELF (EM: 40)"
messages, leading to an ld fail, while using either "APP_ABI :=
armeabi" or "APP_ABI := x86" compiles just fine. I'm on Windows 7 64-
bit. Like Derek I am wondering if doing two separate compilations for
armeabi and x86, as a temporary workaround, is safe?

Thanks

[blindfold]

I tried that, but the resulting APK gives me a "Installation failed
due to invalid APK file" (HTC Desire, Android 2.2), while I had
assumed that it ought to work for existing devices? After deleting the
libs/x86 folder the resulting APK installs fine again.

[blindfold]

When I tried another time, it gave an Eclipse error message "Failed to
install myapp.apk on device 'mydevice!" *and* readily crashed my phone
(HTC Desire, Android 2.2), restarting the phone. This happened four
times now. It only occurs when I have compiled for both armeabi and
x86 (in succession), such that I have a libs/armeabi and a libs/x86
folder with corresponding .so files. Regenerating the APK after
deleting the libs/x86 folder gives an APK that installs and runs fine
again.

[blindfold]

My mistake: I had missed that running ndk-build for only one ABI at a
time automatically deletes the .so for the ABI that is not in use.
When temporarily putting the successively generated libs/armeabi/
myapp.so and libs/x86/myapp.so in a safe place, and then putting them
both back in libs/armeabi/ and libs/x86/ before generating the APK, an
APK resulted that contained (verified by unzipping) both lib/armeabi/
myapp.so and lib/x86/myapp.so, and that APK installed and ran just
fine on my HTC Desire with Android 2.2. So it looks like one can use
successive compilation as a workaround, if taking care that the .so
that was automatically deleted in the last compile step is put back in
its folder.

[Derek]

Thanks, separate build seems to work fine here too.

[Jun Tian]

Otherwise, when putting x86 target before armeabi-v7a like
"NDK_APP_ABI=x86 armeabi-v7a", the build system will try to link x86
objs when building arm target. Nobody test these target together
before?

[David Turner]

On Wed, Jul 13, 2011 at 4:32 AM, Jun Tian <nuj...@gmail.com> wrote:

Otherwise, when putting x86 target before armeabi-v7a like
"NDK_APP_ABI=x86 armeabi-v7a", the build system will try to link x86
objs when building arm target. Nobody test these target together
before?

For the record, I'm working on fix for this. Will let you know when it's available.

[David Turner]

The fix is already in the AOSP tree: https://review.source.android.com/24575

I'm trying to make a bug-fix release  (r6b), but I don't have any ETA, so please apply the patch to your tree in the meantime.

Regards

[blindfold]

Thanks David, your patch seems to work fine! I had no problems anymore
using "APP_ABI := armeabi x86" after replacing build/core/build-
binary.mk, build/core/default-build-commands.mk, toolchains/arm-linux-
androideabi-4.4.3/setup.mk and toolchains/x86-4.4.3/setup.mk with the
ones in your patch.

Regards

On Jul 15, 1:31 pm, David Turner <di...@android.com> wrote:
> The fix is already in the AOSP tree:https://review.source.android.com/24575
> I'm trying to make a bug-fix release  (r6b), but I don't have any ETA, so
> please apply the patch to your tree in the meantime.
>
> Regards
>
>
>
>
>
>
>
> On Thu, Jul 14, 2011 at 1:52 AM, David Turner <di...@android.com> wrote:
>

> > On Wed, Jul 13, 2011 at 4:32 AM, Jun Tian <nujn...@gmail.com> wrote:
>
> >> Otherwise, when putting x86 target before armeabi-v7a like
> >> "NDK_APP_ABI=x86 armeabi-v7a", the build system will try to link x86
> >> objs when building arm target. Nobody test these target together
> >> before?
>
> >> For the record, I'm working on fix for this. Will let you know when it's
> > available.
>
> >>  On Jul 12, 9:23 am, David Turner <di...@android.com> wrote:

> >> > Damn, this is a serious bug. Can you file something at b.android.comfor it.

[Halsafar]

http://code.google.com/p/android/issues/detail?id=18436 bump this