Anwendung erfordert libssl.so.10 => /usr/lib64/libssl.so.10 explizit

Question

Ich habe eine Anwendung, die von tun:

export LD_LIBRARY_PATH=/this/is/another/folder 
ldd myApp 
// ... 
libssl.so.10 => /usr/lib64/libssl.so.10 
// ... 

Erste Frage: Warum myApp Links explizit auf libssl. so.10? wenn im OpenSSL-Ordner Ich habe (sollte nicht mit libssl.so verknüpfen?):

/usr/lib64/libssl3.so 
/usr/lib64/libssl.so -> libssl.so.1.0.1e 
/usr/lib64/libssl.so.10 -> libssl.so.1.0.1e 
/usr/lib64/libssl.so.1.0.1e 

Zweite Frage: Warum wird es openssl lib in/usr/lib64 und nicht die in/das/ist/ein anderer/Ordner?

zwei Informationen: Strace auf meinem exec mir gab (das sagt deutlich, dass es versucht, in meinem Ordner zu laden libssl.so.10 aber war nicht da, und es soll nicht sein, wie ich mit libssl zu verknüpfen erwarten. so):

open("/this/is/another/folder/libssl.so.10", O_RDONLY) = -1 ENOENT (No such file or directory) 
open("/usr/lib64/libssl.so.10", O_RDONLY) = 3 

und die elf meiner exec ist:

0x0000000000000001 (NEEDED)    Shared library: [libssl.so.10] 

UPDATE Haupt Make-Datei Sektionen:

SRC = myApp.cpp 
TARGET = myApp 
INCLUDE = -I/my/open/ssl/path/include 
LINK = -L/my/open/ssl/path/libs -lssl -lcrypto 

CFLAGS = -MMD -MP -c -std=c++0x 

all: $(TARGET) 

$(TARGET): $(SRC) 
     $(CXX) -o $(TARGET) $(SRC) $(LINK) 

Jede Hilfe wird geschätzt!

Kasper

Answer 1

Denn wenn man mit -lssl verknüpfen, der Link Editor (ld) schaut libss.so auf und sendet einen DT_NEEDED-Tag im .dynamic Abschnitt der Ausgabedatei zu, was auch immer die Datei selbst erklärt sein.

Diese Erklärung aus dem DT_SONAME-Tag aus dem .dynamic Abschnitt libssl.so (die in der Regel ein symbolischer Link ist) kommt, und es meldet libssl.so.10.

Die dynamische Lade (ld.so) wird dann lesen DT_NEEDED Tag und sucht nach einer Datei libsso.so.10 benannt.

Ich eigentlich wrote about this vor einigen Jahren, so können Sie die für die langfristige Erklärung suchen.