[keton22]

Są na sali jacyś spece od #kompilatory?

Dzisiaj w robocie udowodniłem sobie że nie mam bladego pojęcia jak toto działa. Po kolei:
1. platforma Linux, armv7, jaka konkretnie nie mogę powiedzieć ale hula tam normalny aktualizowany Linux
2. mamy sobie bibliotekę .so dostarczaną przez firmę zewnętrzną bez dostępu do kodu źródłowego, są tylko headery
3. jest ona skompilowana przez toolchain który nie do końca pasuje do naszej platformy i nie linkuje się ona z moim kodem narzekając na brak pewnych symboli w libc
4. do tej pory spoko, rozumiem co i jak
5. dzisiaj dostałem wersję tej biblioteki zbudowaną jako static library (.a) przez ten sam nie pasujący toolchain.
6. Nie dość że mogę toto polinkować mimo że nie powinienem to jeszcze jak zrobiłem trik i dałem biblioteki .a gcc i kazałem zrobić .so to te nowe .so linkują się też bez żadnego problemu

No i ja teraz nie wiem co to tu się... Wydawało mi się że wiem jak działa toolchain a tu takie dziwy.

Ktoś mnie uświadomi? I czy mogę spokojnie tego używać czy mam się dalej pałować z dostawcą żeby łaskawie użył mojego toolchaina i podzielił się wynikiem?

#programowanie

[Passer93]

To nie zależy od toolchainu, przecież pliky wynikowe, czy to wykonywalne czy biblioteki musza być zgodne z System V ABI i to nie ma znaczenia przez jaki toolchain zostały wygenerowane.

Ja bym strzelał że wersja libc która była użyta do wygenerowania biblioteki jest inna niż ta którą wy macie dlatego nie możesz tego zlinkować.

Dlatego jak zrobisz biblioteke .so na swoim systemie to działa, bo tworzysz ją z wersją libc która jest

[keton22]

@Passer93: ok ale dlaczego .so nie działa, .a działa a po konwersji .a -> .so działa?
Mi nawiększego mentalnego ćwieka zabija że przecież libc które jest w tym niepasującym toolchainie jest kompletnie inne, są dodatkowe symbole których na swoim systemie nie mam. Te symbole są wykorzystywane przez kompilator bo oryginalne .so przez nie się nie linkuje.
Co to za magia że muszę je mieć dla .so ale nie dla .a?

[Passer93]

@keton22 Może jeśli .a jest statyczna to zależności z libc nie są linkowane tylko wkompilowane wprost w biblioteke? xD Nie wiem, sam strzelam.

Może pobaw się jakimś nm/objdump i zobacz co jest w środku.

[Saly]

@keton22: pliki .a to zwykłe archiwum zawierające pliki .o, nic więcej. Plik .so są bardziej skomplikowane, masz tam np. takie coś jak soname, który mówi jaka jest wymagana wersja. Dodatkowo może to być spowodowane przez mechanizm linkowania. W plikach .so wszystko ma działać, dodatkowo linkowanie z plików .a działa na takiej zasadzie, że wyciągasz tylko to co potrzebne.

6. Nie dość że mogę toto polinkować mimo że nie powinienem to

[keton22]

Linker wzial sobie symbola z .a i tyle

@Saly: tyle że kod w tym symbolu polega na innych symbolach których u mnie nie ma.
To nie jest final static gdzie wszystko co jest bibliotece potrzebne łącznie z kawałkami libc siedzi w tym .a. Widziałem takie wynalazki przy paru projektach i po samej wadze i liście symboli nie ma opcji.
Linker normalnie krzyczy że chce np. openssl i librt. I dostaje ode mnie inną wersję openssl niż ma vendor i jakoś testy przechodzą.
Problem w tym że moje testy nie pokrywają za wiele i chcę jakoś ogarnąć czy to szczęśliwy zbieg okoliczności że na razie działa i przestanie czy mogę tak po

[Saly]

Linker normalnie krzyczy że chce np. openssl i librt. I dostaje ode mnie inną wersję openssl niż ma vendor i jakoś testy przechodzą.

Problem w tym że moje testy nie pokrywają za wiele i chcę jakoś ogarnąć czy to szczęśliwy zbieg okoliczności że na razie działa i przestanie czy mogę tak po prostu działać.

@keton22: zobacz sobie np. używając readelf -a plik.o jak wyglądają symbole undefined. Tam jest tylko nazwa funkcji i jeżeli ta nazwa zgadza się z tym co masz u siebie w systemie to wszystko zlinkuje się prawidłowo.

Przykładowo mając