Dotaz: Kompilace pro běh na starších distrech

[lumpik66]

Zdravím,

snažím se přeložit projekt s g++/qt tak, aby běžel i se staršími systémy. Příklad. když nyní přeložím stejný projekt na Ubuntu 20.04 a chci ho spustit pod 18.04 tak se nespustí. Jak tohle nejlépe vyřešit?

Problém je "/lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found". WTF?

To jako 2 roky starší distro nespustí binárky přeložené na novějším?

To mám překládat vše na 10 let starém distru, abych měl trochu jistoty, že to spustí i na starších strojích?

Přece nemám staticky linkovat glibc??

---

---

Odpovědi

[Max]

A proč myslíš, že každé distro má svůj vlastní repositář? Přesně kvůli tomu, že se linkuje dynamicky proti nějakým verzím s nějakou implementací ABI apod. Další problém je generační změna ve struktuře adresářů apod. Třeba ten "/lib/x86_64-linux-gnu" nebyl v distrech odjakživa.
Pokud by jsi chtěl svoje šance s kompatibilitou u jednoho balíčku zvýšit, tak kompiluj na starším OS a zkoušej spustit na novějším .
Zdar Max

[lumpik66]

Linux používám už asi 20 let každý den a stejně dlouho na něm i vyvíjím. Ale tohle mě vždy dostane. Za tak dlouhou dobu není nikdo schopen zajistit zpětnou kompatibilitu a to ani u stejné distribuce 2 roky staré. Jak windows nesnáším, tak tohle jediné mají vyřešeno opravdu dobře.

Takže není žádné rozumné řešení než se vracet v čase?

Představa, že chci nabídnout uzavřenou aplikaci na Linuxu, která má běžet všude je asi nereálná?

[Petr Šobáň]

A proč ne?

Ovšem pak to musíš překládat pro příslušné knihovny které jsou v těch starých distribucích.

Ale udržovat projekty aby běhaly na 20 let starých distribucích je cesta do pekel.

[lumpik66]

Jenže slinkovat staticky glibc moc dobře nejde. Přesně to jsem se snažil, jenže i když jsem natahal všechny knihovny do adresáře s aplikací, tak to jen krásně padá. Ano, knihovny si tahám staré. Jenže stále je problém v tom, že to nemohu přeložit na novém stroji s aktuálním toolchainem a především glibc. Takže asi virtuální stroj se starým distrem je jediné možné řešení, aniž bych prasil systém.

[lumpik66]

Padáním myslím SEGFAULT.

[Peter Golis]

A prečo nevyužiješ dostupné build hosty, bráni ti v tom licencia?

[lumpik66]

20 let není třeba. Ale aby byl problém i s 2-lety starým? :) Mělo by to běžet na něčem jako debian-oldstable.

[Max]

Takové aplikace jsou do nějaké úrovně slinkovány většinou staticky a tahají si ty knihovny sebou. Podobně jako na Windows . Takže ten příměr s Windows nechápu.
Zdar Max

[Peter Golis]

Ja to prirovnanie chápem. Už len z toho dôvodu, že dodávateľ staticky linkovaného SW by mal zabezpečiť udržiavanie ním používaných verzií externých knižníc. No a spraviť si build pre rôzne distrá a ich verzie je menej prácne ako ručne sledovať a aplikovať všetky tie patchworky o ktoré sa zvykne starať správca distribúcie alebo externého repozitára.

[Andrej]

Jak tohle nejlépe vyřešit?

Používáním aktuálních systémů…?

To jako 2 roky starší distro nespustí binárky přeložené na novějším?

Těžko říct. Nikdy jsem nepoužíval distro straší než 2 měsíce, takže u dvou let bych všeho všudy konstatoval, že výsledek bude libovolně–nedefinovaný.

(A tak to má být; nemá smysl vláčet s sebou několikaletou přítěž zpětné kompatibility a tunu starých bugů k tomu.)

To mám překládat vše na 10 let starém distru, abych měl trochu jistoty, že to spustí i na starších strojích?

Ne.

Stroje „mladší“ než cca 10 let můžou zkrátka provozovat aktuální distro. U strojů starších než cca 10 let má jejich majitel jistě natolik dobrý důvod držet je v provozu, aby do překladu binárek speciálně pro ně byl ochoten investovat trochu času a úsilí. Což se může dost zkomplikovat, protože například připojení takových strojů k internetu není dobré riskovat…

[lumpik66]

Třeba protože ten uživatel není linuxovej nadšenec co nepotřebuje každou chvíli něco instalovat a řešit, proč to zase nejede, když to na starý vyrzi jelo? A třeba mu vše funguje a nemá jediný důvod přecházet na jinou verzi. A nebo mu to nainstaloval někdo jiný a kvůli jediné aplikaci nebude volat někoho dalšího? A nebo protože ta aplikace je pro podniky, kde jedou na stabilních verzích a opravdu to poslední co chtějí je řešit každou chvíli nový systém :D Ano, taky jsem kdysi fungoval na Gentoo, Arch Linux. Ale s realným světem to nemá nic společného.

No můj problém vyřešil virtuál. Je to smutné, ale očividně s novými nástroji to prostě nejde. Tohle linux neumí ani trochu. Proč se nedají stáhnout z těch repozitářů staré verze toolchainu, glibc někde bokem do userspace? To to ještě nikoho nenapadlo?

