Falta la biblioteca del vinculador de C ++ cuando se ejecuta (comportamiento de SONAME)

He creado un programa que utiliza dos bibliotecas compartidas (que compilé) y se colocan así:

/home_directory_where_I_compile_and_run_everything
-->/lib/libjson_linux-gcc-4.4.6_libmt.so
-->/lib/libre2.so.0

Cuando compilo mi programa, paso la ubicación relativa de esas bibliotecas al vinculador, como esto:

g++ ...... stuff ........ my_program.cc lib/libjson_linux-gcc-4.4.6_libmt.so lib/libre2.so.0

Y se compila bien, sin embargo, cuando se ejecuta el programa no se puede encontrar libre2.so, y si lo inspecciono con ldd, esto es lo que sucede:

....
lib/libjson_linux-gcc-4.4.6_libmt.so (0x00007f62906bc000)
libre2.so.0 => not found
....

Aparentemente, reconoce que el camino en libjson es relativo, pero no lo hace en libre2.so.0 (recorta todo el camino y solo deja libre2.so.0)

¿Alguien puede decirme por qué sucede esto?

Además, ¿hay una manera de modificar esto a través de un argumento g ++?

Mejor.

* ACTUALIZACIÓN * Whoa mira esto! He cambiado el nombre de libre2.so.0 a stuff.so, y luego traté de compilar esencialmente el mismo como este:

g++ ...... stuff ........ my_program.cc lib/libjson_linux-gcc-4.4.6_libmt.so lib/stuff.so

Y falla de todos modos; no solo falla, sino que falla porque no puede encontrar "libre2.so.0".

Por que

* ACTUALIZACIÓN # 2 *

Salida parareadelf -d the_program.o

0x0000000000000001 (NEEDED)             Shared library: [lib/libjson_linux-gcc-4.4.6_libmt.so]
0x0000000000000001 (NEEDED)             Shared library: [libre2.so.0]

Ahora, si pudiera hacer que [libre2.so.0] sea [lib / libre2.so.0] en lugar de eso, estaría bien.

* ACTUALIZACIÓN # 3 *

Como @troubadour descubrió:

Cuando un ejecutable está vinculado con un objeto compartido que tiene un campo DT_SONAME, entonces cuando se ejecuta el ejecutable, el enlazador dinámico intentará cargar el objeto compartido especificado por el campo DT_SONAME en lugar de usar el nombre de archivo dado al enlazador.

Es por eso que funciona con libjson ..... y no con libre2.so.0. (libjson ..... así que no tiene una entrada para SONAME).

Y finalmente encontré la pregunta exacta para lo que estoy buscando:

¿Hay alguna manera de decirle al vinculador de gcc que ignore las entradas de SONAME en un archivo de biblioteca compartida y que se vincule a la ruta específica del archivo?