c++ - Undefined symbol when loading a shared library -

in program need load shared library dynamically dlopen(). both program , shared library cross-compiled arm architecture cross-compiler installed on x86. however, whenever program tries load library @ run time on arm, fails giving error:

undefined symbol: _dl_hwcap

i cannot find culprit of error.

let me give details on how shared library (libmyplugin.so) built on x86 first. use g++ cross-compiler below:

/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 

please pay attention following notes:

1. module1.cpp , module2.cpp source code files.
2. libstatic.a big archive of object .o files implementing stuff directly invoked/referenced module1.cpp , module2.cpp. these object files have been compiled others same arm architecture mine, same compiler flags, using more updated g++ compiler (v4.9 instead of v4.8.3). unfortunately, have no control on building of these objects.
3. --sysroot /home/me/arm/sysroot/ represents remote filesystem of arm os local g++ cross-compiler can take native libraries while linking.
4. -wl,--no-as-needed -ldl -lx11 -lxext: these flags required force dynamic loader load x11 libraries present on system when shared library loaded program. in particular, --no-as-needed required because x11 libraries not directly referenced module1.o , module2.o; on contrary x11 libraries referenced static library only.

note above setup works on x86. it's don't understand reason of _dl_hwcap symbol not resolved when program tried load library on arm.

do have idea how investigate issue?

there myriad of things problematic, here 4 avenues of exploration. concentrating on -shared in link line, last item addresses well. (a nice howto on shared libraries here: http://tldp.org/howto/program-library-howto/shared-libraries.html

a) check environment variable ld_library_path. since aren't using rpath linker (rpath embeds full path .so can find @ runtime), way linker can find code search ld_library_path. make sure .so or .0 want in path.

b) use unix utility 'nm' search .so (shared objects) , .a files symbol. example, 'nm -d /usr/lib64/libpython2.6.so' show dynamic symbols in libpython.so, , can symbols of interest: example, 'initgc' defined or used in libpython?

% nm -d /usr/lib64/libpython2.6.so | grep initgc 000003404300cf0 t initgc 

the 't' means text or, yes, defined there. see if can find symbol in module of interest using grep , nm. (a 'u' means undefined, means defined in module).

c) useful tool 'ldd'. shows dynamic libraries library looking on depends on. example:

% ldd /usr/lib64/libpython2.6.so linux-vdso.so.1 =>  (0x00007fffa49ff000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00000033f0200000) libdl.so.2 => /lib64/libdl.so.2 (0x00000033f0600000) libutil.so.1 => /lib64/libutil.so.1 (0x00000033fea00000) libm.so.6 => /lib64/libm.so.6 (0x00000033f0a00000) libc.so.6 => /lib64/libc.so.6 (0x00000033efe00000) /lib64/ld-linux-x86-64.so.2 (0x00000033efa00000) 

if can't find library (because it's not on ld_library_path or wasn't specified in rpath), library turn empty.

d) little worried link line of seeing '.a' file -shared option. compilers/linkers cannot use '.a' (archive) file create '.so' file. '.so' files have made other '.so' files or '.o' files have been compiled -fpic.

i recommend (if can), recompile /home/me/arm/libstatic.a it's .so. if can't do, might have make final output '.a' file well. (in other words, rid of -shared command line option).

in summary: check ld_library_path, use nm , ldd around @ .a , .so files, think end result may not able combine .so , .a files.

i hope helps.