Wyodrębnienie kompilatorów do osobnego folderu na Linuxie

0

Cześć,

mam w systemie zainstalowane GCC i Clang. Chce je wyodrębnić do osobnego folderu, w którym mam również kody źródłowe programów. Chodzi o to, aby można było później ten folder skopiować do innego systemu i rozpocząć kompilację plików przy użyciu dołączonych kompilatorów. Przy czym chciałbym skopiować wyłącznie pliki niezbędne do kompilacji C++. C mnie nie interesuje. Słabo znam Liunxa. Dzięki za pomoc albo przynajmniej dobre wskazówki

0

Po pierwsze do C++ potrzebujesz G++ a nie GCC (aczkolwiek system automatycznie cię "przełączy")
Po drugie poszukaj wersji "portable" (o ile takowa istnieje) bez tego to niewykonalne. Za dużo zależności i potrzebnych bibliotek systemowych w konkretnych wersjach / ich przedziałach.

0

Wiem. GCC to także nazwa zestawu wszystkich kompilatorów projektu GNU.
Skoro jest to niewykonalne, to w jaki sposób zainstalować wiele różnych wersji GCC tak, żeby śmigały pod różnymi nazwami? Np. wersja 8.1 odpalana jako g81++, wersja 7.1 jako g71++, wersja 4.9.3 jako g493++... itd?

0

Musisz mieć w systemie osobne pakiety GNU Compiler Collection - jak to jest np. w Arch-u zrobione (AUR). Każdy taki pakiet GCC jest kompilowany pod indywidualną ścieżkę lib-ów i inną nazwę binarek. I wtedy możesz sobie używać jakiegokolwiek kompilatora podając jego nazwę - np. gcc-4.6 lub gcc-5.3.

4

Do takich rzeczy powstał docker. Ściągnij dockera i obraz z GCC/Clang i masz już przenośne środowisko, nie tylko gcc, ale cały system jaki jest potrzebny. W ten sposób unikasz niezgodności wersji bibliotek-zależności, która prawdopodobnie nastąpi jeśli tak po prostu przeniesiesz binarki. Inną opcją jest skompilować GCC/clang ze źródeł, statycznie linkując biblioteki. Tylko nie wiem po co tyle zabawy skoro większość dystrybucji ma managery pakietów i można jednym poleceniem zainstalować te rzeczy, no chyba że masz problem z przenośnością między wersjami kompilatora.

3
Cpp17 napisał(a):

Chodzi o to, aby można było później ten folder skopiować do innego systemu i rozpocząć kompilację plików przy użyciu dołączonych kompilatorów.

To nie zadziała. Bo nie tylko musisz mieć dobry kompilator, ale również odpowiednie (kompatybilne) wersje wszystkich zależności (i to zależności kompilatora, a nie projektu). No i (mam nadzieję, że to oczywiste) będzie to działać tylko w obrębie jednego systemu operacyjnego.

Docker jest tutaj jednym z najprostszych rozwiązań (ale nie jedynym).

Coś mi się wydaje, że mamy tutaj XY problem.

0
Lampart napisał(a):

Musisz mieć w systemie osobne pakiety GNU Compiler Collection - jak to jest np. w Arch-u zrobione (AUR). Każdy taki pakiet GCC jest kompilowany pod indywidualną ścieżkę lib-ów i inną nazwę binarek. I wtedy możesz sobie używać jakiegokolwiek kompilatora podając jego nazwę - np. gcc-4.6 lub gcc-5.3.

Rozumiem i podoba mi się takie rozwiązanie, ale nie bardzo wiem, jak się za to zabrać. Jakimi komendami to wgrać, żeby się wszystko nie nadpisało?

To rozwiązanie z dockerem też jest ciekawe, tylko nie wiem, czy nie za głęboko jak na początek. XY powiadasz... no potrzebuję po prostu różnych zestawów kompilatorów do kompilacji i testów. Myślałem, że pójdzie lekko jak na Windowsie, gdzie sobie pokatalogowałem porty MinGW, porobiłem odpowiednie skrypty i mogę to w 30 sec. przenieść na inną platformę sprzętową. No ale pogodziłem się już z faktem, że się nie da na Linuxie tak zrobić i teraz wystarczy mi, żebym jakkolwiek mógł te różne zestawy GCC wgrać.

