Android NDK r3 with enabled C++ exceptions, RTTI and STL
Dmitry Moskalchuk
David Turner
--
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.
Dmitry Moskalchuk
David Turner
David,Thanks for attention. Unfortunately, placing libgcc.a before libc.so cause SIGSEGV on load of shared library from Java. There are duplicates of some functions (such as Unwind_RaiseException) which are both in libc.so and in libgcc.a. Looks like implementation located in libc.so is correct whereas in libgcc.a - no. So currently the only way to use it - place libc.so before libgcc.a.Is this real problem or potential? I mean is this approach will get broken binaries for latest android devices such as Nexus One? I've tested it on emulator 2.1 and it works fine there. Unfortunately, I have no Nexus One so can not test it on device.
If this is just potential problem, don't worry, I'll fix it soon and will replace patch by the newest version. If this is real problem, I'll remove temporarily my prebuilt versions from site until solution will found.
Dmitry Moskalchuk
tdo...@googlemail.com
thanks for you work. You released Android NDK r2, too. The website
doesn't contain a warning for that, but the same restrictions/possible
future problems apply, right?
On 11 Mrz., 01:06, Dmitry Moskalchuk <crys...@gmail.com> wrote:
> Done. Seehttp://www.crystax.net/android/ndk-r3.php
Dmitry Moskalchuk
Yes, I believe that it. But in case of r2 applications built using my
custom version will behave the same as built using official NDK r2 so
therefore I've not placed warning there.
Anyway, right now I'm digging in this problem and seems I'm pretty
close to final solution. As soon as I'll get it done, I'll update my
site with that.
Dmitry Moskalchuk
22.03.2010, в 11:05, tdo...@googlemail.com написал(а):
gamebits
Just wanted to say thanks for providing a version of the Android NDK
with C++ support. While I don't use exceptions and STL in my game
engine, your NDK helps me run my unit tests.
Cheers
On Mar 22, 8:19 pm, Dmitry Moskalchuk <crys...@gmail.com> wrote:
> Hi,
>
> Yes, I believe that it. But in case of r2 applications built using my
> custom version will behave the same as built using official NDK r2 so
> therefore I've not placed warning there.
> Anyway, right now I'm digging in this problem and seems I'm pretty
> close to final solution. As soon as I'll get it done, I'll update my
> site with that.
>
> Dmitry Moskalchuk
>
> 22.03.2010, × 11:05, tdom...@googlemail.com ÎÁÐÉÓÁÌ(Á):
>
> > hi,
> > thanks for you work. You released Android NDK r2, too. The website
> > doesn't contain a warning for that, but the same restrictions/possible
> > future problems apply, right?
>
> > On 11 Mrz., 01:06, Dmitry Moskalchuk <crys...@gmail.com> wrote:
> >> Done. Seehttp://www.crystax.net/android/ndk-r3.php
>
> >> Dmitry Moskalchuk
>
> >> 11.03.2010, × 2:41, David Turner ÎÁÐÉÓÁÌ(Á):
> >>> 11.03.2010, × 2:16, David Turner ÎÁÐÉÓÁÌ(Á):
Dmitry Moskalchuk
Just want to inform I've fixed that problem David mentioned (potential problem with running binaries on future android versions). I've re-uploaded fixed distribution to my site http://www.crystax.net/android/ndk-r3.php. All C++ stuff like runtime support of exceptions, RTTI and standard C++ library links statically into binary so applications built using my NDK distribution will not differ by ABI from that built by official version (and therefore, could be run everywhere where original could be run). The only drawback is bit bigger size of final binary.
Detailed explanation of problem I've bumped with and my fix:
There was changed relative order of libgcc.a and libc.so on link stage in Android NDK r3. This was done to allow application use as much functions from libgcc.a as it can instead of libc.so. This is GNU linker peculiarity - it actually do one-step linking and if library does provide symbol A, but there is no objects need that symbol BEFORE library A in command line - this symbol will be thrown away from final binary.
Well, this is right thing, but, unfortunately, this approach introduced new bug for them who uses C++ exceptions. Placing libgcc.a before libc.so pull weak symbol __gnu_Unwind_Find_exidx into final binary (so or exe - no matter). This symbol used only in stack unwinding procedure so no problems until you'll try to do that (for example, by throwing C++ exception). Well, I've thrown exception and have seen in gdb SIGILL pointing to place where this symbol called. The pointer was not NULL, there was some garbage. Actually this symbol is defined in bionic libc but has not been correctly initialized (bionic linker bug?).
I've patched GCC sources changing type of this symbol from 'weak' to 'undefined' - and that did the trick. In that case bionic linker correctly bind it with one in libc.so.
If anybody has thoughts on that - you are welcome.
Dmitry Moskalchuk
11.03.2010 03:06, Dmitry Moskalchuk О©╫О©╫О©╫О©╫О©╫:
Done. SeeО©╫http://www.crystax.net/android/ndk-r3.php
Dmitry Moskalchuk
11.03.2010, О©╫ 2:41, David Turner О©╫О©╫О©╫О©╫О©╫О©╫О©╫(О©╫):
On Wed, Mar 10, 2010 at 3:33 PM, Dmitry Moskalchuk <cry...@gmail.com> wrote:
David,
Thanks for attention. Unfortunately, placing libgcc.a before libc.so cause SIGSEGV on load of shared library from Java. There are duplicates of some functions (such as Unwind_RaiseException) which are both in libc.so and in libgcc.a. Looks like implementation located in libc.so is correct whereas in libgcc.a - no. So currently the only way to use it - place libc.so before libgcc.a.
Is this real problem or potential? I mean is this approach will get broken binaries for latest android devices such as Nexus One? I've tested it on emulator 2.1 and it works fine there. Unfortunately, I have no Nexus One so can not test it on device.
This will be a problem when we release a version of the platform that is built with a different toolchain because it will generate slightly different code that depends on different libgcc.a functions. This could happen for Gingerbread for example.The symptom will be that NDK apps built with your NDK may fail to load their shared library at startup after an OTA. This kind of thing is why I want to be extremely cautious about officially supporting C++ exceptions / RTTI in the NDK.
О©╫
If this is just potential problem, don't worry, I'll fix it soon and will replace patch by the newest version. If this is real problem, I'll remove temporarily my prebuilt versions from site until solution will found.
I don't know yet :-( At the minimum, please tag your NDK as "experimental" or something and try to make the issue very clear to users.
Sorry about that. Yeah, native ABIs suck !
О©╫
Dmitry Moskalchuk
11.03.2010, О©╫ 2:16, David Turner О©╫О©╫О©╫О©╫О©╫О©╫О©╫(О©╫):
Dmitry,
Your latest patch is not correct, libgcc.a should really be placed before any shared libraries and PRIVATE_LDLIBS flags when generating a binary.If you don't do this, the final binary may have symbol references to libgcc functions that are embedded in libc.so, libm.so and others, which unfortunately may changer in later platform revisions due to toolchain changes(We had this problem when switching from 4.2.1 in Donut to 4.4.0 in Eclair).
Can I ask you to correct your modified NDK to avoid this problem in the future ?
Thanks
On Wed, Mar 10, 2010 at 3:07 PM, Dmitry Moskalchuk <cry...@gmail.com> wrote:
Hi all,
Just want to inform that I've built customized version of recently released Android NDK r3 with enabled full C++ support (exceptions, RTTI, Standard C++ library including STL).
Both arm-eabi-4.2.1 and arm-eabi-4.4.0 toolchains have full C++ support enabled. Changes I've made:О©╫http://www.crystax.net/data/android-ndk-r3-crystax.diff.You can download prebuilt packages from my site or build own versions following instructions I've provided. Try it out:О©╫http://www.crystax.net/android/ndk-r3.php
Dmitry Moskalchuk
--
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.
--
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.
--
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.
Yongki
I really appreciate your patch works. Your works speed up my software
development.
Regards,
Yongki C. AndykaJong
On Mar 28, 7:44 pm, Dmitry Moskalchuk <crys...@gmail.com> wrote:
> Hi all,
>
> Just want to inform I've fixed that problem David mentioned (potential
> problem with running binaries on future android versions). I've
> re-uploaded fixed distribution to my sitehttp://www.crystax.net/android/ndk-r3.php. All C++ stuff like runtime
> > Done. Seehttp://www.crystax.net/android/ndk-r3.php
>
> > Dmitry Moskalchuk
>
> > 11.03.2010, О©╫ 2:41, David Turner О©╫О©╫О©╫О©╫О©╫О©╫О©╫(О©╫):
>
> >> On Wed, Mar 10, 2010 at 3:33 PM, Dmitry Moskalchuk <crys...@gmail.com
> >> <mailto:crys...@gmail.com>> wrote:
>
> >> David,
>
> >> Thanks for attention. Unfortunately, placing libgcc.a before
> >> libc.so cause SIGSEGV on load of shared library from Java. There
> >> are duplicates of some functions (such as Unwind_RaiseException)
> >> which are both in libc.so and in libgcc.a. Looks like
> >> implementation located in libc.so is correct whereas in libgcc.a
> >> - no. So currently the only way to use it - place libc.so before
> >> libgcc.a.
>
> >> Is this real problem or potential? I mean is this approach will
> >> get broken binaries for latest android devices such as Nexus One?
> >> I've tested it on emulator 2.1 and it works fine there.
> >> Unfortunately, I have no Nexus One so can not test it on device.
>
> >> This will be a problem when we release a version of the platform that
> >> is built with a different toolchain because it will generate slightly
> >> different code that depends on different libgcc.a functions. This
> >> could happen for Gingerbread for example.
> >> The symptom will be that NDK apps built with your NDK may fail to
> >> load their shared library at startup after an OTA. This kind of thing
> >> is why I want to be extremely cautious about officially supporting
> >> C++ exceptions / RTTI in the NDK.
>
> >> If this is just potential problem, don't worry, I'll fix it soon
> >> and will replace patch by the newest version. If this is real
> >> problem, I'll remove temporarily my prebuilt versions from site
> >> until solution will found.
>
> >> I don't know yet :-( At the minimum, please tag your NDK as
> >> "experimental" or something and try to make the issue very clear to
> >> users.
>
> >> Sorry about that. Yeah, native ABIs suck !
>
> >> Dmitry Moskalchuk
>
> >> 11.03.2010, О©╫ 2:16, David Turner О©╫О©╫О©╫О©╫О©╫О©╫О©╫(О©╫):
>
> >>> Dmitry,
>
> >>> Your latest patch is not correct, libgcc.a should really be
> >>> placed before any shared libraries and PRIVATE_LDLIBS flags when
> >>> generating a binary.
> >>> If you don't do this, the final binary may have symbol
> >>> references to libgcc functions that are embedded in libc.so,
> >>> libm.so and others, which unfortunately may changer in later
> >>> platform revisions due to toolchain changes
> >>> (We had this problem when switching from 4.2.1 in Donut to 4.4.0
> >>> in Eclair).
>
> >>> Can I ask you to correct your modified NDK to avoid this problem
> >>> in the future ?
>
> >>> Thanks
>
> >>> On Wed, Mar 10, 2010 at 3:07 PM, Dmitry Moskalchuk
> >>> <crys...@gmail.com <mailto:crys...@gmail.com>> wrote:
>
> >>> Hi all,
>
> >>> Just want to inform that I've built customized version of
> >>> recently released Android NDK r3 with enabled full C++
> >>> support (exceptions, RTTI, Standard C++ library including STL).
> >>> Both arm-eabi-4.2.1 and arm-eabi-4.4.0 toolchains have full
> >>> C++ support enabled. Changes I've made:
> >>> http://www.crystax.net/data/android-ndk-r3-crystax.diff.
> >>> You can download prebuilt packages from my site or build own
> >>> versions following instructions I've provided. Try it out:
> >>> http://www.crystax.net/android/ndk-r3.php
>
> >>> Dmitry Moskalchuk
>
> >>> --
> >>> 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
> >>> <mailto:andro...@googlegroups.com>.
> >>> To unsubscribe from this group, send email to
> >>> android-ndk...@googlegroups.com
> >>> <mailto:android-ndk%2Bunsu...@googlegroups.com>.
> >>> For more options, visit this group at
> >>> http://groups.google.com/group/android-ndk?hl=en.
>
> >>> --
> >>> 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 <mailto:andro...@googlegroups.com>.
> >>> To unsubscribe from this group, send email to
> >>> android-ndk...@googlegroups.com
> >>> <mailto:android-ndk...@googlegroups.com>.
> >>> For more options, visit this group at
> >>> http://groups.google.com/group/android-ndk?hl=en.
>
> >> --
> >> 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
> >> <mailto:andro...@googlegroups.com>.
> >> To unsubscribe from this group, send email to
> >> android-ndk...@googlegroups.com
> >> <mailto:android-ndk%2Bunsu...@googlegroups.com>.
> >> For more options, visit this group at
> >> http://groups.google.com/group/android-ndk?hl=en.
>
> >> --
> >> 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
> >> <mailto:andro...@googlegroups.com>.
> >> To unsubscribe from this group, send email to
> >> android-ndk...@googlegroups.com
> >> <mailto:android-ndk...@googlegroups.com>.
Dmitry Moskalchuk
Dmitry Moskalchuk
28.03.2010, в 20:16, Yongki написал(а):
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to android-ndk...@googlegroups.com
alan
I am trying to add thread support to your patch. I have managed to
build the toolchain by adding "--enable-threads=posix" to the gcc
configure command and then removing the references to pthread cancel
from gthr_posix.h.
However when I try to load libraries linked against this build I get a
segmentation fault in get_static mutex.
This is the ddms trace:
03-31 10:55:26.257: INFO/DEBUG(28): pid: 264, tid: 270 >>>
com.test.threadtest <<<
03-31 10:55:26.257: INFO/DEBUG(28): signal 11 (SIGSEGV), fault addr
fffffffe
03-31 10:55:26.257: INFO/DEBUG(28): r0 00000000 r1 80a7cfb4 r2
0000ffff r3 00000001
03-31 10:55:26.257: INFO/DEBUG(28): r4 45098b64 r5 00000000 r6
00000001 r7 00000000
03-31 10:55:26.257: INFO/DEBUG(28): r8 ad00f380 r9 0011f1f0 10
427b1d14 fp 00000000
03-31 10:55:26.257: INFO/DEBUG(28): ip 00000000 sp 45098b50 lr
80a7cff4 pc 80a00024 cpsr 60000010
03-31 10:55:26.752: INFO/DEBUG(28): #00 pc 00000024 /data/
data/com.test.threadtest/lib/libthreadtest.so
03-31 10:55:26.752: INFO/DEBUG(28): #01 pc 0007cff0 /data/
data/com.test.threadtest/lib/libthreadtest.so
03-31 10:55:26.752: INFO/DEBUG(28): #02 pc 0007d074 /data/
data/com.test.threadtest/lib/libthreadtest.so
03-31 10:55:26.783: INFO/DEBUG(28): code around lr:
03-31 10:55:26.783: INFO/DEBUG(28): 80a7cfe4 e92d4010 e59f1010
e59f0010 ebff3b3c
03-31 10:55:26.783: INFO/DEBUG(28): 80a7cff4 e59f300c e5930000
e8bd8010 80a7cfb4
03-31 10:55:26.783: INFO/DEBUG(28): 80a7d004 80ab13ec 80ab13f8
e24dd008 e3a03000
03-31 10:55:26.783: INFO/DEBUG(28): stack:
03-31 10:55:26.783: INFO/DEBUG(28): 45098b10 45098c3e
03-31 10:55:26.783: INFO/DEBUG(28): 45098b14 03b3f175
03-31 10:55:26.783: INFO/DEBUG(28): 45098b18 afe03460 /system/
lib/libc.so
03-31 10:55:26.783: INFO/DEBUG(28): 45098b1c b0000491 /system/
bin/linker
03-31 10:55:26.783: INFO/DEBUG(28): 45098b20 afe065b0 /system/
lib/libc.so
03-31 10:55:26.850: INFO/DEBUG(28): 45098b24 afe021d0 /system/
lib/libc.so
03-31 10:55:26.850: INFO/DEBUG(28): 45098b28 45098c38
03-31 10:55:26.850: INFO/DEBUG(28): 45098b2c b000f448 /system/
bin/linker
03-31 10:55:26.850: INFO/DEBUG(28): 45098b30 b000fd00 /system/
bin/linker
03-31 10:55:26.850: INFO/DEBUG(28): 45098b34 80ab0770 /data/
data/com.test.threadtest/lib/libthreadtest.so
03-31 10:55:26.850: INFO/DEBUG(28): 45098b38 00000000
03-31 10:55:26.850: INFO/DEBUG(28): 45098b3c b00004ef /system/
bin/linker
03-31 10:55:26.850: INFO/DEBUG(28): 45098b40 b00163d0
03-31 10:55:26.850: INFO/DEBUG(28): 45098b44 b000f448 /system/
bin/linker
03-31 10:55:26.850: INFO/DEBUG(28): 45098b48 df002777
03-31 10:55:26.850: INFO/DEBUG(28): 45098b4c e3a070ad
03-31 10:55:26.850: INFO/DEBUG(28): #01 45098b50 45098b64
03-31 10:55:26.850: INFO/DEBUG(28): 45098b54 80a7d078 /data/
data/com.test.threadtest/lib/libthreadtest.so
This is the disassembly of the relevant part of the library:
0007cfe4 <_ZN12_GLOBAL__N_116get_static_mutexEv>:
7cfe4: e92d4010 push {r4, lr}
7cfe8: e59f1010 ldr r1, [pc, #16] ; 7d000
<_ZN12_GLOBAL__N_116get_static_mutexEv+0x1c>
7cfec: e59f0010 ldr r0, [pc, #16] ; 7d004
<_ZN12_GLOBAL__N_116get_static_mutexEv+0x20>
7cff0: ebff3b3c bl 4bce8 <_ZnwjPv-0x330>
7cff4: e59f300c ldr r3, [pc, #12] ; 7d008
<_ZN12_GLOBAL__N_116get_static_mutexEv+0x24>
7cff8: e5930000 ldr r0, [r3]
7cffc: e8bd8010 pop {r4, pc}
7d000: 0007cfb4 .word 0x0007cfb4
7d004: 000b13ec .word 0x000b13ec
7d008: 000b13f8 .word 0x000b13f8
any ideas?
On Mar 29, 9:31 pm, Dmitry Moskalchuk <crys...@gmail.com> wrote:
> Glad to hear that :)
>
> Dmitry Moskalchuk
>
> 28.03.2010, × 20:16, Yongki ÎÁÐÉÓÁÌ(Á):
> >> 11.03.2010 03:06, Dmitry Moskalchuk �����:
>
> >>> Done. Seehttp://www.crystax.net/android/ndk-r3.php
>
> >>> Dmitry Moskalchuk
>
> >>> 11.03.2010, � 2:41, David Turner �������(�):
> >>>> 11.03.2010, � 2:16, David Turner �������(�):
Dmitry Moskalchuk
Sorry, I can not understand - why you are trying to do that? As I know, current android gcc (and gcc from my custom build too) has no problems with threads - I'm using pthreads in my core engine and all works fine there. Can you explain more detailed what you are trying to do?
Dmitry Moskalchuk
31.03.2010, в 14:16, alan написал(а):
Alan Birtles
get boost to compile without using the --enable-threads=posix parameter,
I believe boost is using gthreads and these aren't enabled
jeromiya
official ndk? This is fantastic work.
Kelly
Thanks for enabling all these goodies!
I'm getting a link error with the c++ new and delete functions. Turns
out the default tool being used by your NDK is gcc, not g++ (used by
default NDK). I haven't worked on the NDK before but I'm going to take
a stab at changing that.. Unless someone already has..? (fingers
crossed)
Cheers
alan
is cpp, if you are using something else you need to specify that in
your make files
Kelly
put into my project that is having the link errors. I checked the
difference in the two NDKs and I didn't come across any gcc/g++ swaps,
but when I put the project in crystax NDK it uses gcc instead of the g+
+ when building from stock r3. Curious..
Bryan Ashby
On your website it states that on Windows we should use GCC 3.x if
under Windows. I'm currently using 4.4.0 (from the r3 NDK) but am
attempting to build Boost which will need RTTI and exceptions (http://
groups.google.com/group/android-ndk/t/29217fb1e4642898 for progress)
-- what is the reasoning for this? Is this still the case?
Bryan
Alan Birtles
knight666
toolchain. This is the code I'm testing:
class Base
{
public:
Base() { }
virtual ~Base();
}; // class Base
Base::~Base()
{
}
class Vehicle : public Base
{
public:
Vehicle() : Base() { }
~Vehicle();
}; // class Vehicle
Vehicle::~Vehicle()
{
}
class Car : public Vehicle
{
public:
Car() : Vehicle() { }
~Car();
}; // class Car
Car::~Car()
{
}
int main(int a_Data, char** argv)
{
Car* stupid = new Car();
return 0;
}
Here's how I compile it:
/home/oem/android-ndk-r3-crystax/build/prebuilt/linux-x86/arm-
eabi-4.4.0/bin/arm-eabi-g++ -g -nostdlib -std=c++0x -Wall -Werror -O2 -
w -shared -fshort-enums -fno-builtin -I ../../YoghurtGum/src/GLES -
I ../../YoghurtGum/src -I /home/oem/android-ndk-r3-crystax/build/
platforms/android-5/arch-arm/usr/include -c src/Inheritance.cpp -o
intermediate/Inheritance.o
And here's how I link it:
/home/oem/android-ndk-r3-crystax/build/prebuilt/linux-x86/arm-
eabi-4.4.0/bin/arm-eabi-g++ -Wl,--entry=main -Wl,-rpath-link=/home/oem/
android-ndk-r3-crystax/build/platforms/android-5/arch-arm/usr/lib -Wl,-
rpath-link=/home/oem/android-ndk-r3-crystax/build/prebuilt/linux-x86/
arm-eabi-4.4.0/arm-eabi/lib -Wl,-dynamic-linker=/system/bin/linker -
Wl,-L/home/oem/android-ndk-r3-crystax/build/platforms/android-5/arch-
arm/usr/lib -Wl,-rpath=../../YoghurtGum/lib/GLES -nostdlib -lstdc++ -
lm -lc -lGLESv1_CM /home/oem/android-ndk-r3-crystax/build/platforms/
android-5/arch-arm/usr/lib/crtbegin_dynamic.o /home/oem/android-ndk-r3-
crystax/build/platforms/android-5/arch-arm/usr/lib/crtend_android.o
intermediate/Inheritance.o ../../YoghurtGum/bin/YoghurtGum.a -o bin/
Galaxians.android
I'm doing this test because I can't seem to get inheritance to work in
Android C++. I'm building an engine called YoghurtGum (http://
code.google.com/p/yoghurtgum/) that really, really needs inheritance.
I get the following errors:
intermediate/Inheritance.o:(.rodata+0x38): undefined reference to
`vtable for __cxxabiv1::__si_class_type_info'
intermediate/Inheritance.o:(.rodata+0x50): undefined reference to
`vtable for __cxxabiv1::__si_class_type_info'
intermediate/Inheritance.o:(.rodata+0x64): undefined reference to
`vtable for __cxxabiv1::__class_type_info'
collect2: ld returned 1 exit status
make: *** [bin/Galaxians.android] Fout 1
Can you help me with this, wise Android C++ guru?
Thanks in advance.
Dmitry Moskalchuk
actual problems but if using other than .cpp extension for C++ files,
you need explicitly specify it in your Android.mk:
LOCAL_CPP_EXTENSION := cc
Dmitry Moskalchuk
01.05.2010 01:11, Kelly пишет:
David Turner
Dmitry Moskalchuk
Dmitry Moskalchuk
EnricoC
Thanks to your work I'm now able to compile a research project in
which I'm involved! So, thank you for the great work!
Do you think that there are possibilities to include your patches in
the official Android NDK?
Best regards
Enrico Casini
Dmitry Moskalchuk
Dmitry Moskalchuk
12.05.2010, в 21:03, EnricoC написал(а):
> Hi Dmitry,
> Thanks to your work I'm now able to compile a research project in
>
> Do you think that there are any possibilities to include your patches
> in the original Android NDK?
>
> Best regards,
> Enrico Casini
> On May 5, 3:12 am, Dmitry Moskalchuk <crys...@gmail.com> wrote:
>> Of course, you are right. Thanks, David.
>>
>> Dmitry Moskalchuk
>>
>> On 05.05.2010 1:38, David Turner wrote:
>>
>>
>>
>>
>>
>>> Slight correction, there should be a dot at the start of the extension
>>> (as documented in docs/ANDROID-MK.TXT):
>>
>>> LOCAL_CPP_EXTENSION := .cc
>>
>>> :-)
>>
>>> <mailto:crys...@gmail.com>> wrote:
>>
>>> How you build your app? Using android build system or own one? I
>>> have no actual problems but if using other than .cpp extension for
>>> C++ files, you need explicitly specify it in your Android.mk:
>>
>>> LOCAL_CPP_EXTENSION := cc
>>
>>> Dmitry Moskalchuk
>>
>>> 01.05.2010 01:11, Kelly пишет:
>>
>>> It's actually a static library I pulled out of the android
>>> build to
>>> put into my project that is having the link errors. I checked the
>>> difference in the two NDKs and I didn't come across any
>>> gcc/g++ swaps,
>>> but when I put the project in crystax NDK it uses gcc instead
>>> of the g+
>>> + when building from stock r3. Curious..
>>
>>> On Apr 30, 1:38 pm, alan<a...@birtles.org.uk
>>
>>> It should use g++ for c++ files. The default extension for
>>> c++ files
>>> is cpp, if you are using something else you need to
>>> specify that in
>>> your make files
>>
>>> On Apr 30, 9:35 pm, Kelly<senor...@gmail.com
>>
>>> Hey Dmitry,
>>
>>> Thanks for enabling all these goodies!
>>
>>> I'm getting a link error with the c++ new and delete
>>> functions. Turns
>>> out the default tool being used by your NDK is gcc,
>>> not g++ (used by
>>> default NDK). I haven't worked on the NDK before but
>>> I'm going to take
>>> a stab at changing that.. Unless someone already
>>> has..? (fingers
>>> crossed)
>>
>>> Cheers
>>
>>> --
>>> 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
>>> <mailto:android-ndk%2Bunsu...@googlegroups.com>.
>>> <http://groups.google.com/group/android-ndk?hl=en>.
>>> --
>>> 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
>>> <mailto:android-ndk%2Bunsu...@googlegroups.com>.
>>> <http://groups.google.com/group/android-ndk?hl=en>.
>>> --
>>> 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
>>> <mailto:android-ndk%2Bunsu...@googlegroups.com>.
zhihao
I try to use android-ndk-r3-windows-crystax-2, but i can't compile
anything, even the example.
it always return make Error 57，do you know why?
hao@HAO-PC /cygdrive/e/devel/android-ndk-r3-crystax
$ make APP=hello-jni
Android NDK: Building for application 'hello-jni'
Compile++ thumb: hello-jni <= apps/hello-jni/project/jni/hello-jni.cc
make: *** [out/apps/hello-jni/armeabi/objs/hello-jni/hello-jni..o]
Error 57