Наш продукт содержит несколько исходных пакетов. Некоторые исходные пакеты создаются с помощью autotool/conf.NDK12b: Различные ELF, созданные clang vs gcc, используя автономную инструментальную цепочку и те же скрипты сборки
Основываясь на том, что Google сказал о переключении на clang в качестве компилятора по умолчанию для NDK, начиная с NDK-13, мы пошли вперед с помощью переключателя в файлах * .mk, а также в наших скриптах настройки и сборки env. Нет изменений в файлах.
Мы использовали NDK-10d, который является старым, поэтому мы перешли на NDK-12b. Мы также создали автономную инструментальную цепочку из нее, как рекомендовано в документации Android, для упрощения наших скриптов сборки и стандартизации для всех.
Проблема, с которой я столкнулась, - это сбой при запуске, как только загрузится собственный код. То, что я заметил, является предупреждением в logcat относительно: unused DT entry: type 0x6ffffffe (VERNEED) и 0x6fffffff (VERNEEDNUM).
Тогда, в ужасе: A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x30 in tid 22246.
Трассировка стека говорит мне очень, очень мало:
08-11 15:31:02.421 128-128/? I/DEBUG: #00 pc 00036b8c /system/lib/libc.so
08-11 15:31:02.421 128-128/? I/DEBUG: #01 pc 0003817b /system/lib/libc.so (vfprintf+18)
08-11 15:31:02.421 128-128/? I/DEBUG: #02 pc 00035251 /system/lib/libc.so (fprintf+12)
08-11 15:31:02.421 128-128/? I/DEBUG: #03 pc 000015fd /data/app/com.myapp.demo-1/lib/arm/libappdebug.so (pipe_listen+328)
08-11 15:31:02.421 128-128/? I/DEBUG: #04 pc 0001659b /system/lib/libc.so
08-11 15:31:02.421 128-128/? I/DEBUG: #05 pc 000144c3 /system/lib/libc.so
Обратите внимание, что сравнение данных в пределах Эльфы, как сбрасывали на readelf -d показывает отсутствие этих 2 DT записи в двоичные файлы, порожденную руки-Linux -androideabi-gcc-4.9 строит.
Любые идеи, указатели, ... все, что угодно ..., было бы очень признательно, потому что я застрял за (краснеть) 3 дня.
Спасибо.
Это помогло бы, если бы вы показали разницу в выходе из 'readelf -d' для двух версий ... – not2qubit