1

Po prostu w Archu instalujesz sobie systemowe gcc7 a potem budujesz pakiety GCC alternatywne z AUR-a: https://aur.archlinux.org/packages/gcc48-alternative-multilib/ https://aur.archlinux.org/packages/gcc49-alternative-multilib/ lub https://aur.archlinux.org/packages/gcc53-alternative-multilib/ przy pomocy makepkg i tyle. Te pakiety gcc*-alternative są tak zrobione, żeby się wzajemnie nie nadpisały. Musisz je sobie tylko przekompilować.

0

@Cpp17 czy Ty przypadkiem nie potrzebujesz zwykłego CI? Skoro mówisz, że to do testów, to po kiego grzyba Ci to w tym samym folderze co kody źródłowe? No i o przenoszeniu plików wykonywalnych na inną platformę sprzętową zapomnij. To nie zadziała (o ile nie masz tzw. "fat binaries" a Linuks takowych nie wspiera).

0

Drodzy Panowie! Wiem, że piszę o czymś innym niż LibreOffice, ale to nie znaczy, że mam jakiekolwiek pojęcie o Linuxie ;( Potrzebuję poprowadzenia za rączkę albo poradnika dla dzieci.

Fajnie, że dostałem linki do pakietów alternatywnych GCC. Czy one (poza nazwami) niczym się nie różnią od tych standardowych?

@hauleth nie wiem, co to zwykłe CI. Chciałem mieć to w jednym folderze, żebym mógł sobie przyjść z pendrivem do Pani Marysi, która ma ubuntupodobny system i odpalić plik run.sh, który skompiluje mi kody źródłowe w pięciu różnych wersjach pakietów GCC i Clang. Tak, żebym już u Marysi nie musiał żadnych makepkg, apt get i innych cudów robić. Marysia nie ma Internetu i nawet nie wie, co to jest komputer (czyli jest dziesięć razy głupsza niż ja). Ona potrafi tylko odpalić plik run.sh.

0

To najbliższy temu jest docker, ale mimo to jak żywo nie rozumiem po co. Kompatybilność wsteczna kompilatorów jest olbrzymia i jedyne co chciałoby mi się zrobić, to upewnić się, że zawsze przekazuję te same flagi kompilacji (bo na przykład mogły się zmienić domyślne i kompiluję w innym standardzie albo z innymi flagami błędów itd.).

Żeby nie było, że rzucam słowa na wiatr: zobacz sobie bugtrackery od Gentoo dla GCC 8, GCC 7 czy GCC 6 — jest tam tylko jeden który kojarzę, który byłby czym innym niż właśnie problemem niewystarczająco ustawionych flag (a był to błąd taki, że był kod, który nie miał prawa się skompilować w ogóle nigdzie, bo był bardzo niezgodny ze standardem, ale starsza wersja kompilatora go łykała bez zająknięcia).

0

@Althorion: odnoszę wrażenie, że bardziej chcesz zaszpanować niż mi pomóc:D Potrzebuję różnych kompilatorów, bo testuję różne rzeczy (zgodność, czas kompilacji, optymalizacje, objętość kodu, czas wykonania etc. etc). Powiedziałem, że jestem Linuksowym laikiem. To tak, jakbyś mi udzielał rady typu "możesz sobie to zmontować w Adobe Studio". A ja nie pytam w czym, tylko jak...

Oczywiście nie musi być instrukcja ze szczegółami, ale też bez czegoś w stylu "poszukaj sobie w Google". :D Szczegółów sobie poszukam, ale - w najprostszej wersji - jak to zrobić?

1

Widzisz — to, co chcesz robić, jest dziwne. I, jak większość rzeczy dziwnych, częściej wynika ze złego podejścia laika, niż z faktycznych potrzeb, to wolę Cię „wymacać”, czy faktycznie wiesz co robisz (nawet laikom się to zdarza ;)). W szczególności, czy naprawdę potrzebujesz wielu wersji kompilatorów (a nie, co ja sugerowałem — jednej najnowszej) na wielu różnych maszynach (o co podpytywał hauleth, chcący Ci polecić coś do ciągłej integracji (CI)).

