Símbolo indefinido al cargar una biblioteca compartida

En mi programa, necesito cargar una biblioteca compartida dinámicamente condlopen(). Tanto el programa como la biblioteca compartida se compilan con éxito para unARM arquitectura con el compilador cruzado instalado en mix86. Sin embargo, cada vez que el programa intenta cargar la biblioteca en tiempo de ejecución enARM, falla al dar este error:

símbolo indefinido: _dl_hwcap

No puedo encontrar al culpable de este error.

Permítanme dar detalles sobre cómo la biblioteca compartida (libmyplugin.so) se basa enx86 primero. Yo uso elg++ compilador cruzado de la siguiente manera:

/home/me/arm/gcc-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ -march=armv7-a -mfloat-abi=hard -c -s -fPIC -o build/module1.o module1.cpp
/home/me/arm/gcc-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ -march=armv7-a -mfloat-abi=hard -c -s -fPIC -o build/module2.o module2.cpp
/home/me/arm/gcc-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ -o dist/libmyplugin.so build/module1.o build/module2.o --sysroot /home/me/arm/sysroot/ -Wl,--no-as-needed -ldl -lX11 -lXext /home/me/arm/libstatic.a -shared -s -fPIC

Por favor, preste atención a las siguientes notas:

module1.cpp ymodule2.cpp son mis archivos de código fuente.libstatic.a es un gran archivo de objetos.o archivos que implementan las cosas directamente invocadas / referenciadas pormodule1.cpp ymodule2.cpp. Estos archivos de objetos han sido compilados por otros para la misma arquitectura ARM que la mía, con los mismos indicadores del compilador, pero utilizando un poco más actualizadog++ compiladorv4.9 en lugar de miv4.8.3) Desafortunadamente, no tengo control sobre la construcción de estos objetos.--sysroot /home/me/arm/sysroot/ representa el sistema de archivos remoto de miARM OS de donde el localg++ El compilador cruzado puede tomar las bibliotecas nativas mientras se vincula.-Wl,--no-as-needed -ldl -lX11 -lXext: estos indicadores son necesarios para forzar al cargador dinámico a cargar elX11 bibliotecas presentes en el sistema cuando el programa carga mi biblioteca compartida. En particular,--no-as-needed se requiere porque elX11 Las bibliotecas NO son directamente referenciadas pormodule1.o ymodule2.o; por el contrario elX11 Las bibliotecas están referenciadas únicamente por la biblioteca estática.

Tenga en cuenta que toda la configuración anterior funciona enx86. Es solo que no entiendo cuál es la razón de la_dl_hwcap símbolo no resuelto cuando el programa intentó cargar la biblioteca enARM.

¿Tienes alguna idea de cómo investigar este problema?

Respuestas a la pregunta(2)

Su respuesta a la pregunta