GLIBCXX 3.4.15

[Tool]

Imam server, Centos 6.6.

Na njemu trebam upogonit program koji prilikom pokretanja javlja:

/usr/lib64/libstdc++.so.6: version 'GLIBCXX_3.4.15' not found

Nakon malo istrazivanja, ispada da greska izvire iz gcc verzije, koji je na 4.4. Minimalno mora biti 4.6.

Prva pomisao mi je bila da se gcc moze upgradeati na visu verziju, no ubrzo sam skuzio da to tak ne ide. Gcc verzija je usko vezana uz OS, nema smisla dizati mu verziju posto bi se narusio integritet OS-a.

Tad mi je sinulo da bude to bio teski hakeraj za sloziti:

cd $HOME
wget ftp://gd.tuwien.ac.at/gnu/gcc/releases/gcc-4.6.2/gcc-4.6.2.tar.gz
tar xzf gcc-4.6.2.tar.gz
cd gcc-4.6.2
./contrib/download_prerequisites
cd ..
mkdir objdir
cd objdir
$PWD/../gcc-4.6.2/configure --prefix=$HOME/gcc-4.6.2 --enable-languages=c,c++,fortran,go
make
make install

Dakle, potrebno je skinuti i buildati gcc 4.6, odvojeno na istom serveru uz 4.4.

Zatim je potrebno skopirati libstdc++.so.6.0.16 iz skinutog gcc-a, i staviti ga u /usr/lib64, i promijeniti symlink da pokazuje na novu verziju (prije je bila niza).

S ovim je narusen integritet OS-a, no s druge strane, program je proradio. Pa je moje pitanje: da li je moguce rijesiti ovo na drugi nacin, koji ne narusava integritet sistema? Da li je apsolutno potrebno promijeniti server?

Jedna alternativa koju vidim je da nabavim source izvrsnog programa, i buildam ga uz dinamicko linkanje biblioteka iz novog gcc 4.6. No jednostavnije mi zvuci promijeniti server.

Konkretno, radi se o ovom programu: http://ifcopenshell.org/ifcconvert.html ukoliko netko zeli replicirati. Jednostavni executable file koji pretvara .ifc datoteke u zeljeni format.

[z3r01]

Tool kaže:

Imam server, Centos 6.6.

Na njemu trebam upogonit program koji prilikom pokretanja javlja:

/usr/lib64/libstdc++.so.6: version 'GLIBCXX_3.4.15' not found

Nakon malo istrazivanja, ispada da greska izvire iz gcc verzije, koji je na 4.4. Minimalno mora biti 4.6.
...

https://gcc.gnu.org/faq.html#multiple

http://www.tellurian.com.au/whitepapers/multiplegcc.php

[Florest Glimp]

Na RHEL sustavima za to postoje tzv. "Software collections". Tako i na CentOS-u ima službeni repo:

[root@centos6 ~]yum install centos-release-scl

Ono što tražiš je:

[root@centos6 ~]# yum search gcc | grep 'toolset-.-gcc\.'
devtoolset-3-gcc.x86_64 : GCC version 4.9
devtoolset-4-gcc.x86_64 : GCC version 5
devtoolset-6-gcc.x86_64 : GCC version 6

Moraš prvo omogućiti centos extras repo, ako nije omogućen. Ovdje imaš upute što i kako:

https://wiki.centos.org/AdditionalRe...positories/SCL
https://access.redhat.com/documentat...e-collections/

[Florest Glimp]

[root@centos6 ~]# yum install scl-utils devtoolset-3-gcc
[root@centos6 ~]# scl -l
devtoolset-3
[root@centos6 ~]# scl enable devtoolset-3 bash
[root@centos6 ~]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-3/root/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/opt/rh/devtoolset-3/root/usr --mandir=/opt/rh/devtoolset-3/root/usr/share/man --infodir=/opt/rh/devtoolset-3/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-languages=c,c++,fortran,lto --enable-plugin --with-linker-hash-style=gnu --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/cloog-install --with-mpc=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/mpc-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)

Malo hakeraja, više vremena za "kissing the girl"...

[Florest Glimp]

Probao sam konkretno. Da vidim o čemu se tu priča zapravo...

[root@centos6 ~]# ./IfcConvert 
./IfcConvert: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by ./IfcConvert)
[root@centos6 ~]# strings /usr/lib64/libstdc++.so.6 | grep GLIBC
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBC_2.2.5
GLIBC_2.3
GLIBC_2.4
GLIBC_2.3.2
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH

Pa to je neki binary. Ja mislio da se priča o kompajliranju iz source-a kad veliš gcc, pa gcc. Ako je i problem sa gcc-om onda nije s verzijom na CentOS-u već onom na stroju developera i možda načinom na koji je on to složio. Ako baš aplikacija traži novu verziju libstdc++ - nikako nije rješenje kopirati drugu verziju u /usr/lib64. To je pucanje sebi u nogu prije trke - mala je vjerojatnost da se nešto neće zeznut. Probaj kompajlirati s najnovijim developer toolsetom, ali tako (ako ne prođe bez) da stdc++ i sve potrebno metneš u:

/opt/rh/devtoolset-3/root/usr/lib64/

Vidi i dodatne pakete u developer toolsetu devtoolset-3-gcc-c++ i devtoolset-3-libstdc++-devel, metapaket se zove devtoolset-3-toolchain. Ako toj aplikaciji baš treba novi libstdc++, onda ga treba s zavisnostima spakirati s aplikacijom, a ne gaziti sistemski.

[Florest Glimp]

