Chcę zacząć od prostego użycia łączenia, aby wyjaśnić mój problem. Załóżmy, że istnieje bibliotekaz które można skompilować do biblioteki współdzielonej libz.dll (D: /libs/z/shared/libz.dll) lub do biblioteki statycznej libz.a (D: /libs/z/static/libz.a).

Pozwól, że chcę się z nim połączyć, a następnie:

gcc -o main.exe main.o -LD:/libs/z/static -lz

Wedługta dokumentacja, gcc wyszuka libz.a, czyli

archiwizuj pliki, których członkowie są plikami obiektowymi

Mogę również wykonać następujące czynności:

gcc -o main.exe main.o -LD:/libs/z/shared -lz

Nie wspomniano o tym w dokumentacji powyżej-l flaga będzie szukaćlib<name>.so.

Co się stanie, jeśli I libz.a i libz.dll znajdą się w tym samym katalogu? Jak biblioteka zostanie połączona z programem? Dlaczego potrzebuję flag-Wl,-Bstatic i-Wl,-Bdynamic Jeśli-l wyszukuje zarówno biblioteki współużytkowane, jak i statyczne?

Dlaczego niektórzy programiści udostępniają pliki .a z plikami .dll dla tych samych modułów, jeśli kompiluję dystrybucję biblioteki współdzielonej?

Na przykład Qt udostępnia pliki .dll w katalogu bin z plikami .a w katalogu lib. Czy jest to ta sama biblioteka, ale zbudowana odpowiednio jako współdzielona i statyczna? Lub pliki .a są pewnego rodzaju fałszywymi bibliotekami, które zapewniają połączenie ze współdzielonymi bibliotekami, gdzie są prawdziwe implementacje bibliotek?

Innym przykładem jest biblioteka OpenGL w systemie Windows. Dlaczego każdy kompilator musi udostępniać statyczną bibliotekę OpenGL, taką jak libopengl32.a w MingW?

Do czego służą pliki z rozszerzeniami .dll.a i .la?

P.S. Jest tu wiele pytań, ale myślę, że każda z nich zależy od poprzedniej i nie ma potrzeby dzielenia ich na kilka pytań.