Zajímavé, že stačí zkompilovat na starém distru a už to jede. Ale opačně to nejde.

[Andrej]

A třeba mu vše funguje a nemá jediný důvod přecházet na jinou verzi.

Myslí si, že nemá, jenže většinou má: Bezpečnost.

A nebo protože ta aplikace je pro podniky, kde jedou na stabilních verzích a opravdu to poslední co chtějí je řešit každou chvíli nový systém :D

Rozumné distro s rolling updates se neřeší, není tam co řešit; je zkrátka aktuální.

Aplikace „pro podniky“ je častá výmluva, nicméně zajímalo by mě, proč se „podniky“ neobrací především na dodavatele té aplikace, která je (zjevně) špatně udržovaná a zastaralá.

Ale s realným světem to nemá nic společného.

Jak je definovaný ten reálný svět? Například s mým reálným světem, tedy s mou prací i zábavou, to má nejen mnoho společného, ale je to s obojím dokonce v dokonalém souladu.

No můj problém vyřešil virtuál. Je to smutné, ale očividně s novými nástroji to prostě nejde. Tohle linux neumí ani trochu.

Dodavatel té pofidérní aplikace cosi neumí. Nevidím důvod vinit z toho „Linux“ jako takový.

Proč se nedají stáhnout z těch repozitářů staré verze toolchainu, glibc někde bokem do userspace?

Protože mají v sobě spoustu neopravených bugů, leckdy velmi nebezpečných, a žádný správce distribuce si nechce takovou věc vzít na triko. Ne že by šlo o nějakou odpovědnost v právním slova smyslu, ale reputace kolem bezpečnosti je důležitá.

To to ještě nikoho nenapadlo?

Jistě napadlo, ale vzápětí si možná položil otázku, proč by měl řešit problémy způsobené dodavateli neudržovaných a nekompatibilních komerčních aplikací, když jinak 999‰ upstreamu s vývojem kolem knihoven a distribucí bez problémů drží krok.

Zajímavé, že stačí zkompilovat na starém distru a už to jede.

Pak tedy nezbývá než doufat, že to neposlouchá na žádném portu.

[Martin Tůma]

Jistě napadlo, ale vzápětí si možná položil otázku, proč by měl řešit problémy způsobené dodavateli neudržovaných a nekompatibilních komerčních aplikací, když jinak 999‰ upstreamu s vývojem kolem knihoven a distribucí bez problémů drží krok.

s/bez problémů/s vypětím všech sil/g ...

[Martin Tůma]

No můj problém vyřešil virtuál. Je to smutné, ale očividně s novými nástroji to prostě nejde. Tohle linux neumí ani trochu. Proč se nedají stáhnout z těch repozitářů staré verze toolchainu, glibc někde bokem do userspace? To to ještě nikoho nenapadlo?

Napadlo a výsledkem jsou různé flatpacky a appimage... Pokuď chceš vyrábět jenom jednu binárku tak cesta vede asi jenom tudy.

Zajímavé, že stačí zkompilovat na starém distru a už to jede. Ale opačně to nejde.

To může být zajímavé pouze pro někoho, kdo vůbec netuší, jak věci fungují... Neplatí to pro všechny knihovny, ale zrovna (g)libc je tímto směrem kompatibilní přes spoustu verzí. Opačně to z podstaty fungovat nebude, protože nové buildy můžou používat nějaké nové API, které ve starších verzích vůbec nebylo.

[Odin1918]

V Debiane pouzivam chroot so starsou verziou, kde mam kompilator a potrebne kniznice. V mojom pripade ide nielen o glibc ale aj o Qt. Jednoducho sa to da urobit pomocou schroot a debootstrap.

[alfonz]

Párkrát jsem toto "uspesne" vyresil v LXC a starsi verzi systemu např. ubuntu 16.04 a v nem kompilace. Bohuzel to nefunguje vzdy a je to hodne problematicke. Popravde vubec nevim jak toto dobre resit, ale pry appimage by mohlo byt realne reseni.

[alfonz]

Ještě bych doplnil, že už jsem i viděl docker image nebo i LXC image s gui, takto připravený. Vyžaduje to však docker/lxc.

[Odin1918]

Maz nekolik moznosti: otrocky staticky linkovat vsechny knihovny, knihovny pribalit k aplikaci a zajistit jejich loadnuti. Ale je s tim trapeni. Ja to u jednoho projektu resil jednoduse: do virtualbox nainstalovat potrebne distro, nastavit ssh, zvenku skriptik, ktery se pripojil, zajistil build a nasledne odeslal hotovy vyrobek, kam bylo treba. Cesta s virtualem se mi zdala tehdy nejmene pracna, ale urcite profici v dnesni dobe maji nejake lepsi reseni postavene na dockeru, chrootu nebo tak.

[Tom K]

Místo virtuálu používám systemd-nspawn (machinectl), který narozdíl od virtuálu spotřebuje minimum paměti, prostoru na disku a dá se do něj bindnout adresář se zdrojákama. Takže skript přes ssh jen buildne a pak se přes rsync získá výsledek. Na ubuntu 21.10 mám takhle centos7, ubuntu-20.04 a ubuntu 18.04. Je to trocha práce navíc, ale potom už je to celkem bez práce.