Centos7: 10 ősember közül 9 ajánlja

Annyit mondtam neki, hogy nm --with-symbol-versions -D /usr/local/lib64/libstdc++.so de ez is túl megterhelő volt neki.

$ rpm -qa | grep binutils
binutils-2.27-43.base.el7_8.1.x86_64

Még abban bízom, hogy sikerül forrásból telepíteni újabbat. (Off: Nemrég fordult egy gcc-10.2, hátha ez még könnyebb is lesz.)

( _ventura_ v | 2021. 01. 01., p – 08:13 )

Ezt sose értettem, miért kell olyan oprendszerrel szarakodni, amit nem arra terveztek, hogy a legujabb csilli villi szarsagot futassa ? Futassa ?

Tegyél alá Fedora 33 szervert, abban forgatás nélkül lesz 10.2.1 es gcc meg 2.35-ös binutils.

Fedora 42, Thinkpad x280

Tehát egy gányláda, ami eredetileg CentOS7 volt, de ha most force-olva felmenne rá egy yum update, akkor jó esély lenne rá, hogy maga alá fordulna...
A forrásból telepítés értelmes dev környezetben _nem_ opció, ugyanis az, ami ott készül, annak prod környezetben is mennie kell, és prod-ban - legalábbis jobb helyeken - a targézé forrásból felgányolás elég régóta nem elfogadott.

ez igaz, de ezt most is csinalja, csak kezzel haxolja fel a cuccokat. viszont a docker/lxc megoldassal teljesiti azt a (balfasz) ceges policyt hogy csak centos7 lehet a "host" gepen, a lomok meg megkapjak amit igenylenek.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Valami hasonló van, csak fordítva: az üzemeltetésre átadott termékek Docker-image-ek, szóval annak nem sokat árt, hogy én frissítettem a gcc-t meg a binutils-t a devserveren. (Vagy ki tudja. Kis szerencsével előfordulhat, hogy a libgcc_s nem kompatibilis, vagyis azt is bele kell tenni. Majd blogolok, ha esetleg sikerül valami.)

Autoupdate-jellegű megoldás van, csak ahogy legutóbb épp Ubuntu-n sikerült tapasztalni, lehetnek khm. mellékhatásai... (Java update ment le autoupdate-tel, aztán egy wildfly-on futó app elég furcsán kezdett viselkedni...).

Az, hogy a verziószám micsoda például egy emcéeditnél, az egy dolog - a kérdés az, hogy az adott fix visszaportolásra került-e a RHEL/CentOS verzióba? Ha nem, akkor jelezted-e arrafelé a problémát?

Rosszul állsz hozzá és nem a megfelelő összefüggést akarod megérteni.

  1. Vegyünk egy oprendszert, ami kellően ismert és stabil ahhoz, hogy érdemes legyen használni, mindenféle részletesebb körültekintés nélkül.
  2. Használjuk egy darabig, majd fussunk bele egy problémába, amire a stackoverflow- és serverfault-mérnökurak már találtak megoldást a legújabb rolling release és/vagy 1 évig támogatott csilidisztrójukon, 64 GB RAM, 1 TB SSD, 12. gen. CPU mögül pötyörészve.
  3. Próbáljuk ki a javasolt megoldást és szembesüljünk vele, hogy nem működik, mert túl régi™ hozzá a kernel, az egyik csomag, vagy úgy önmagában a rendszer.
  4. A régit feleltessük meg gondolatban elavultnak, az elavultat legacynak, a legacyt a számítástechnika hőskorából származónak, a hőskorit őskorinak, az őskorit őskövületnek. Az azt sikerrel használókat pedig értelemszerűen ősembereknek.
  5. Kényszeresen ignoráljuk a tényt, hogy az újabbnál újabb fejlesztések, kerékújrafeltalálások az emberi tényező tökéletlensége miatt folyamatos új, addig ismeretlen hibákat hoznak be a rendszerbe, aminek a stabilitás, a kiszámíthatóság és (megfelelő preventív védelem hiányában) a biztonság előbb-utóbb áldozatul esnek.

Azt hiszem, ez a legegyszerűbb gondolatmenet annak megértésére, egyesek miért várják a stabil, LTS disztribúcióktól, hogy minden elmúlt évi kényelmi idealizmust is tudjanak és írják le őket a felhasználóközönségükkel együtt, ha mindent azonnal akaró egójuk nem lel kielégülésre.

( NevemTeve | 2021. 07. 23., p – 12:43 )

Azért ez sem nagy dicsőség:

Centors$ file -v
file-5.11
magic file from /etc/magic:/usr/share/misc/magic
AIX5$ file -v
file-5.38
magic file from /usr/local/share/misc/magic

Ad 1. Régi a CentOS-od.
Ad 2. A verziószámok CentOS/RHEL esetén azt az upstream verziót mutatják, ami az alap az adott csomaghoz, de a backportolt javításokról/módosításokról nem adnak információt. Kvázi lehet olyan, hogy az upstream adott főverziójában wontfix-szel lezárt, és a későbbi főverzióban kikalapált probléma a CentOS/RHEL esetében ki lett javítva, pont azért, mert backportolnak nagyon sok javítást.

Mindegy, némi vigaszt jelent, hogy az autoconf/automake is túl régi ahhoz, hogy a file-5.40-et forrásból telepítsem.

$ autoconf -V
autoconf (GNU Autoconf) 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
$ automake --version
automake (GNU automake) 1.13.4

Ha forrásból akarsz mindenhol minden áron a legfrissebb dolgokat buildelni, akkor _nem_ a CentOS, és nem az AIX a megfelelő OS neked. Ennyi. De buildelhetsz komplett toolchain-t, mindent _is_, ami kell ahhoz, hogy e-pélót lengethess azzal a felkiáltással, hogy nálad aztán minden _is_ a legfrissebb... És? Aki verzószám-fétisben szenved, az használjon lfs-t, gentoo-t, vagy hasonló motyót...

Mindegy, azért összeállt, ilyet is tud:

$ file -v
file-5.40
magic file from /usr/local/share/misc/magic
$ file libmorena_25.jnilib
libmorena_25.jnilib: Mach-O universal binary with 2 architectures:
[i386:Mach-O i386 dynamically linked shared library,
 flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|NO_REEXPORTED_DYLIBS>]
[x86_64:Mach-O 64-bit x86_64 dynamically linked shared library,
 flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|NO_REEXPORTED_DYLIBS>]