Can not load shared libraries because major number is given as a part of the library dependency

I have been creating a set of shared libraries to run on an android phone. When I try to load them in they are failing and it looks to me as if the libraries that my shared library depends on have been named with their major number.

I should explain that I am not using the ndk-* commands, only the ndk toolchain with the usual configure scripts.

As a simple example, though the rest of my libs are doing the same. I have build libtiff with a dependency on libjpeg. If I do a readelf on libtiff I get this.

$ /c/android/android-ndk-r5b/toolchains/arm-eabi-4.4.0/prebuilt/windows/bin/arm-eabi-readelf.exe -d libs/armeabi/libtiff.so

Dynamic section at offset 0x79988 contains 25 entries:
  Tag        Type                         Name/Value
0x00000001 (NEEDED)                     Shared library: [libjpeg.so.8]
0x00000001 (NEEDED)                     Shared library: [libz.so]
0x00000001 (NEEDED)                     Shared library: [libm.so]
0x00000001 (NEEDED)                     Shared library: [libc.so]
0x00000001 (NEEDED)                     Shared library: [libdl.so]
0x0000000e (SONAME)                     Library soname: [libtiff.so.3]
0x00000010 (SYMBOLIC)                   0x0
0x0000000f (RPATH)                      Library rpath: [c:/Users/whadden/workspace/jni_debug/jpeg-8c/.libs:C:/MinGW/ms
s/1.0/local/lib]
0x00000004 (HASH)                       0xb4
0x00000005 (STRTAB)                     0x1f54
0x00000006 (SYMTAB)                     0xa24
0x0000000a (STRSZ)                      5195 (bytes)
0x0000000b (SYMENT)                     16 (bytes)
0x00000003 (PLTGOT)                     0x7aa70
0x00000002 (PLTRELSZ)                   768 (bytes)
0x00000014 (PLTREL)                     REL
0x00000017 (JMPREL)                     0x4110
0x00000011 (REL)                        0x3668
0x00000012 (RELSZ)                      2728 (bytes)
0x00000013 (RELENT)                     8 (bytes)
0x6ffffffe (VERNEED)                    0x3648
0x6fffffff (VERNEEDNUM)                 1
0x6ffffff0 (VERSYM)                     0x33a0
0x6ffffffa (RELCOUNT)                   339
0x00000000 (NULL)                       0x0

As you can see I would have expected to see libjpeg named as libjpeg.so not libjpeg.so.8. As this is being deployed to an android phone I do not think I can create symbolic links to resolve this issue, and I don't think I should be anyway.

When I try to root cause the issue by doing a test link with the phone's system libs I get

$ /cygdrive/c/android/android-ndk-r5b/toolchains/arm-eabi-4.4.0/prebuilt/window
s/bin/arm-eabi-ld libtiff.so -rpath=.
C:\android\android-ndk-r5b\toolchains\arm-eabi-4.4.0\prebuilt\windows\bin\arm-eabi-ld.exe: warning: libjpeg.so.8, needed
by libtiff.so, not found (try using -rpath or -rpath-link)
C:\android\android-ndk-r5b\toolchains\arm-eabi-4.4.0\prebuilt\windows\bin\arm-eabi-ld.exe: warning: cannot find entry sy
mbol _start; defaulting to 00008260
libtiff.so: undefined reference to `__aeabi_ui2f@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_CreateCompress@LIBJPEG_8.0'
libtiff.so: undefined reference to `__aeabi_i2f@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_std_error@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_write_raw_data@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_set_defaults@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_finish_decompress@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_set_colorspace@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_suppress_tables@LIBJPEG_8.0'
libtiff.so: undefined reference to `__aeabi_fdiv@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_read_header@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_write_tables@LIBJPEG_8.0'
libtiff.so: undefined reference to `__aeabi_fsub@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_abort@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_set_quality@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_read_scanlines@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_resync_to_restart@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_destroy@LIBJPEG_8.0'
libtiff.so: undefined reference to `__aeabi_f2iz@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_start_decompress@LIBJPEG_8.0'
libtiff.so: undefined reference to `__aeabi_fadd@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_start_compress@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_write_scanlines@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_read_raw_data@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_CreateDecompress@LIBJPEG_8.0'
libtiff.so: undefined reference to `__aeabi_fmul@LIBJPEG_8.0'
libtiff.so: undefined reference to `jpeg_finish_compress@LIBJPEG_8.0'

Which indicates that libjpeg has not been found, yet if I rename libjpeg to libjpeg.so.8 then I get none of these errors.

So should I a) fix the build so that there are no major number referenced in the shared libs, and more importantly how do I do that? b) named the build libraries with their major numbers on the file system? ( I presume this is wrong )

/edit

An example of the command line being used for a .o is

libtool: compile: arm-linux-androideabi-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I/c/Users/whadden/workspace/jni/jpeg-8c -I/c/Users/whadden/workspace/jni/tiff-3.9.5/libtiff -O3 -mandroid -nostdlib -I/c/Users/whadden/workspace/jni/jpeg-8c -I/c/Users/whadden/workspace/jni/tiff-3.9.5/libtiff -Wall -W -MT tif_getimage.lo -MD -MP -MF .deps/tif_getimage.Tpo -c tif_getimage.c -fPIC -DPIC -o .libs/tif_getimage.o

As an aside I have just moved to the new NDK R6

Thanks Wil

I should explain that I am not using the ndk-* commands, only the ndk toolchain with the usual configure scripts.

It's possible that although your configuration script is generating something that uses the ndk compiler, it's actually building for some properties auto-detected from the environment of your development machine, where for example libjpeg.so.8 might be correct.

You will likely need to either fix the configure script or manually edit the makefiles, you might even be able to do so with sed.