Portál AbcLinuxu, 27. dubna 2024 04:09
15.8.2022 13:44
Max | skóre: 72
| blog: Max_Devaine
.36 ... DT_HASH je 'mandatory' podle SysV ... DT_GNU_HASH není zdokumentovaná, resp. je zdokumentovaná blogem ... Nevidim nikde, že by DT_HASH mělo být deprecated ... To je celé takové poněkud shitty ...
Ale to je bohužel s GNU libc normálka už dekády... Tak hlavně nezapomenout démonizovat statické linkování a různé alternativy k oficiálním distro repozitářům...
Tak hlavně nezapomenout démonizovat statické linkování a různé alternativy k oficiálním distro repozitářům...Tak hlavne si nezapomenout kopnout kdyz Rust dynamicke linkovani ani *neumi*, zatimco glibc si dynamicky/staticky zkompiluju podle potreby. A repozitare/tarball s bugem v glibc nesouvisi uz vubec.
Tak hlavne si nezapomenout kopnout kdyz Rust dynamicke linkovani ani *neumi*Ale umí. Nešiř fake news. Binárky jsou by default nalinkované proti libc dynamicky. C dependence se také často linkují dynamicky. Zkompiluj si hello world na linuxu, a uvidíš, že ti vypadne dynamicky linkovaná binárky. Rustovské knihovny je také možné linkovat dynamicky, ale není to default, protože 1) ABI se relativně často mění a 2) hodně se používají generika, která nenalinkuješ dynamicky z principu. Rust se v tomhle principielně nijak neliší od C++, pouze se prakticky liší v tom, že častěji rozbíjí ABI. U C++ se to ale děje taky a jsou z toho problémy, které se pak řeší různými způsoby - viz třeba c++ devtoolset v RH.
zatimco glibc si dynamicky/staticky zkompiluju podle potrebyTeoreticky sice ano, ale kdykoli jsem zkoušel sestavit statickou glibc + k tomu potřebné knihovny, byl to takový oser, že jsem pokaždé radši sáhl po musllibc.
A repozitare/tarball s bugem v glibc nesouvisi uz vubec.No, souvisí to tím, že je to oficiální "správný" způsob, jak distribuovat software pro linux... A typicky jsou ta pravidla taková, že po tobě budou chtít dynamicky linkovat proti dependencím v repu (ale záleží na distru), jenže pak se to pravidelně rozbíjí (díky bugům/'fíčurám', jako je tato) a stabilitu / zpětnou kompatibilitu nemáš ani v rámci jednoho distra ani u tak základní věci, jako je libc... Prostě, vyžadovat po vendorech softwaru dynamické linkování distro-provided dependencí, ale zároveň mít laxní přístup ke zpětný kompatibilitě těchto knihoven, je naprosto absurdní. Buď budu vyžadovat dynamické linkování, ale pak nesmim lidem rozbíjet software těmahle změnama, anebo si dovolim nekompatibilní změny, ale pak je potřeba podporovat bundlování dependencí (ať už ve formě statického linkování nebo jiné).
Ale umí. Nešiř fake news.
hodně se používají generika, která nenalinkuješ dynamicky z principu.Takze neumi. A ten princip by me skutecne zajimal, kdyz to C++ s templatama zvlada.
No, souvisí to tím, že je to oficiální "správný" způsob, jak distribuovat software pro linux...A kdyz se podivas na alternativni zpusoby distribuce SW, tak je to bida a zmar na Windows, chranena dilna u Applu/Androidu a tarball/snap/flatpak/docker. Z toho mi fakt vychazi repozitare jako s prehledem nejlepsi volba - a nikdo ti nebrani si pridat repo se starou, novejsi nebo staticky linkovanou verzi.
Prostě, vyžadovat po vendorech softwaru dynamické linkování distro-provided dependencí, ale zároveň mít laxní přístup ke zpětný kompatibilitě těchto knihoven, je naprosto absurdní.Souhlas, ale kdo nikdy do produkce nepustil kriticky bug at se prihlasi :)
A ten princip by me skutecne zajimal, kdyz to C++ s templatama zvlada.Přestávám být schopen určit, jestli mě trolluješ. (V tom SO threadu se exportujou 2 konkrétní instanciace generický funkce s konkrétníma typama, ne generická funkce.)
A kdyz se podivas na alternativni zpusoby distribuce SW, tak je to bida a zmar na Windows, chranena dilna u Applu/Androidu a tarball/snap/flatpak/docker. Z toho mi fakt vychazi repozitare jako s prehledem nejlepsi volbaJo, teď jen vymyslet, které z těch X balíčkových systémů a repozitářů jsou ta "nejlepší volba"... inb4 "To je na uživateli, aby si vybral", jo, a takový ekosystém pak podporovat je fakt super. To má takovou diverzitu, že oproti tomu je nejnovější holywoodský woke velkofilm konzervativní monokultura...
V tom SO threadu se exportujou 2 konkrétní instanciace generický funkce s konkrétníma typama, ne generická funkce.Ja v C++ nic noveho nepisu, jen vim ze templaty uz par let existuji - takze dotaz do SO a prvni rozumne vypadajici vysledek.
Jo, teď jen vymyslet, které z těch X balíčkových systémů a repozitářů jsou ta "nejlepší volba"... inb4 "To je na uživateli, aby si vybral", jo, a takový ekosystém pak podporovat je fakt super.Uzivatel dostava funkcni default - jestli si prida custom repozitare (treba Ubuntu+Launchpad meli vybornou integraci) nebo popularni EPEL na CentOSu uz je jeho vec (je naprosto spravne, ze to udelat muze). Maintainerovi staci dodat novou verzi spravcum repa na zacatku cyklu, tech velkych distribuci neni zas tolik a nova verze vychazi jednou za par let. Ale kdyz chces podporovat rolling release jako Arch, tak mas holt vic prace no.
takze dotaz do SO a prvni rozumne vypadajici vysledekProsím tě, ty nepiš raději v ničem. Jak můžou šablony fungovat s dynamickým linkováním, co se má jako v té knihovně volat?
Ja v C++ nic noveho nepisu, jen vim ze templaty uz par let existuji - takze dotaz do SO a prvni rozumne vypadajici vysledek.Ok, takže v sumě, nemáš tušení, o čem mluvíš, jen jsi mi hodil první SO thread, který vypadal, že obsahuje ty správný klíčový slova. No tak hlavně, že máš o problematice generik a linkování v C++ a Rustu jasno :-/ Přitom už ten název templaty by mohl napovědět, v čem je problém...
Maintainerovi staci dodat novou verzi spravcum repa na zacatku cyklu, tech velkych distribuci neni zas tolik a nova verze vychazi jednou za par let. Ale kdyz chces podporovat rolling release jako Arch, tak mas holt vic prace no.Je to přesně naopak - podporovat Arch je mnohem jednodušší, protože v jedné chvíli existuje pouze jedna verze, a všichni uživatelé jsou tedy na jedné lodi (víceméně, samozřejmě pak existují rozdíly v konfiguracích, ale whatever, minimálně ten základ je společný). Navíc Arch má AUR, kde může kdokoli publikovat jakýkoli balíček téměř bez byrokracie, včetně binárních, VCS/nightly a vůbec cokoli, takže nová (třeba nightly) verze může být uživateli dostupná v řádu minut. To se třeba s daňovým přiznáním v EPELu nedá srovnat. Oproti tomu třeba Ubuntu má v této chvíli 5 (slovy pět) maintainovaných verzí, které mezi sebou můžou mít víceméně libovolné rozdíly, klidně ti binárka z jedné nemusí fungovat na druhé, protože v té době frajeři z GNU libc vymysleli nějakou supr změnu. A samozřejmě v každé z nich bude jiná sada knihoven (tzn. nějaká množina bude mít nějaký problém/nekompatibilitu, nějaká množina bude chybět, ...). A celé je to nepredikovatelné, protože nikdy nevíš, co kdo kde vymyslí. Já něříkám, že to nejde, neříkám, že Windows nebo whatever jsou celkově lepší (mají hromadu jiných problémů), jenom to, že podporovat Linux ekosystém je pro 3rd party vývojáře absurdně komlpikované a nepredikovatelné.
No tak hlavně, že máš o problematice generik a linkování v C++ a Rustu jasno :-/Jasna je jedina vec - v C++ to jde, v Rustu ne. Jak si to kompilatory/linker/ABI standard zaridi neni moje starost, byt to urcite je inzenyrsky zajimave tema. Mozna kdybys to prestal okecavat a poucil ctenare proc templaty/generika nenalinkuješ dynamicky z principu?
protože v jedné chvíli existuje pouze jedna verze, a všichni uživatelé jsou tedy na jedné lodi (víceméně, samozřejmě pak existují rozdíly v konfiguracích, ale whatever, minimálně ten základ je společný).Ano, existuje pouze rolling verze, takze kdyz se zmeni API nejake zavislosti, tak musis svuj kod predelat taky. ,,A celé je to nepredikovatelné, protože nikdy nevíš, co kdo kde vymyslí." Ubuntu sice vydava kazdeho pulroku novou verzi, jenze s podporou jen 9 mesicu, coz nevim jestli nekoho bavi porat preinstalovavat/povysovat a resit nove nezname bugy. LTS s petiletou podporou ma prave ten stabilni zaklad ktery je pro vyvoj/support cehokoliv vetsiho potreba.
podporovat Linux ekosystém je pro 3rd party vývojáře absurdně komlpikované a nepredikovatelné.Kdyz chces distribuovat jednu jedinou binarku pro "proste linux", tak to taky jde - viz nativni linuxove hry na Steamu treba. Vzhledem k tomu, ze jsou to vetsinou indie/poloprofi vyvojari, tak "extremni komplikovanost" je vlastne v pohode.
Jasna je jedina vec - v C++ to jde, v Rustu ne.troll detected, nikdo nemůže být takový pablb
Jasna je jedina vec - v C++ to jde, v Rustu ne.Co v C++ jde? Ukázal jsi export dvou explicitních instanciací, což je principielně stejné jako exportovat dvě obyčejné funkce. Ukaž mi, jak v C++ nadefinuješ generickou funkci, zkompiluješ do shared objectu a v programum to použiješ s vlastním typem toho programu, o kterém ta knihovna nemá ani tušení. To jsem zvědav.
Mozna kdybys to prestal okecavat a poucil ctenare proc templaty/generika nenalinkuješ dynamicky z principu?Protože takový je princip na jakém fungují (tj. na úrovni zdrojáků, ne strojového kódu), nevim, na co se ptáš, chceš po mě úvod do šablon v C++? Nedá se to najít někde na webu, abych to nemusel ad-hoc psát?
Ano, existuje pouze rolling verze, takze kdyz se zmeni API nejake zavislosti, tak musis svuj kod predelat taky.To platí pro non-rolling distro úplně stejně, rozdíl je v tom, že v případě rolling distra můžeš na tu starou verzi zapomenout, kdežto v případě non-rolling distra budeš muset udržovat paralelně několik různých řešení a kód s tim musí počítat (ať už infrastrukturní nebo vlastní kód softwaru). Vyhodit ta stará řešení můžeš až když té dané verzi distra skončí podpora / nepoužívají ji uživatelé.
LTS s petiletou podporou ma prave ten stabilni zaklad ktery je pro vyvoj/support cehokoliv vetsiho potreba.Takže jako vývojář si prostě vybereš nějaké LTS a na to cílíš vývoj a podporu? A co všichni ti ostatní, kteří používají jinou LTS verzi nebo úplně jiné distro, ti mají smůlu?
Kdyz chces distribuovat jednu jedinou binarku pro "proste linux", tak to taky jde - viz nativni linuxove hry na Steamu treba. Vzhledem k tomu, ze jsou to vetsinou indie/poloprofi vyvojari, tak "extremni komplikovanost" je vlastne v pohode.Chápu indie/poloprofi vývojářům je prostě potřeba zkomplikovat život...
Co v C++ jde? Ukázal jsi export dvou explicitních instanciací, což je principielně stejné jako exportovat dvě obyčejné funkce. Ukaž mi, jak v C++ nadefinuješ generickou funkci, zkompiluješ do shared objectu a v programum to použiješ s vlastním typem toho programu, o kterém ta knihovna nemá ani tušení. To jsem zvědav.Zpatky na zacatek - argument o nutnosti kompilovat Rust staticky kvuli generikum pouzivas ty, nikoli vyvojari v C++ - ti nemaji se sdilenymi knihovnami problem, at uz je technicke reseni na urovni ABI jakekoli (ja osobne nevim a link na SO se ti, mozna opravnene, nelibi).
To platí pro non-rolling distro úplně stejně, rozdíl je v tom, že v případě rolling distra můžeš na tu starou verzi zapomenout, kdežto v případě non-rolling distra budeš muset udržovat paralelně několik různých řešení a kód s tim musí počítat (ať už infrastrukturní nebo vlastní kód softwaru). Vyhodit ta stará řešení můžeš až když té dané verzi distra skončí podpora / nepoužívají ji uživatelé.V pripade non-rolling muzes na starou verzi zapomenout uplne stejne, jen proste stare verze distribuce dostane tak maximalne sec/bugfix tveho programu. Coz je prave ta vyhoda stability a "nemeni se pod rukama". Navic mas na zpracovani novych zmen cas, nemusis predelavat svuj program okamzite, protoze to okamzite prestane tvym uzivatelum fungovat jen co aktualizuji knihovnu s breaking change.
Takže jako vývojář si prostě vybereš nějaké LTS a na to cílíš vývoj a podporu? A co všichni ti ostatní, kteří používají jinou LTS verzi nebo úplně jiné distro, ti mají smůlu?Presne tak. Ostatnim to pojede pravdepodobne taky, pripadne jim mergnu podporu pro distro X (typicky to budou drobnosti jako chybejici zavislost v deb/rpm, jine jmeno lib*)
Chápu indie/poloprofi vývojářům je prostě potřeba zkomplikovat život...Tos me bohuzel spatne pochopil. Kdyz to zvladnou indie vyvojari, tak to ,,absurdně komlpikované a nepredikovatelné" opravdu neni.
Zpatky na zacatek - argument o nutnosti kompilovat Rust staticky kvuli generikum pouzivas ty, nikoli vyvojari v C++ - ti nemaji se sdilenymi knihovnami problem, at uz je technicke reseni na urovni ABI jakekoli (ja osobne nevim a link na SO se ti, mozna opravnene, nelibi).Predvism ten link co jsi postnul, podporuje kralykovu tvrzeni, ze C++ je na tom se statickym/dynamickym linkovanim stejne jako Rust. Jen to C++ je tady tak dlouho a ma v sobe namixovano tolik jazykovych konstruktu, ze se nikdo nepodivuje, ze pouzivani nekterych z nich se vylucuje.
Presne tak. Ostatnim to pojede pravdepodobne taky, pripadne jim mergnu podporu pro distro X (typicky to budou drobnosti jako chybejici zavislost v deb/rpm, jine jmeno lib*)IMHO LOL. Zkus si napsat neco v QT a supportovat to jen na vsech aktualnich Ubuntich LTS.
Tos me bohuzel spatne pochopil. Kdyz to zvladnou indie vyvojari, tak to ,,absurdně komlpikované a nepredikovatelné" opravdu neni.No zvladnou to staticky slinkovat, ze.
Zpatky na zacatek - argument o nutnosti kompilovat Rust staticky kvuli generikum pouzivas ty, nikoli vyvojari v C++ - ti nemaji se sdilenymi knihovnami problemProblém s dynamickým likováním ne-generického kódu samozřejmě v C++ nemají a úplně stejně to jde i v Rustu, akorát ti nástroje typu
cargo tolik nepomůžou, protože to prostě lidi moc nepoužívají, ale kompilátor jako takový to umí. Ono to dává smysl - Rust přepoužívá ABI infrastrukturu z C++ (ABI konvence, name mangling, EH, dwarf, ...).
Co se týče šablonového kódu, je s tím v C++ stejný problém jako v Rustu. Proč myslíš, že třeba většina boostu je header-only?
at uz je technicke reseni na urovni ABI jakekoliTechnické řešení šablon na úrovni ABI žádné není, protože na úrovni ABI žádné šablony nejsou.
link na SO se ti, mozna opravnene, nelibiTen SO thread je ok, akorát prostě pojednává o něčem jiném. Mrkni se na ten výpis symbolů, který tam uvádí:
nm libexample.so
0000000000000f50 T __Z3MaxIdET_S0_S0_
0000000000000f20 T __Z3MaxIiET_S0_S0_
U dyld_stub_binderdouble Max<double>(double, double)
int Max<int>(int, int)
Max<T>) v symbolech nenajdeš (nedává to smysl).
Dynamicky linkovat šablony/monomorfizovaná generika umí, pokud vím, pouze C#, který při načítání knihovny překompiluje bajtkód. V C++ nebo Rustu by sis asi musel naspat nějaké JITování, abys dosáhl podobného efektu.
V pripade non-rolling muzes na starou verzi zapomenout uplne stejne, jen proste stare verze distribuce dostane tak maximalne sec/bugfix tveho programu.Případně nedostane nic, pokud jsi indie/3rd party... A uživatelé těchto distribucí si budou stěžovat v tvém bugtrackeru (zažil jsem to).
Navic mas na zpracovani novych zmen cas, nemusis predelavat svuj program okamzite, protoze to okamzite prestane tvym uzivatelum fungovat jen co aktualizuji knihovnu s breaking change.Jo, ale opět přijde někdo s nejnovějším non-LTS Ubuntu nebo Archem nebo whatever, že u něj nefunguje tvůj build nebo ani nejde sestavit zdroják, a že to máš rozbitý. Inb4 "no tak si to musí zařídit sám / jeho problém" - ano, jsaně, dá se k tomu tak přistoupit, akorát tím vlastně dokázeš pravdivost premisy (že je pro vývojáře těžké podporovat Linux ekosystém)...
Tos me bohuzel spatne pochopil. Kdyz to zvladnou indie vyvojari, tak to ,,absurdně komlpikované a nepredikovatelné" opravdu neni.No, tak když to dělá problémy Linusovi, tak to asi úplně triviální nebude. Ale jinak jako jo, ty problémy se většinou dají nějak umlátit, když do toho člověk leje dost času a energie... Ale je to pro vývojáře dost nesmyslné utrpení a pravděpodobně to snižuje kvalitu a/nebo dostupnost linux softwaru (čím víc blbostí okolo musíš řešit, tím méně máš energii na vývoj toho SW jako takového).
Jo, ale opět přijde někdo s nejnovějším non-LTS Ubuntu nebo Archem nebo whatever, že u něj nefunguje tvůj build nebo ani nejde sestavit zdroják, a že to máš rozbitý.Heh, to netrvalo dlouho - zprávička - hw vendor se rozhodl podporovat jedno distro, a hned je zlý, protože rozbil "vibrant ecosystem" a vytvořil monokulturu...
This means that when the PinePhone Pro shipped from the factory with Manjaro on the eMMC it will always boot the Manjaro u-Boot, even when booting from a microSD card. We no longer have any control over the bootloader for these devices. ... PINE64 representatives went so far as to say, quote, "people who want [an SPI chip] can just solder one on". This batch of Pinebook Pros has ended up shipping without Tow-Boot flashed.
Případně nedostane nic, pokud jsi indie/3rd party... A uživatelé těchto distribucí si budou stěžovat v tvém bugtrackeru (zažil jsem to).
Jo, ale opět přijde někdo s nejnovějším non-LTS Ubuntu nebo Archem nebo whatever, že u něj nefunguje tvůj build nebo ani nejde sestavit zdroják, a že to máš rozbitý.Pokud v howto rikas ze podporujes distribuci X, tak si uzivatele opravnene stezuji tobe kdyz to nefunguje (ikdyz nekompatibilni zmenu udelal nekdo jiny, shit happens).
Inb4 "no tak si to musí zařídit sám / jeho problém" - ano, jsaně, dá se k tomu tak přistoupit, akorát tím vlastně dokázeš pravdivost premisy (že je pro vývojáře těžké podporovat Linux ekosystém)...A kde se tohle nedeje? Android je jeste rozbitejsi, Windows 10 mely byt "posledni" a podivej se jaky bordel s verzovanim maji, dokonce MS vydal jeste poslednejsi W11. Jedine vyvojarsky stabilni prostredi je snad iOS (a mainframe, ale to je extrem zase na druhou stranu)...
čím víc blbostí okolo musíš řešit, tím méně máš energii na vývoj toho SW jako takovéhoSouhlas v tomhle. Nesouhlas v tom jak se "blbostem okolo" vyhnout. Tobe se zda lepsi rolling, me zamrzly LTS.
Vyborne, dostali jsme se od podezirani z trollingu k technickemu vysvetleni. Treba Rust casem vezmu na milost...Je mi úplně buřt, co si o Rustu, C++ nebo whatever budeš myslet, postačí mi, když nebudeš šířit technicky nepravdivé informace...
A kde se tohle nedeje? Android je jeste rozbitejsi, Windows 10 mely byt "posledni" a podivej se jaky bordel s verzovanim maji, dokonce MS vydal jeste poslednejsi W11.Ano, ale i tak v aktuální chvíli máš 3 podporované major verze: Win 8.1, 10 a 11 (server edice nepočítám, diskuse je o desktopu). Porovnej to s Linuxem, už jen samotné Ubuntu má podporovaných verzí minimálně stejně, spíš více...
Souhlas v tomhle. Nesouhlas v tom jak se "blbostem okolo" vyhnout. Tobe se zda lepsi rolling, me zamrzly LTS.Tak jsem to nemyslel... resp. ano, LTS distra komplikují situaci, protože zvětšují fragmentaci / počet systémů, které se mohou lišit, ale hlavní problém je to, co jsem psal už vejš - relativně časté rozbíjení zpětné kompatiblity a zároveň nepodpora, či dokonce aktivní odpor k bundlování dependencí. Druhý problém je absence automatizace, všechno je strašně ruční proces. Už jen vůbec zjišťovat závislosti různých věcí (obecně v upstreamu, ne na konkrétním distru). Nebo třeba úloha "závisim na libfoo 2.x, na kterých distrech to bude fungovat?" Existuje Repology, což jako super, ale je to 3rd party web appka nějakého Rusa, který to dělá ve volném čase. Oficiálními nástroji to nedáš, protože všechny balíčkovací nástroje jsou distro-specific a dávají distro-version-specific výsledky...
Nějak nevidím vinu na straně glibc. Je to vlastně ještě hloupější situace, než když si autoři out-of-tree ovladačů stěžují, že někdo vylepšuje interní prostředky jádra. Kterákoliv aplikace, která se až příliš aktivně zajímá o to, jak přesně byla spuštěna, si prostě koleduje o problémy. Vždycky bude křehká.
Rozhodli se použít 12 let deprecated datovou strukturu pro lookup symbolů (DT_HASH)Ne, nebyla deprekována [1] a je vyžadovaná System V ABI.
namísto nové (DT_GNU_HASH), která je hned vedle... a je nezdokumentovaná.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.