Problem beim Installieren von WineX

Sound, Digitalkameras, TV+Video und Spiele.
Antworten
Benutzeravatar
the_isz
Beiträge: 101
Registriert: 17.11.2003 16:50:27

Problem beim Installieren von WineX

Beitrag von the_isz » 26.03.2004 16:58:05

Hi Ihr!

Ich hab mir mal die UT2004 Demo unter Linux angeschaut und seitdem hab ich mir gedacht: Zocken unter Linux funktioniert ja vielleicht doch...

Um auch Diablo2 auch zocken zu können (spiel ich halt immer noch am häufigsten) hab ich mir mal WineX gezogen (einmal 3.2 und einmal 3.3).

Das .configure ist auch prima durchgelaufen, aber beim compilieren gabs Probleme. Das eine ließ sich recht einfach durch Installation des flex-old Pakets beheben, das andere leider nicht. Das Compilieren brach mit folgender Fehlermeldung ab:

Code: Alles auswählen

make[2]: *** [oaidl_p.o] Fehler 1
make[2]: Leaving directory `/home/rincewind/files/winex/dlls/oleaut32'
make[1]: *** [oleaut32/liboleaut32.so] Fehler 2
make[1]: Leaving directory `/home/rincewind/files/winex/dlls'
make: *** [dlls] Fehler 2
Mein System:

AMD Athlon 2500+
ASUS A7N8X Deluxe 2.0
Sapphire Radeon 9800 Pro
======================
Debian Sid (upgedatet aus Knoppix 3.3)
Kernel 2.6.4
XFree86 Version 4.3.0.1 (X11 6.6)
fglrx Treiber Version 3.7.6

Hab schon zwei Ideen woran's liegen könnte:
  1. Hab gesehen, dass OSS zum Compilieren vorgeschlagen wird, hab aber ALSA in den Kernel compiliert.
  2. Folgendes hab ich aus der README:
    You need to have the X11 development include files installed
    (called xlib6g-dev in Debian and XFree86-devel in RedHat).
    Das Paket xlib6g-dev ist aber ein stable Paket, das aber mit einem anderen Paket in Konflikt steht:

    Code: Alles auswählen

    Die folgenden Pakete haben nichterfüllte Abhängigkeiten:
    xlibs-static-dev: Kollidiert: xlib6g-dev aber 4.1.0-16woody1 soll installiert werden
Kann mir hierbei jemand helfen? Welder google, noch holarse, noch Suchen in diversen Foren konnten mir bei diesem Problem helfen.

Grüße,

Timo

/edit:

Ich hab mal die Ausgabe der configure Prozedur untersucht pack mal die negativen Ergebnisse hierher. Vielleicht kann mir dann ja jemand helfen:

Code: Alles auswählen

checking whether we are cross compiling... no
checking for lclint... no
checking for lint... no
checking for i386_set_ldt in -li386... no
checking for _oss_ioctl in -lossaudio... no
checking for _xpg4_setrunelocale in -lxpg4... no
checking for mmap in -lmmap... no
checking for openpty... no
checking for dlopen... no
checking Checking if the sdldrv should be built... no
checking for sane-config... no
checking freetype/ftnames.h usability... no
checking freetype/ftnames.h presence... no
checking for freetype/ftnames.h... no
checking for gcc strength-reduce bug... no
checking whether .type must sit inside a .def directive... no
checking whether external symbols need an underscore prefix... no
checking whether stdcall symbols need to be decorated... no
checking for the errno variable name on this platform: __error... no
checking for the errno variable name on this platform: ___errno... no
checking for the errno variable name on this platform: __thr_errno... no
checking for the errno variable name on this platform: __errno... no
checking for _lwp_create... no
checking for _pclose... no
checking for _popen... no
checking for _stricmp... no
checking for _strnicmp... no
checking for chsize... no
checking for fpclass... no
checking for rfork... no
checking direct.h usability... no
checking direct.h presence... no
checking for direct.h... no
checking ieeefp.h usability... no
checking ieeefp.h presence... no
checking for ieeefp.h... no
checking io.h usability... no
checking io.h presence... no
checking for io.h... no
checking libutil.h usability... no
checking libutil.h presence... no
checking for libutil.h... no
checking linux/ucdrom.h usability... no
checking linux/ucdrom.h presence... no
checking for linux/ucdrom.h... no
checking socket.h usability... no
checking socket.h presence... no
checking for socket.h... no
checking sys/cdio.h usability... no
checking sys/cdio.h presence... no
checking for sys/cdio.h... no
checking sys/filio.h usability... no
checking sys/filio.h presence... no
checking for sys/filio.h... no
checking sys/link.h usability... no
checking sys/link.h presence... no
checking for sys/link.h... no
checking sys/lwp.h usability... no
checking sys/lwp.h presence... no
checking for sys/lwp.h... no
checking sys/modem.h usability... no
checking sys/modem.h presence... no
checking for sys/modem.h... no
checking sys/sockio.h usability... no
checking sys/sockio.h presence... no
checking for sys/sockio.h... no
checking sys/strtio.h usability... no
checking sys/strtio.h presence... no
checking for sys/strtio.h... no
checking sys/v86.h usability... no
checking sys/v86.h presence... no
checking for sys/v86.h... no
checking sys/v86intr.h usability... no
checking sys/v86intr.h presence... no
checking for sys/v86intr.h... no
checking whether stat file-mode macros are broken... no
checking for gcc option to accept ANSI C... none needed
checking whether sys/mount.h defines statfs... no
checking for msg_accrights in struct msghdr... no
checking for sa_len in struct sockaddr... no
checking for sun_len in struct sockaddr_un... no
checking whether we need to define __i386__... no
Fällt jemandem hier etwas Schlimmes auf?