Bolja ideja - ako je to samo neka komandnolinijska aplikacija, a koliko vidim -je, a radi na CentOS 7 ili bilo kojoj drugoj distribuciji, zašto ju ne bi pokretao kroz Docker? Npr. ja sam to radio s novim GDAL stvarima na CentOS 6:

http://blog.klokantech.com/2015/02/g...th-single.html

Princip je isti... Npr, ja bih napravio skriptu i postavio alias za alat koji mi treba koja puca na tu skriptu. Sa getopts pokupim sve parametre koje komanda iz kontejnera traži, a onda ih u skripti prilagodim za "docker run".

[Annatar]

Tool kaže:

Imam server, Centos 6.6.

Na njemu trebam upogonit program koji prilikom pokretanja javlja:

/usr/lib64/libstdc++.so.6: version 'GLIBCXX_3.4.15' not found

Nakon malo istrazivanja, ispada da greska izvire iz gcc verzije, koji je na 4.4. Minimalno mora biti 4.6.

Nije do GCC-a, nego do libstdc++ biblioteke. /usr/lib64/libstdc++.so.6 je prestar.

Dakle, potrebno je skinuti i buildati gcc 4.6, odvojeno na istom serveru uz 4.4.

Da, ali ne mora biti gcc 4.6, nego moze biti i najnovija verzija, sve dotle, dok generirani kod odnosno aplikacija nema neku regresiju, bilo u performansama, bilo u necem drugome.

Zatim je potrebno skopirati libstdc++.so.6.0.16 iz skinutog gcc-a, i staviti ga u /usr/lib64, i promijeniti symlink da pokazuje na novu verziju (prije je bila niza).

NE!!! NIKADA!!! NIKADA!!!!!

GNU C i C++ biblioteke ne garantiraju apsolutno ikakvu kompatibilnost niti API, kako unaprijed a tako ni unazad. Nije ti ovo UNIX, to je GNU, kauboji i Indijanci!

S ovim je narusen integritet OS-a, no s druge strane, program je proradio. Pa je moje pitanje: da li je moguce rijesiti ovo na drugi nacin, koji ne narusava integritet sistema? Da li je apsolutno potrebno promijeniti server?

Da, moguce je to rijesiti i to tako da bude 100% cisto. Ja sam to izveo na prastarom RHEL-u 5.8, gdje je compiler bio GCC 4.4, a ja sam uz pomoc njega izgradio GCC 5.3.0 (samo C i C++ u prvom prolazu), odnosno napisao sam vlastiti RPM .spec file za isti i pronasao sam tocan redosljed opcija, te korektne opcije dok to nije proradilo.

Taj sam gcc i g++ modificirao tako da je uz /usr/lib te /usr/lib64 jos i automatski trazio header datoteke te biblioteke u /opt/antr/include te /opt/antr/lib, odnosno /opt/antr/lib64.

Uz to sam jos i modificirao ta dva compilera da u svaki generirani ELF kod dodaju $ORIGIN:$ORIGIN/../lib64 RPATH slot za 64-bitni, odnosno $ORIGIN:$ORIGIN/../lib RPATH slot za 32-bitni generirani kod.

Nakon toga sam uz pomoc tog compilera ponovno izkompilirao sve njegove biblioteke (libisl, libgmp, libz i tako dalje), te njega samog, plus jos gfortran.

Zatim sam sve jos jednom rekompilirao s tim novim compilerima.

Tako sam se oslobodio sistemskog GCC-a. Nakon toga sam mogao normalno kompilirati s GCC 5.3.0 compilerom na RHEL-u 5.8. Naravno, prije izgradnje svega toga, morao sam kompilirati i pripadajuce binutils, jer one uvijek idu u tandemu s GCC compilerom. Njih sam isto modificirao za "multilib" (32- i 64-bit as te ld, te podrska za dodatne arhitekture i platforme), rekompilirao s novim compilerom, te nakon toga opet rekompilirao compilere.

Sve u svemu, binutils, pripadajuce shared object biblioteke, te same compilere sam morao kompilirati najmanje tri puta kako bi se potpuno oslobodio sistemskog compilera, sistemskih binutils te sistemskih biblioteka koje GCC treba.

Ako ti jos uvijek treba, mogu ovdje postati moje .spec datoteke za automatsku izgradnju RPM paketa.

Isto tako morat ces generirati zasebni paket za samo libc i libstdc++ - takozvani "GCC runtime" paket, da aplikacije kompilirane s tvojim compilerom ne moraju instalirati compilere samo da bi se mogle pokrenuti.

Uglavnom, bio je to pravi pravcati inzinjerski izazov, jer je GCC 4.4 prestar za kompilaciju GCC 5.3.0, te jer sam ja izricito htio da mi gcc i g++ po defaultu generiraju 32-bitni kod, cak i kada sam na 64-bitnoj platformi, kako bi se ponasali isto kao sto se ponasaju na Solarisu ili pak na Linuxima koji se vrte na RISC (citaj: PPC) platformama opcenito. Bilo je to poduze natezanje dok nisam uspio naci carobni redosljed tocno odredjenih opcija, jer GCC bootstrap na GNU/Linuxu to smatra "cross kompilacijom" ako si na 64-bitnoj platformi, dok na UNIX operativnim sustavima po defaultu generira "multilib" 32-/64-bitne compilere bez ikakvih problema ili natezanja. A ja pristup 32-bitnoj platformi nisam imao, jer su sistem inzinjeri bili nesposobni, a nisam si smio sam sloziti 32-bitni RHEL 5.8.

Cijela akcija je bila vise-manje jednaka jailbreak-u, jer je idiotsko-kretenski redhat eksplicitno kastrirao sistemski GCC compiler da moze generirati samo 64-bitni kod (jos jedan argument zasto ne koristiti redhatove izbljuvke).