[Parseval]

Zrobiłem cross-compile programu używając CMake i ustawiając RPATH, żeby binarka szukała dynamicznych bibliotek .so w konkretnej ścieżce pomijając domyślną ścieżkę /usr/lib. Wstępnie wszystko jest dobrze, bo biblioteki są znajdowane z wyjątkiem jednej. Co ciekawe ustawienie LD LIBRARY PATH na tę samą ścieżkę co RPATH pomaga. Macie pomysł dlaczego tak się dzieje?

CMake: https://pastebin.com/XXWB9Xbb

#linux #programowanie #programista15k #programowanie #cpp #cmake

[codeasap-pl]

@Parseval: Sprawdź może tutaj: https://dev.my-gate.net/2021/08/04/understanding-rpath-with-cmake/
Tutaj też piszą, że LD_LIBRARY_PATH jest ważniejsze niż RPATH: https://www.linuxquestions.org/questions/linux-software-2/ld_library_path-overriding-rpath-for-executable-4175639435/

A w man ld.so jest o tym $ORIGIN.

[Parseval]

@codeasap-pl dzięki, pierwszy link już prześledziłem, ale możliwe, że z drugiego i z mana coś jeszcze wyciągnę.
Dziwi mnie jednak fakt, że ustawienie RPATH pozwala na znalezienie niektórych bibliotek, a jedna biblioteka mimo, że siedzi w tym samym folderze z pozostałymi jest niewykrywana. Wygląda mi na to, że ustawienie ld library path naprawia problem, bo wspomniana biblioteka, która jest niewykrywana jest zależnością dla innej biblioteki, która nie widzi RPATH co jest przypisane

[codeasap-pl]

@Parseval: Ja podejrzewam, że może chodzić o tę zależność. Jak dorzucisz LD_LIBRARY_PATH to linker ignoruje RPATH i jedzie według kolejności z ld.conf oraz tej podanej ścieżki w LD_LIBRARY_PATH. A w przypadku RPATH prawdopodobnie widzi tę bibliotekę, ale nie ma jej jak załadować, bo ona jest zależna od czegoś innego, czego nie widzi.
Nie ma zatem jak zlinkować. ELF, biblioteka to też wykonywalny kod, zatem nie może załadować jej częściowo, bo

[codeasap-pl]

@Parseval: Interesuje Cię chyba ten fragment z man ld:

-rpath-link=dir
 When using ELF or SunOS, one shared library may require another.
 This happens when an "ld -shared" link includes a shared library as
 one of the input files.

 When the linker encounters such a dependency when doing a non-
 shared, non-relocatable link, it will automatically try to locate
 the required shared library and include it in the link, if it is

[Parseval]

@codeasap-pl jeśli dobrze rozumiem, to linker powinien w takim razie znaleźć tę bibliotekę :( jutro popróbuje jeszcze z $ORIGIN

[codeasap-pl]

@Parseval: Ale jeśli ma zależność, to potrzebuje tę drugą. A jeszcze dochodzi (według man ld) kwestia "relocatable", czyli "-fPIC" i reszta kolegów. Popatrz na te pliki jakimś objdump/elfdump. nm pokaże pewnie też o które symbole chodzi w tych zależnościach.

[Parseval]

@codeasap-pl: Dopiero znalazłem ponownie czas, żeby do tego przysiąść :D Sytuacja wygląda tak, że w binarce jest libka (libgrpc++.so.1.38). Ta libka ma zależność do libgrpc.so.16 czego nie potrafi znaleźć mimo, że są w tym samym folderze. Prawdopodobnie problem polega właśnie na tym, że brakuje jej RUNPATH na $ORIGIN, tak jak widzę, że mają niektóre inne biblioteki. Spróbuję to przekompilować na nowo tak, żeby wszystkie biblioteki miały RUNPATH.

[codeasap-pl]

@Parseval: Czyli Twoje biblioteki mają RUNPATH, a ta zależna nie, prawda? I Twoje działają, ale już nie może załadować tej zależnej (bo ona nie ma RUNPATH), tak? Bo do tego zmierzałem na początku. A jak ustawisz LD_LIBRARY_PATH, to wtedy linker widzi wszystkie, bo ignoruje RUNPATH.

[Parseval]

@codeasap-pl: Powinno być dokładnie jak piszesz. Zaraz będę to sprawdzał i dam znać co wyszło :)

[codeasap-pl]

@Parseval: Trochę więcej zgadywania: robisz program na gRPC w c++ i kompilujesz bilbiotekę grpc samodzielnie (libgrpc++), ale interfejs c++ jest wrapperem na funkcje w C osadzone w libgrpc.so, którego już samodzielnie nie kompilujesz, bo masz ją w systemie docelowym ("z paczki?"). Dobrze zgaduję? Jeśli tak, to pewnie najlepiej byłoby albo samodzielnie kompilować również grpc (libgrpc) w taki sam sposób, albo napisać skrypt uruchamiający program, który ustawi właśnie LD_LIBRARY_PATH.

[Parseval]

Aktualnie jest tak, że będę pisał program w C++ pod urządzenie z ARMv7 z bardzo okrojonym systemem (postawiony przez buildroota). W związku z tym zrobiłem cross compile protobufów oraz grpc i z przekompilowanych bibliotek próbuję zbudować exampla, do tej pory wszystko się udało z wyjątkiem wyżej opisanych problemów z uruchomieniem binarek. Przekompilowanych przeze mnie bibliotek nie chcę wrzucać do /usr/lib, bo będzie konflikt z aktualnie zainstalowanymi, a mam mocno okrojone możliwości i

[Parseval]

@codeasap-pl: Sukces! Przekompilowałem od nowa gRPC z CMAKE_INSTALL_RPATH na $ORIGIN, biblioteki mają ustawione RUNPATH $ORIGIN i działa jak miało :)
Wielkie dzięki za pomoc!

[codeasap-pl]

o pod Windowsem jest domyślnie taka funkcjonalność, którą próbuję tutaj uzyskać, prawda? Tzn. mając .exe i wrzucając koło niego .dll automatycznie się zaczytają razem z zależnościami.

@Parseval: O tym nie mam bladego pojęcia. Ale być może - w win *.dll są obok. W OSX, czy Guix też programy mają biblioteki obok. Ale co Ty masz tam na ARM to ciężko powiedzieć. Specyfika linkera też tutaj wchodzi.
Ale fajnie, że udało się