Computer : Acer AMD Athlon II X2 220 2,7 Gig ram . openSUSE 12.3 Darthmouth 64 bits Linux 3.7.10-1.16 , KDE 4.10.5 Release 1. Grafische kaart : NVidia GeForce 6150 SE nForce 430 openGL 2.1.2 NVidia 304.88
Ik heb vandaag geïnstalleerd RealPlayer van de site : Other versions | RealPlayer. Realplayer11GOLD.rpm is de bestandsnaam. Ik koos bij Linux 686 voor het meest rechtse bestand : English .rpm
Ik heb 't door Apper laten installeren, die laat geen foutmeldingen zien. Yast geeft m keurig weer in Softwarebeheer. Echter, Realplayer start niet op. Ik zie het icoontje wel ca 10 seconden stuiteren.
Het is Architectuur i586, terwijl mijn openSUSE versie 64 bits is. Kan dat ermee te maken hebben ?
Als je wilt zien wat er gebeurt bij het starten van een programma (eventuele foutmeldingen enn zo), moet je het van de CLI doen. Dus
realplayer
of hoe het programma ook genoemd moge wezen.
Het mag geen probleem zijn om 32-bits programmaas op een 64-bits systeem te draaien. Echter, er zijn vaak bijbehorende 32-bits libraries bij nodig. Als het goed is zorgt een RPM er voor dat die geïnstalleerd worden als ze dat niet al zijn. Als ze niet geïnstalleerd kunnen worden dient een foutmelding te volgen. Maar ja, misschien is je RPM niet waterdicht gebouwd.
Overigens kan ik dit niet naspelen. Ik heb Apper niet op mijn systeem. Aan YaST en zypper heb ik genoeg. Ik zou het waarschijnlijk via YaST hebben geïnstalleerd. Als ik mij goed herrinner (maar ik installeer niet zo vaak RPMs van derden) wordt bij “klikken op” een RPM bestand al gevraagd of je dat misschien met yast wilt installeren. Anders is yast -i *.rmp ook te doen. (Ik wil daarmee niet zeggen dat Apper het niet goed heeft gedaan, maar ik weet eigenlijk niets van Apper behalve dat ik het overbodig vind).
Henk ,
foutmelding is :
/opt/real/RealPlayer/realplay.bin: error while loading shared libraries: libgdk-x11-2.0.so.0: cannot open shared object file: No such file or directory
Bestand
./usr/lib64/libgdk-x11-2.0.so.0
bestaat dus wel.
Ik heb path /usr/lib64/ toegevoegd, path /usr/lib64/ komt nu trouwens ook voor in path van root.
Echter foutmelding blijft.
Of had ik geen / moeten schrijven achter /usr/lib64 ?
Inderdaad is kennelijk een 32-bit versie nodig.
Hoezo “dus” 
Ik begrijp niet wat je hiermee bedoelt. Als je iets hebt gedaan toon dat dan door copy/paste vanaf je terminal scherm naar een post en wel tussen CODE tags (de # knop in the gereedschapbalk van de post editor). We kunnen dan zien wat je waar deed.
Het lijkt me beter om dat maar weer ongedaan te maken. Ik zie niet in wat dit (al is het nog zo vaag omschreven) kan bijdragen aan een oplossing.
De oplossing is dat je de 32-bit versie moet installeren.
Zoeken in YaST > Software > Software management op libgdk-x11 (met RPM “levert” aangevinkt) geeft dat het zit in package libgtk-2_0-0 (geïnstalleerd bij mij) en package libgtk-2_0-0-3bit (niet geïnstalleerd bij mij en bij jou waarschijnlijk ook niet). Het lijkt me logisch om dat te installeren.
Henk ,
het laatste gedeelte van de foutmelding is :
No such file or directory
Daarom schreef ik :
Bestand
./usr/lib64/libgdk-x11-2.0.so.0
bestaat dus wel.
De door mij toegevoegde PATH’s zijn na herstart pc automatisch weer verwijderd.
Ik heb op jouw advies libgtk-2_0-0-32 bits versie geïnstalleerd.
Verder moest ik nog libpangox-1.0.so.0 installeren. Ik heb zowel 32 als 64 bits geïnstalleerd.
Maar hij doet het nu.
Bedankt voor je hulp !
Volgens mij is het zo dat “dus” wijst op een conclusie die uit het voorafgaande getrokken kan worden. Uit het gegeven dat de 32-bits er niet is blijkt niet dat de 64-bits er wel is. Dat is een afzonderlijk gegeven. Als je het woord “dus” weglaat, staat er precies wat je hebt geconstateerd. Maar dat doet er allemaal niet zo toe 
Je hebt het nu over PATH, eerst over path. Dat is verwarrend.
En als je daarmee de environment variable PATH bedoeld, die heeft hier niets mee te maken. De directories die in deze PATH variabele staan worden door de shell gebruikt bij het ingeven van een commando zonder voorafgaand path. Bijvoorbeeld:
ls
Er wordt dan van voor naar achter door die rij van directories gezocht of er een bestand ls in staat. En jawel, dan wordt /usr/bin/ls gevonden. En dan wordt dat uitgevoerd. Dat bespaart je dus het weten waar ls staat en het intikken daarvan.
Het heeft dus niets met libraries te maken en je kunt er al helemaal niet mee suggereren dat iets is geïnstalleerd, als dat niet zo is (computers zijn ongevoelig voor suggesties).
Aangezien je niet laat zien wat je met die path/PATH gedaan hebt, kan ik ook geen commentaar geven op de eventuele gevolgen en waarom het nu weer weg is.
In ieder geval leuk dat het nu werkt. Je hebt gelijk iets hebt opgestoken van de systematische aanpak om dit op te lossen. Dat blijkt uit het vinden van de tweede library. Inderdaad moet je dat soms in meer stappen doen. En dan kan je nog altijd op een library stuiten die niet in de repos staat. Daarom is buiten de repos om installeren vaak iets van “proberen maar”. lol!
Aangezien realplayer (brrrr) een 32bit programma is, heb je ook de 32bit libs nodig.
zypper in libgtk-2_0-0-32bit
installeert die voor je. Het kan heel goed zijn, dat je nog meer …-32bit pakketten nodig hebt.
NB. Dit zijn dus x86_64 pakketten, met 32bit libs erin. Na de installatie zul je zien, dat de libgdk … ook in /usr/lib staat.