Comments 13
UFO just landed and posted this here
Android очень далек от того, чтоб называться unix-like системой. По крайней мере, в привычном смысле этих слов. Да, ядро там линуксовое, но все остальное — жуткий зоопарк. И да, libc там есть — просто она а) неполная, б) нестандартная и в) очень забагованная. Грустно, но факт.
Срываете покровы просто. Спасибо!
А может найдется под рукой несколько ссылок на пруфы про забагованность стандартной си-бибилиотеки под андроид?
А может найдется под рукой несколько ссылок на пруфы про забагованность стандартной си-бибилиотеки под андроид?
Ссылок — не найдется, т.к. не веду учет, но вот простейший пример:
/* test.c */
#include <stdio.h>
#include <stdlib.h>
int main()
{
double d;
d = strtod("0x1234", NULL);
printf("d=%f\n", d);
return 0;
}
$ uname -s
Darwin
$ cc -x c -Wall -Wextra -Werror -c -o test.o test.c
$ cc -o test test.o
$ ./test
d=4660.000000
$ uname -s
Linux
$ cc -x c -Wall -Wextra -Werror -c -o test.o test.c
$ cc -o test test.o
$ ./test
d=4660.000000
$ adb shell getprop ro.build.version.release
4.4.4
$ /opt/android/android-ndk-r10d/ndk-build
[armeabi-v7a] Compile thumb : test-strtod <= test.c
/opt/android/android-ndk-r10d/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc -MMD -MP -MF ./obj/local/armeabi-v7a/objs/test-strtod/test.o.d -fpic -ffunction-sections -funwind-tables -fstack-protector -no-canonical-prefixes -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -mthumb -Os -g -DNDEBUG -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -Ijni -DANDROID -Wall -Wextra -Werror -Wa,--noexecstack -Wformat -Werror=format-security -I/opt/android/android-ndk-r10d/platforms/android-9/arch-arm/usr/include -c jni/test.c -o ./obj/local/armeabi-v7a/objs/test-strtod/test.o
[armeabi-v7a] Executable : test-strtod
/opt/android/android-ndk-r10d/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-g++ -Wl,--gc-sections -Wl,-z,nocopyreloc --sysroot=/opt/android/android-ndk-r10d/platforms/android-9/arch-arm -Wl,-rpath-link=/opt/android/android-ndk-r10d/platforms/android-9/arch-arm/usr/lib -Wl,-rpath-link=./obj/local/armeabi-v7a ./obj/local/armeabi-v7a/objs/test-strtod/test.o -lgcc -no-canonical-prefixes -march=armv7-a -Wl,--fix-cortex-a8 -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -mthumb -lc -lm -o ./obj/local/armeabi-v7a/test-strtod
[armeabi-v7a] Install : test-strtod => libs/armeabi-v7a/test-strtod
install -p ./obj/local/armeabi-v7a/test-strtod ./libs/armeabi-v7a/test-strtod
/opt/android/android-ndk-r10d/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-strip --strip-unneeded ./libs/armeabi-v7a/test-strtod
$ adb push libs/armeabi-v7a/test-strtod /data/local/tmp/test-strtod
366 KB/s (9492 bytes in 0.025s)
$ adb shell chmod 0755 /data/local/tmp/test-strtod
$ adb shell "cd /data/local/tmp && ./test-strtod"
d=0.000000
Вы будете смеяться, но Visual C++ Compiler Version 18.00.21005.1 выдаёт тот же результат. Воу
Андроид — это не линукс, а клоунада.
Юзеры там используются не для юзеров, а набор библиотек — не соответствует никакому стандарту.
Юзеры там используются не для юзеров, а набор библиотек — не соответствует никакому стандарту.
Поясните, пожалуйста, какой сейчас смысл в Crystax NDK? Помню, когда-то давно у меня были проблемы с родным NDK, но где-то с версии 6 всё отлично. Сейчас в родном NDK есть GCC 4.9 — соотвественно, полная поддержка С++ 11, есть какие-то фичи из С++ 14. У меня кросс-платформенный проект среднего размера с довольно приличным количеством 3rd-party библиотек (в основном, обработка изображений — exiv2, libraw, freetype, lcms, libjpeg), всё работает.
Разве только если непонятные крэши в С++-ядре вызваны NDK, а не моим / 3rdpraty кодом… но это маловероятно, мне кажется.
Разве только если непонятные крэши в С++-ядре вызваны NDK, а не моим / 3rdpraty кодом… но это маловероятно, мне кажется.
Если у вас все отлично с использованием Google NDK — что ж, рад за вас, вам CrystaX NDK не нужен. Однако многим нужен, т.к. проблем хватает, а Google не торопится их чинить. Тот же Boost — многие библиотеки из его состава просто не будут работать, будучи собранными с помощью Google NDK (разумеется, те, которым нужна какая-то поддержка со стороны libc; чисто языковые вещи типа shared_ptr зависят только от компилятора и работать будут нормально). Ну и веселые баги в libc и прочих библиотеках, которые опять-таки не чинятся годами — посмотрите на пример со strtod в коментариях выше. Поэтому падения, вызванные плохой реализацией C++ или иной библиотеки — вовсе не так маловероятны, как вы считаете.
Проблем в Андроиде много, и неполная поддержка C++ — это только малая часть. Главная проблема — это то, что Android абсолютно полностью нестандартен на нативном уровне. Иными словами, удобно под него разрабатывать только на Java. Нативная разработка — в разы сложнее, а многие вещи — вплоть до того, что «проще забить», чем пытаться что-то с этим сделать. Вот это мы и пытаемся изменить. Мы хотим сделать так, чтоб все текущее разнообразие языков/фреймворков/библиотек, доступных на других POSIX платформах, стало доступно и для разработки под Android.
Я описал все это здесь — почитайте, там довольно подробно описано что это и зачем. Дублировать в комментарии мало смысла.
Проблем в Андроиде много, и неполная поддержка C++ — это только малая часть. Главная проблема — это то, что Android абсолютно полностью нестандартен на нативном уровне. Иными словами, удобно под него разрабатывать только на Java. Нативная разработка — в разы сложнее, а многие вещи — вплоть до того, что «проще забить», чем пытаться что-то с этим сделать. Вот это мы и пытаемся изменить. Мы хотим сделать так, чтоб все текущее разнообразие языков/фреймворков/библиотек, доступных на других POSIX платформах, стало доступно и для разработки под Android.
Я описал все это здесь — почитайте, там довольно подробно описано что это и зачем. Дублировать в комментарии мало смысла.
Спасибо за ответ (и за проделанную работу, конечно же). Возникло желание попробовать Crystax, посмотреть, не улучшится ли стабильность приложения. Хуже, я так понимаю, точно не станет?
Ну, как говорил Остап Бендер, полную гарантию может дать только страховой полис, но тем не менее, хуже стать не должно — мы специально уделяем внимание тому, чтоб CrystaX NDK был прозрачной заменой для Android NDK от Google. Тем не менее, от багов никто не застрахован, и у вас, конечно, может вылезти что-то неучтенное. В таком случае мы будем признательны, если вы сообщите о проблеме, а мы постараемся ее максимально быстро починить и добавить test case, исключающий ее появление в будущем.
UFO just landed and posted this here
Выбросить можно, и можно сделать много чего другого, но это не поможет. Вы получите свою ОС, которую даже не сможете назвать «Android», и которая, скорее всего, так и заглохнет в безвестности.
Мы же предоставляем возможность для нативной разработки под тот Android, который есть. Не меняя системы, просто делаем поведение нижнеуровневых библиотек более соответствующим стандарту. Это позволяет разрабатывать под Android и распространять приложения, которые будут работать на всех устройствах с Android, а не только на несуществующих «идеальных». При этом не добавляются требования типа «телефон должен быть рутованным» — т.е. с точки зрения системы это обычные приложения, такие же как и другие. С точки зрения же разработчика — все сильно более стандартное и, следовательно, проще в разработке.
Мы же предоставляем возможность для нативной разработки под тот Android, который есть. Не меняя системы, просто делаем поведение нижнеуровневых библиотек более соответствующим стандарту. Это позволяет разрабатывать под Android и распространять приложения, которые будут работать на всех устройствах с Android, а не только на несуществующих «идеальных». При этом не добавляются требования типа «телефон должен быть рутованным» — т.е. с точки зрения системы это обычные приложения, такие же как и другие. С точки зрения же разработчика — все сильно более стандартное и, следовательно, проще в разработке.
Sign up to leave a comment.
Boost C++ libraries на Android