Das Forum wurde aktualisiert. Wurde höchste Zeit. Wenn etwas nicht funktioniert, bitte gerne hier jederzeit melden.
(Das "alte Design" kommt wieder, wird ne Weile brauchen!)

[erledigt] FedoraNightlyBuild vmware-tools vs. open-vm-tools

Hilfe bei Problemen mit der Installation und Benutzung des VMware Player.

Moderatoren: irix, stefan.becker, continuum, Dayworker, Tschoergez

Member
Beiträge: 138
Registriert: 06.06.2006, 08:12

[erledigt] FedoraNightlyBuild vmware-tools vs. open-vm-tools

Beitragvon ManfredB » 17.10.2011, 10:37

Hallo zusammen,

ich habe Fedora 16 (als NightlyBuild vom 16.10.2011 im VMplayer laufen.

Soweit so gut: Da Fedora standardmässig den VMware-Grafik-Treiber mitbringt, ist es kein Problem, im Fullscreen (bei mir 1440x900" zu arbeiten.

Doch nun möchte ich meine SharedFolders einbinden, was ja nur mit vmhgfs funktioniert, was die VMware-Tools benötigt.
Diese lassen sich zwar compilieren, doch hgfs lässt sich nicht nutzen,
da spielt der Kernel verrückt.
Vor allem wird da eine neue initrd generiert, die dazu führt, dass nachher dauernd Fehlermeldungen erscheinen.

Nun wollte ich die open-vm-tools nutzen, doch da ist bereits bei
./configure
das Ende schnell da.
Siehe hier:

Code: Alles auswählen

checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking how to run the C++ preprocessor... g++ -E
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... no
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for pkg-config... yes
checking for X... no
checking libintl.h usability... yes
checking libintl.h presence... yes
checking for libintl.h... yes
checking for glib-2.0 >= 2.6.0 (via pkg-config)... no
configure: error: glib >= 2.6.0 is required.


glib-2.0 >=2.60 ist irgendwie falsch,
denn glib gibt es nur bis 2.30.1

Was kann ich da anstellen?
Oder muss ich es gleich vergessen?

Danke im voraus für Hinweise.

Gruss
Manfred

Benutzeravatar
King of the Hill
Beiträge: 12009
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 19.10.2011, 03:06

checking for glib-2.0 >= 2.6.0 (via pkg-config)... no
configure: error: glib >= 2.6.0 is required.
Naja, 2.6.0 ist nicht nur bei mir unterhalb deiner erwähnten Version 2.30.1 ;)

Wie schon öfter hier gesagt, sind neueste Kernelergüsse immer mit Vorsicht zu geniessen. VMware patcht seine SW nicht jedem Kernel hinterher und daher bist du dann immer wieder an einen zur jeweiligen Kernelversion passenden Patch der Linux-Community angewiesen. Du hast hier also wieder mit dem üblichen Linuxproblem auf neuer HW zu kämpfen, nur das diesmal die Hardware in einer VMware-VM feststeht und SW noch nicht an eine neue Kernelversion angepaßt wurde.
Wenn du häufiger Nightly-Builds einsetzen willst, solltest du vielleicht auch eher eine VT-Lösung einsetzen, die von den Kernelhackern mitgepflegt wird. Andernfalls wirst du immer wieder auf solche Probleme stossen.

Die Open-Tools haben direkt auch nichts mit den VMware-Tools zu tun. Die Open-Tools werden entweder durch die jeweilige Distri oder die Kernelhacker im Zuge der Kernel-EW gepflegt. Wenn also selbst die mitgelieferten Open-Tools nicht funktionieren, werden die älteren VMware-Tools mit deiner Kernelversion erst recht nichts anfangen können.
Was sagt den Fedora dazu?

Member
Beiträge: 138
Registriert: 06.06.2006, 08:12

Beitragvon ManfredB » 19.10.2011, 07:57

Danke für diese Erklärung.

Interessanterweise ist gentoo mit seinem kernel-3.0.6-gentoo in dieser Hinsicht ohne Probleme mit den VMware-Tools umgegangen.

Dort sind sogar die SharedFolders zu mounten, was die Sache wesentlich vereinfacht.

In anderen Fällen habe ich die benötigten Programme-Einstellungen auf einem USB-Stick, der sich in allen DIstros mounten lässt.

So kann ich zB die Einstellungen von gkrellm und mozilla kopieren und dann nutzen.

Gruss
Manfred


Zurück zu „VMware Player“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste