Cześć,
Pytanie chyba bardziej dotyczy samego linux-a, ale zadane jest w kontekście programów pisanych w C++ i kompilowanych na różnych wersjach linux-a.
Jak wiadomo linux ma setki odmian, chociaż jądro chyba powinno być to samo. Zacząłem się zastanawiać czy kompilując kod np. na debianie będzie on działał również na ubuntu? Ewentualnie od czego to zależy?
Zakładając, że program będzie chodził na obu systemach to czy są jakieś dodatkowe korzyści kompilacji programu na obu systemach niezależnie vs na jednym z nich? Np. czy jak skompilujemy kod na debianie to na ubuntu będzie on mniej wydajny lub mniej stabilny(?).
Na stronie postgressql mamy oddzielne wersje dla debiana, ubuntu oraz kilku innych wersji. A co jeśli mam minta, archa, gentoo etc. dla których nie ma wersji postgresa? Niby jest opcja other linux - ale dlaczego dla debiana i ubuntu jest oddzielna wersja? Jeśli można zrobić jedną wersję dla pozostałych linux-ów to debian i ubuntu mają swoją wersję?
Zacząłem się zastanawiać czy kompilując kod np. na debianie będzie on działał również na ubuntu?
Co do zasady — tak.
Ewentualnie od czego to zależy?
Od linkowanych bibliotek — czy są takie same albo chociaż kompatybilne. Jeśli są — będzie działać, jeśli nie są — nie będzie.
Np. czy jak skompilujemy kod na debianie to na ubuntu będzie on mniej wydajny lub mniej stabilny(?).
Nie.
Na stronie postgressql mamy oddzielne wersje dla debiana, ubuntu oraz kilku innych wersji.
Różnice w paczkowaniu — program jest prawdopodobnie ten sam, ale inaczej spakowany, żeby różne managery pakietów wiedziały, co z nim zrobić.
A co jeśli mam minta, archa, gentoo etc. dla których nie ma wersji postgresa?
Sami sobie ogarną paczkowanie, zazwyczaj kompilując ze źródeł — żeby mieć pewność, że linkuje do ich wersji bibliotek i nic się nie rozejdzie ani teraz, ani w przyszłości.
Niby jest opcja other linux - ale dlaczego dla debiana i ubuntu jest oddzielna wersja?
Debian i Ubuntu mają inne podejście do aktualizacji podstawowych bibliotek systemowych.
Jeśli coś robisz dla Linuksów, i masz otwarte źródła, to społeczność sobie sama poradzi, jeśli będzie zainteresowana. Możesz im ułatwić start, dostarczając gotowe paczki, ale istnieje szansa, że Ty się napracujesz, a oni to i tak zrobią po swojemu, by mieć większą kontrolę.
Gorzej jak robisz coś zamkniętego, wówczas powinieneś albo kompilować statycznie — jeśli licencja pozwala; albo ganiać za aktualizacjami bibliotek po różnych systemach — jeśli czas pozwala; albo wrzucić to w odpowiedni rodzaj paczki wraz z zależnościami, np. we Flatpaka — jeśli sumienie pozwala.
Wprawdzie pytanie z C++ więc miałem ominąć ale..
Nie wiem na ile stosowanie POSIXA jest problemem na c++ ( powinien być kompilowany w c99, więc mamy C nie C++ ).
Jak nie ma problemu to by była najrozsądniejsza ścieżka imho. ( najmniej użerania się z portownością )
Inna opcja. Sprawdzać czy się kompiluje na trzech wybranych najpopularniejszych dystrybucjach i mieć wywalone.
Ewentualnie:
https://distrowatch.com/search.php#advanced
Masz tam do odhaczenia na dole based on, z tych typów na których inne distro się wzorują sprawdź co jest najpopularniejsze.
Jak widać z tymi setkami odmian to trochę ściema. Jest sporo badziewnych gównianych dystrybucji niemal nie rozwijanych,
którymi nie powinieneś się po prostu przejmować.
Niestety może być czasem tak, że po aktualizacji distra coś się nie
będzie kompilować, więc trzeba czasem sprawdzać czy z kodem wszystko gra. Znacznie bardziej pracochłonne niż opcja pierwsza o której pisałem.
"" Np. czy jak skompilujemy kod na debianie to na ubuntu będzie on mniej wydajny lub mniej stabilny(?).""
Ja bym się tym w ogóle nie przejmował. Nie będzie praktycznie różnic. A jak będą to nie zależy już od Ciebie.
Chyba, że chcesz powiedzieć, że kompilujesz na debianie i kopiujesz binarkę na ubuntu. Jak tak to jest czyste szaleństwo.
__
Jak w repozytorium nie ma jakiejś paczki, a chcesz bardzo ją użyć to ściągasz źródło i kompilujesz,
Może z tego się zrobić czasem masakra ale czasami tak jest łatwiej ( mało zależności )
Tak będzie działał ci na windowsie/linuxie/macos.
Chyba, że użyjesz typowo C library headerów systemowych to wtedy tylko linux rodzina, ale na macos też, bo mac os to taka kopia linuxa, library ma tak samo nazwane i w tych samych katalogach.
Druga sprawa, może być konieczne kompilowanie przy instalacji gdyż, linuxa można zainstalować na różnych procesorach jak arm, mips, amd64, więc wygenerowana binarka może nie mieć adekwatnych instrukcji procesora to żeby ominąć ten problem można na docelowej platformie kompilować.
Generalnie są dwa przypadki. Jeśli linkujesz biblioteki dynamicznie to nawet po grubszej aktualizacji może ci już nie działać, bo nie będzie mógł znaleźć jakiegoś wywołania w bibliotece. Nie mówiąc już o innej dystrybucji, choć akurat między debianem i ubuntu, prawdopodobieństwo, że zadziała jakieś jest. Natomiast jeśli będziesz linkować statycznie to powinno zadziałać na każdym Linuksie na tą samą architekturę. Może z wyjątkiem jakichś skrajnych przypadków.
Zapewne wersja other-Linux jest kompilowana statycznie i przez to jest większa (bo wszystkie zależności są wbudowane w binarkę). W przypadku dedykowanych paczek masz metadane dotyczące zależności, dzięki czemu menedżer pakietów to sobie rozwiąże.
program napisany w C++ będzie działać bez problemu. Jedynie co musisz zrobić, to przygotować paczkę dla odpowiedniej dystrybucji. Każda różni się strukturą katalogów i bibliotekami których używa.
Czyli musisz się nauczyć tworzyć paczki dla Debiana, Ubuntu, Archa etc... no chyba, że dostarczysz źródła do skompilowania ale i tak musisz napisać plik makefile
Althorion napisał(a):
A co jeśli mam minta, archa, gentoo etc. dla których nie ma wersji postgresa?
Sami sobie ogarną paczkowanie, zazwyczaj kompilując ze źródeł — żeby mieć pewność, że linkuje do ich wersji bibliotek i nic się nie rozejdzie ani teraz, ani w przyszłości.
Trochę to pokrętnie napisałeś i za pierwszym razem zrozumiałem że uważasz że postgresa to biblioteka XD
A odpowiadając na pytanie OPa to jeśli czegoś nie ma w oficjalnym repo to zwykle można doinstalować z zewnętrznego repo. Nie takie rzeczy trzeba robić na linuxach XD
Główny problem to binarny compatibility, z którym jest problem na różnych dystrybucjach (i ich dodatkowymi bibliotekami), a nawet w ramach wersji jednej dystrybucji.
Niestety brak jest szacunku do wstecznej kompatybilności.
Funkcje znikają, zmienia się typ argumentów, wielkość klas albo liczba metod wirtualnych.
Nawet zmiana kompilatora ma wpływ na ABI.
Rozwiązania są dwa:
- Budować projekt osobno dla każdej dystrybucji (duże koszty) i utrzymywać tyle paczek ile wspiera się dystrybucji.
- Linkować statyczne biblioteki. - co odbija się na wielkości dostarczanego produktu.
Konkretnych przykładów ci nie dam.
MarekR22 napisał(a):
- Budować projekt osobno dla każdej dystrybucji (duże koszty) i utrzymywać tyle paczek ile wspiera się dystrybucji.
- Linkować statyczne biblioteki. - co odbija się na wielkości dostarczanego produktu.
Tak trobią komercyjne podmioty np. draft sight i inny soft. Wspierają ubuntu/debina, fedora/rhel i opensuse/sled i nara. 3-4 distra utrzymują resztą się nie przejmują i słusznie. Czasami jak matlab(nie wiem czy dale jtak jest) robili tak jak mówisz czyli wszystko statycznie.
No i teraz masz flatpak i ten drugi więc jest pewien postęp.
Największa zaleta/wada** Linux-a to taka że każdy może ten sam problem rozwiązać inaczej bo jest wolność jaka się filozofom nie śniła. A jak nie potrafi ugryźć problemu dostępnymi w systemie środkami to robi kolejną rewolucyjną dystrybucję :)
@Kofcio dobierz rozwiązanie do problemu i możliwości , tak jak napisał @revcorey najdroższe będzie utrzymanie pakietów wielu dystrybucji (które maja wiele wersji) a prawdopodobnie najtańsze statyczne linkowanie (zobacz jak wygląda Firefox do pobrania na stronie mozilla.org)
**niepotrzebne skreślić
Pamiętam jak dawno temu dłubałem w Symbian.
Tam była komenda abdl freeze jeśli dobrze pamiętam, która zapisywała sygnatury wszystkich publicznych funkcji. Jak się potem coś zmodyfikowało, to kompilator walił po łbie, że API się zmieniło.
Przydałoby się coś takiego na Linux.