reubicaciones de texto a pesar de -fPIC?

Estoy tratando de recompilar una pila de software de buen tamaño (doubango) para ARM. Después de dos semanas, pensé que finalmente lo había hecho porque las bibliotecas que tenían reubicaciones de texto ya no las tenían paraarmeabi, armv5te, armv7-a. Sin embargo,armv7-a-neon todavía los tengo ...

Sé que vincular contra bibliotecas estáticas o bibliotecas compartidas que contienen reubicaciones de texto también las introducirá en mi biblioteca, y para luchar contra eso debería usar-fPIC en sus CFLAGS mientras recompila todo para construir código independiente de posición. Todo lo que hice, construí FFMPEG sin reubicaciones de texto también ...

Lo que no entiendo es esto:Si estoy usando el mismo conjunto de archivos de origen para todos los arcos, y comprobando manualmente a mano si los archivos .a tienen reubicaciones de texto, ¿por qué solo aparece una reubicación de texto para ARMv7 NEON?

Estoy comprobando usandoreadelf&nbsp;al igual quereadelf -a <libame.a> | grep TEXTREL&nbsp;para ambos.a&nbsp;y.so&nbsp;libs.

devshark@ubuntu:~/SCRATCH/doubango_env/doubango/android-projects/output/gpl/armv7-a-neon/lib$ readelf -a libtinyWRAP.so | grep TEXTREL 
   0x00000016 (TEXTREL)                    0x0
   0x0000001e (FLAGS)                      SYMBOLIC TEXTREL BIND_NOW

¿Cómo encuentro al culpable que está introduciendo las reubicaciones de texto en mi armv7neon?.so&nbsp;¿biblioteca?

Estoy usando NDK r12b. Aquí hay un pastebin de todo el resultado de la compilación: OK, no pastie o pastebin ya que no permitirán 2.1mb de texto.

Excelente. Entonces, ¿alguna idea de por qué las reubicaciones de texto aparecen solo para NEON?

La pregunta podría ser similar a esta, excepto que tampoco tengo reubicaciones para x86.¿Por qué NDK genera una biblioteca compartida para x86 con reubicación de texto incluso después de configurar el indicador -fPIC?