http://bugs.winehq.org/show_bug.cgi?id=7711
--- Comment #25 from Alexander K. Seewald alex@seewald.at 2007-12-19 01:48:48 --- I have the following hal libraries (debian etch packages) installed. AFAIK the hal works perfectly under normal linux (otherwise the drive would not attach), so what's the problem with wine here?
ii hal 0.5.8.1-9 Hardware Abstraction Layer ii libhal-dev 0.5.8.1-9 Hardware Abstraction Layer - development fil ii libhal-storage-dev 0.5.8.1-9 Hardware Abstraction Layer - development fil ii libhal-storage1 0.5.8.1-9 Hardware Abstraction Layer - shared library ii libhal1 0.5.8.1-9 Hardware Abstraction Layer - shared library
AFAIK wine has everything it needs - configure --verbose gives: checking dbus/dbus.h usability... yes checking dbus/dbus.h presence... yes checking for dbus/dbus.h... yes checking hal/libhal.h usability... yes checking hal/libhal.h presence... yes checking for hal/libhal.h... yes checking for dbus_connection_close in -ldbus-1... yes checking for -lhal... libhal.so.1
I've noted that in wine/dlls/hal, in hal.spec there are almost only stubs, except for...
@ stdcall -norelay KfAcquireSpinLock(ptr) @ stdcall -norelay KfLowerIrql(long) @ stdcall -norelay KfRaiseIrql() @ stdcall -norelay KfReleaseSpinLock(ptr long)
Is there a known hal-related problem with linux kernel 2.6.23-rc3? What should I do next to ensure a working hal up to at least device broadcast on plugging in? And how exactly do I debug this? (i.e. is there a proper +debug parameter to get the device notifications from hal-layer?)
-
wine-bugs＠winehq.org