Portál AbcLinuxu, 30. dubna 2025 11:26
Môžete to považovať za variantu masochizmu, ale kompilujem si sám veci, ktoré priamo neponúka moje distro - Slackware. Tento zápis, je o tom, kam ma táto úchylka priviedla pri VirtualBox-e 4.0.0.
Pozn.: zápis nie je pre slabšie povahy, ktorým sa robí nevoľno pri slove "linker", "jadro" či "fatal error". Pred nedávnom Slackware - zaradil KDE 4.5.4. Tak som sa pustil upgradovať. Nielen KDE, ale takmer všetko. Všetko klapalo, ale to mi nestačilo. Tak som si povedal, že upgradnem aj jadro. Veď 2.6.36 mala byť zlepšená odozva na desktope. Používam vanila a upgrade prebehol hladko, až na to, že prirodzene prestal fungovať VirtualBox pretože jeho jadrový modul nebol správne nainštalovaný. Presnejšie - pri inštalácii VirtualBox-u sa vyrobí modul s menom vboxdrv a ten sa musí umiestniť niekam pod /lib/modules/`uname -r`. No a pretože `uname -r` sa zmenilo, tak modul sa nenahral. Maličkosť, modul treba prekompilovať, dať do správneho adresára a nahrať. Ale doteraz som bežal VirtualBox-3.1.6 a ten sa mi odmietol prekompilovať, pretožeChecking for gcc:To bude dôsledok toho, že som pri KDE upgradol aj gcc. Hovorím si nevadí, veď nedávno vyšiel VirtualBox 4.0.0. Uvidíme, čo s tým Oracle urobil. (VirtualBox-3.2.0 som preskočil, lebo mal vraj nejaký nepríjemný bug). No a 4.0.0 ma trocha potrápila. Prvý problém je, že Slackware nemá PAM. Následkom toho zlyhá buildovanie VBoxAuth:
** gcc version 4.5.1 found, expected gcc 3.x with x>1 or gcc 4.x with 0<x<4!
kBuild: Compiling VBoxAuth - .../src/VBox/HostServices/auth/pam/VBoxAuthPAM.cV predchádzajúcich verziách niečo také nebolo, tak som dúfal, že to nebude kritická vec (myslím, že je to dobré na podporu Linux-ových guestov). Podarilo sam mi to obísť zakomentovaním riadku
.../src/VBox/HostServices/auth/pam/VBoxAuthPAM.c:77:31: fatal error: security/pam_appl.h: No such file or directory
include $(PATH_SUB_CURRENT)/auth/Makefile.kmkv súbore
src/VBox/HostServices/Makefile.kmk
Ďalší zádrhel bol pri buildovaní manuálu. Neviem celkom prečo
kBuild: pdflatex /archive/build/virtualbox/VirtualBox-4.0.0_OSE/out/linux.x86/release/obj/manual/en_US/UserManual.tex (three passes) -> /archive/build/virtualbox/VirtualBox-4.0.0_OSE/out/linux.x86/release/obj/manual/en_US/UserManual.pdf
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
kmk: [.../out/linux.x86/release/obj/manual/en_US/UserManual.pdf] Error 1 (ignored)
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
kmk: [.../out/linux.x86/release/obj/manual/en_US/UserManual.pdf] Error 1 (ignored)
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
kmk: [.../out/linux.x86/release/obj/manual/en_US/UserManual.pdf] Error 1 (ignored)
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
kmk: [.../out/linux.x86/release/obj/manual/en_US/UserManual.pdf] Error 1 (ignored)
kmk_builtin_cp: .../out/linux.x86/release/obj/manual/en_US/UserManual.pdf: No such file or directory
Ale keďže manuál je na webe, tak som to viac neriešil a jednoducho použil --disable-docs.
Po týchto trampotách som nakoniec úspešne dokompiloval a dostal výsledné subory v out/linux.x86/release/bin. Odtiaľ ich zvyknem kopírovať do /usr/local/VirtualBox. To som spravil aj teraz. Ale ukázalo sa, že ešte nie je čas na prípitok.
/usr/local/VirtualBox/VirtualBox VirtualBox: supR3HardenedMainGetTrustedMain: dlopen("/usr/local/VirtualBox/VirtualBox.so",) failed: VBoxVMM.so: cannot open shared object file: No such file or directorySamozrejme VBoxVMM.so existuje a je v rovnakom adresári ako VirtualBox.so. VirtualBox ale v snahe zvyšovať bezpečnosť robí niečo kvôli čomu loaduje svoje knižnice bez ohľadu na konfiguráciu dynamického loadera. A keďže jeho "exáče" majú set-uid-root flag, tak nezafunguje ani LD_LIBRARY_PATH. Vytrvalé pátranie ma priviedlo na údajný fix - program chrpath. Nadobudol som pocit, že je to vec napísaná reverzným inžinierstvom a meni niečo čo sa volá "rpath" v skompilovaných súboroch. Teraz nastáva ten moment, kedy moje ma úsilie priviedlo na ďalší zaujímavý čriepok vedomostí, o ktorom som doteraz nevedel - rpath. Ja viem. Taký starý linuxák, ako ja, to mohol vedieť: každý súbor v ELF môže v sebe niesť informáciu o tom, kde hľadať dynamické knižnice. Túto informáciu do neho môže vložiť linker pomocou prepínača
-rpath
. A skutočne v zdrojákoch VirtualBox-u mi grep pomohol nájsť veci ako:
./out/linux.x86/release/obj/scm/scm.dep:@g++ '-Wl,-rpath,/opt/VirtualBox'
...
Po presunutí súborov z /usr/local/VirtualBox do /opt/VirtualBox sa to celé rozbehlo. Až budem mať zas niekedy záchvat, tak to prekompilujem tak, aby to išlo do /usr/local/VirtualBox, tak ako som to pôvodne chcel. Môžeme nalievať
Šťastné a veselé.
P.S. To bol môj príspevok, aby v blogoch na abíčku bolo aj niečo iné než Kernel ultras a Jílek.
Tiskni
Sdílej:
Slackpkg
, utilita pro (re)instalaci/aktualizaci balíků z oficiálních repozitářů, takže už se nemusíš stahovat ručně stahovat a (re)instalovat/aktualizovat balíky (stačí #slackpkg upgrade-all). Pokud vím, tak přechod mezi verzemi zatím neumí, ale aktualizaci distra stejně vždycky dělám ručně.
Když něco není v repozitářích, je velká šance, že to najdeš na Slackbuild.org (v podstatě totéž co pkgbuildy v Arch Linuxu). Abys nemusel stahovat a kompilovat každý SlackBuild ručně, naštěstí existuje sbopkg
(totéž co slackpg
). Takže co se týče manipulace s balíky po síti, je na tom Slackware dobře.
A nevím jak se chovají nejnovější ovladače od Nvidie, ale ty staré (nvidia-legacy) jsem zkompiloval přesně podle instrukcí od Nvidie a fungovaly hned*.
* Bylo tam pár drobností typu: když v Xorg.conf nemáš nastavenou default color depth (nebo něco takového), Xka zhavarovaly, ale tohle bylo na Slackware 12.2 s Xorg 1.4.x, tak to snad už (na obou stranách) opravili
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.