LittleBoy
Beiträge: 718
Registriert: 30.04.2002 14:32:26

Beitrag von LittleBoy » 27.03.2004 10:11:55

Wenn bei einer Kompilation das ganze abbricht, muss man nach der Fehlermeldung der Ursache suchen - du hast leider nur die make-Fehler hingeschrieben. DIe sagen aber nichts über den Fehler aus. IdR sind Fehlermeldungen, wo eckige Klammern vorstehen unwichtig.

woody kommt afaik mit XFree 4.1 - du hast XFree 4.3 drauf, also ein Backport. Damit hast du eine sehr hohe Chance, dass die Devel-Pakete nicht wirklich kompatibel zum woody System sind. Daher kriegst du die Schwierigkeiten mit den Abhängigkeiten.

Da aber das configure Skript durchgelaufen ist, wird es wohl nicht an den xlibs scheitern. Aber ohne die wirkliche Fehlermeldung lässt sich das nur sehr schwer sagen.

Benutzeravatar
the_isz
Beiträge: 101
Registriert: 17.11.2003 16:50:27

Beitrag von the_isz » 28.03.2004 01:23:01

Hi!

Erstmal sorry, dass ich so lange nicht geantwortet habe, LittleBoy.

Ich hab's mittlerweile hinbekommen. Mit der aktuellsten cvs Version hat's dann funktioniert, wobei ich jedem, der ähnliche Probleme hat, das Script empfehlen kann, das im Howto auf http://www.linux-gamers.net benutzt wird:

http://www.linux-gamers.net/modules/wfs ... rticleid=2

Damit gings eigentlich auf Anhieb. Nicht, dass Diablo2 starten würde, aber immerhin konnte ich es schon einmal installieren. Das ist ja schonmal was :D

Ich vermute, ich muss meinen X Server jetzt erstmal auf eine einigermaßen stabile Version bekommen, denn die unstable Version, die ich im Moment benutze, kackt jedes Mal ab, wenn das D2 Setup die Grafikmodi testen will.

Auf jeden Fall danke für Deine Bemühungen LittleBoy!

Greetz,

Timo

nemesis23
Beiträge: 1
Registriert: 12.04.2004 23:26:26

Beitrag von nemesis23 » 12.04.2004 23:46:33

hallo the_isz,

ich habe, bzw, hatte das problem mit der oaidl_p.c seit 2 tagen. da du bei deinem ersten posting nichts ausser den make fehlermeldungen zu sehen war, gehe ich davon aus, dass es sich bei dir auch um einen, fuer deinen compiler unuebersetzbaren, sourcecode gehandelt hat. falls dem so ist, kann dir geholfen werden. bei transgaming findest in dem/der aktuellen cvs repository eine version 1.2 der oaidl_p.c. ich habe mir jene einfach mal gezogen und mit meiner ausgetauscht. siehe da, der fehler wart nicht mehr gesehen. anbei der link zur version 1.2 damit du nicht solangel suchen musst =)
http://cvs.transgaming.org/cgi-bin/view ... .c?rev=1.2

gruesse

nemesis23

Antworten