I jeśli jest tak faktycznie, to jak pisałem — najbliższy temu będzie docker. I na Docker Hubie znajdziesz gotowe obrazy dla różnych wersji GCC (ale już nie Clanga, tutaj byś musiał robić samemu) z opisem, jak tego używać. Jeszcze Ci brakuje do pełni szczęścia informacji, jak tego Dockera zainstalować i używać, ale to już zależy od konkretnej dystrybucji. Na przykład dla Archa — https://wiki.archlinux.org/index.php/docker

Podsumowując, pani Marysia musiałaby mieć zainstalowanego Dockera (co musisz jakoś ogarnąć sam), a potem już tylko podrzucasz jej pliki z obrazami GCC (z tego linka wyżej) i programem i może sobie to skompilować jednym poleceniem wtedy.

1

Fajnie, że dostałem linki do pakietów alternatywnych GCC. Czy one (poza nazwami) niczym się nie różnią od tych standardowych?

To są standardowe wersje GCC tyle tylko że przekompilowane tak żeby nie kłóciły się między sobą. Tak jak pisałem wcześniej - one instalują swoje pliki w indywidualnych katalogach im dedykowanych - więc konfliktów nie będzie.

1

Stawialbym na obrazy dockera. Potrafia skompilowac zewnetrzne zrodla podlaczone woluminem, na LinkedIn jest kurs o tym:

https://www.linkedin.com/learning/web-servers-and-apis-using-c-plus-plus

Instalowanie alternatywnych gcc to ryzykowna gra i nie zawsze sie to dobrze konczy.

0
vpiotr napisał(a):

Instalowanie alternatywnych gcc to ryzykowna gra i nie zawsze sie to dobrze konczy.

Co masz na myśli?

Laik naprawdę potrzebuje różnych wersji kompilatorów, bo laik te kompilatory testuje :) Cała reszta to próba stworzenia odtwarzalnego środowiska testowego w łatwy i przyjemny sposób. Może i być ten Docker, byle tylko dało się go również do tego katalogu wsadzić i oskryptować tak, żeby się automatycznie zainstalował przed testami. .. jednak podejrzewam, że to będzie trudniejsze niż automatyczne zainstalowanie różnych wersji kompilatorów vel ryzykowna gra?

1

@Cpp17: a nie myślałeś o tym, by udostępnić to jako pakiet Debioanowy? Są narzędzia, które usprawniają takie pakowanie, a dzięki takiemu podejściu masz również możliwość aktualizacji wszystkich użytkowników przy pomocy centralnego repozytorium.

0
hauleth napisał(a):

@Cpp17: a nie myślałeś o tym, by udostępnić to jako pakiet Debioanowy? Są narzędzia, które usprawniają takie pakowanie, a dzięki takiemu podejściu masz również możliwość aktualizacji wszystkich użytkowników przy pomocy centralnego repozytorium.

O! W sensie, mógłbym te wszystkie kompilatory i kody źródłowe spakować do jednego pakietu, a gdybym zmienił coś w repozytorium, to każdy by sobie mógł zassać aktualizację? To by było super. Jeśli mam te alternatywne kompilatory, to dałoby radę coś takiego spakować? Każdy GCC ma inną nazwę, czyli - jak rozumiem - nie będzie konfliktów na tym polu?

Co do "przenośności" wystarczy mi w sumie, żeby osoba dokładnie na tej samej wersji systemu była w stanie to odpalić. Czyli: mam jakiś nowy sprzęt, instaluję na nim tę samą dystrybucję systemu i przy pomocy jednej albo dwóch mało skomplikowanych komend umożliwiam uruchomienie testów. Im prościej - tym lepiej.

1

Co ty się tak uparłeś tych kompilatorów na litość bogów. Jak masz pakiet, to jest on już skompilowany i udostępniasz już tylko gotową binarkę. Ja widzę tutaj olbrzymi problem XY - opisujesz cały czas rozwiązanie, które sobie wymyśliłeś zamiast opisać problem, który próbujesz rozwiązać. To powoduje, że wychodzą idiotyczne problemy do rozwiązania problemu.

Pytania jakie są:

  • Czemu ktokolwiek miałby testować kompilatory tutaj?
  • Co wg Ciebie mieli by testować przy pomocy tych kompilatorów?
  • Nie masz testów automatycznych?
  • Czy macie jakiekolwiek CI?
0

To, że robię coś, co się rzadko robi to nie znaczy od razu XY. xD

Pytania jakie są:

  • Czemu ktokolwiek miałby testować kompilatory tutaj?
  • Co wg Ciebie mieli by testować przy pomocy tych kompilatorów?
  • Nie masz testów automatycznych?
  • Czy macie jakiekolwiek CI?

-BO TAKIE JEST ZAŁOŻENIE MOJEJ PRACY.

  • Testuje wpływ wersji kompilatorówna czas wykonania, objętość kodu wynikowego etc., etc... już o tym wspominałem... np. Clang w wielu przypadkach generuje lepszy kod, wiedziałeś o tym? A wiedziałeś, jakie to przypadki i jakiego rzędu są to różnice? O tym między innymi jest moja praca..
  • co masz na myśli? Mam katalogi z programami i skrypty, które je kompilują / wykonują w kilku iteracjach i badają średnie czasy.
  • CO TO JEST CI, mądralo? ;O
0

A czy ktoś mógłby mi wreszcie pomóc, zamiast mądrzyć się, co ma sens, co nie ma sensu i jak należy przeprowadzać testy? :D To, że nie ogarniam Linuxa, nie oznacza automatycznie, że jestem imbecylem z IQ poniżej 75. Poradzę sobie ze szczegółami, ale nie wiem nawet, od czego zacząć. Co wpisać, gdzie, jaką komendę? Napisałem, co chcę zrobić. Zainteresowało mnie rozwiązanie z instalacją wielu alternatywnych pakietów i centralne repozytorium, które będę mógł aktualizować. Powiedzcie mi, proszę, jak to ugryźć...będę wdzięczny.

1

To, jak to ugryźć, zależy od konkretnej dystrybucji, z której będziesz korzystał — bo każda ma inny manager pakietów, więc inaczej to w niej działa. Dobrym punktem startu będzie wyszukanie w ulubionej wyszukiwarce (nazwa dystrybucji) custom repo.

A co Ci nie odpowiada w rozwiązaniu z Dockerem, jak opisywałem wyżej?

I jeśli jest tak faktycznie, to jak pisałem — najbliższy temu będzie docker. I na Docker Hubie znajdziesz gotowe obrazy dla różnych wersji GCC (ale już nie Clanga, tutaj byś musiał robić samemu) z opisem, jak tego używać. Jeszcze Ci brakuje do pełni szczęścia informacji, jak tego Dockera zainstalować i używać, ale to już zależy od konkretnej dystrybucji. Na przykład dla Archa — https://wiki.archlinux.org/index.php/docker

1
Cpp17 napisał(a):

A czy ktoś mógłby mi wreszcie pomóc, zamiast mądrzyć się, co ma sens, co nie ma sensu i jak należy przeprowadzać testy? :D To, że nie ogarniam Linuxa, nie oznacza automatycznie, że jestem imbecylem z IQ poniżej 75. Poradzę sobie ze szczegółami, ale nie wiem nawet, od czego zacząć. Co wpisać, gdzie, jaką komendę? Napisałem, co chcę zrobić. Zainteresowało mnie rozwiązanie z instalacją wielu alternatywnych pakietów i centralne repozytorium, które będę mógł aktualizować. Powiedzcie mi, proszę, jak to ugryźć...będę wdzięczny.

Jeśli masz Arch-a to:

  1. Ściągasz sobie alternatywne gcc-ki:
    https://aur.archlinux.org/cgit/aur.git/snapshot/gcc48-alternative.tar.gz
    https://aur.archlinux.org/cgit/aur.git/snapshot/gcc49-alternative.tar.gz
    https://aur.archlinux.org/cgit/aur.git/snapshot/gcc53-alternative-multilib.tar.gz
    każdy do innego katalogu,
  2. rozpakowujesz każdy z tych tar.gz-pów
  3. w każdym z katalogów uruchamiasz: "makepkg" i po jakimś czasie dostajesz gotowe pakiety do zainstalowania
  4. Instalujesz otrzymane pakiety - np. dla gcc-4.8 będą to:
    pacman -U gcc48-alternative-libs-multilib-4.8.5-2-x86_64.pkg.tar.xz
    pacman -U gcc48-alternative-multilib-4.8.5-2-x86_64.pkg.tar.xz
    pacman -U lib32-gcc48-alternative-libs-4.8.5-2-x86_64.pkg.tar.xz

to chyba wszystko.

0

A co Ci nie odpowiada w rozwiązaniu z Dockerem, jak opisywałem wyżej?

Rozwiązanie jest dobre i skorzystam z niego w razie problemów. Na razie chciałem spróbować zrobić to bez konteneryzacji. Wg mojej wiedzy, z Dockerem powinno to działać z podobną wydajnością (choć pewnie musiałbym się tłumaczyć).

@lampart, dziękuję Ci ciepło! Mam Miętę - zadziała, czy muszę szukać innych paczek?

1
Cpp17 napisał(a):

@lampart, dziękuję Ci ciepło! Mam Miętę - zadziała, czy muszę szukać innych paczek?

Znaczy się masz Minta? Mint to zdaje się pochodna Ubuntu - więc tam zamiast pacman-a używasz zapewne apt-get-a albo dpkg. Minta słabo znam więc nie pomogę za bardzo. Pod Ubuntu kiedyś były zdaje się alternatywne GCC-ki, takie które nie gryzą się z podstawowym GCC-kiem, więc może i na Mincie to pójdzie?

1

W takim razie nie masz gotowca dla Minta, tylko musisz znaleźć, tak jak pisałem, jak się tam robi własne repozytorium (ubuntu custom repository — Mint bazuje na Ubuntu) i jak się robi paczki (pamiętam, że na debianowatych było to dosyć wymagające, ale w sumie nic poza tym — ostatnio to robiłem z dziesięć lat temu…).

Oprócz tego, sensownym będzie przeczytanie plików PKGBUILD tych paczek wyżej, to zwykłe skrypty basha które mają za zadanie zbudować co trzeba.

0

OK, Panowie, na bazie wskazówek zacząłem mieszać łokciem w terminalu (inaczej tego nazwać nie można). Kiedy myślałem, że coś mi się udało, wpisałem g++5. Nie zadziałało. Ale konsola mi podpowiedziała, że mogę sobie zainstalować:

sudo apt install g++-5

Jak łatwo się domyślić, zrobiłem to samo dla g++-6, g++-7 i g++-8. Nie wiem, czy miałem w tym jakikolwiek udział (chyba nie). W każdym razie dostałem to, czego oczekiwałem. Do pełni szczęścia brakuje mi jeszcze jakiejś wersji g++ 4.x. Niestety, oficjalnie (??) tego nie ma, a nie znalazłem żadnego prywatnego repo, który miałby paczki zgodne z bionic. W związku z tym moje pytanie: czy można "na chama" wgrać paczkę zrobioną pod starszą wersję systemu?

1

Pewnie można, ale ryzykujesz że Ci system wybuchnie. Spróbuj najpierw zrobić to samo pod maszyną wirtualną.

0

Tzn. nie mam nic do stracenia - mogę ryzykować, tylko jak? Mam maskę spawacza w razie czego

1

No to jak nie masz, to zakrzyknąć „Awruk!”, słowo ulubione, zawołanie rodu, znaleźć sobie w sieci (link będzie po drugiej stronie ulubionej wyszukiwarki internetowej; ale żeby nie było, że wszedłem w tryb „pełna Elektroda” — gcc-4.9) paczkę, pościągać jej zależności, zainstalować (sudo dpkg -i (paczka)) i przetestować całość.

1 użytkowników online, w tym zalogowanych: 0, gości: 1