wine-devel

wine-devel@winehq.org

1 participants
84482 discussions

Re: undefined symbol: GetPrinterDataA
by Alexandre Julliard 26 Feb '01

26 Feb '01

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > Would it be useful to create such a list, and maybe list > for each of the dlls in there, why there aren't separated yet? Here's a list of the undefined symbols that prevent separation of the remaining dlls (I didn't include user/gdi/kernel to avoid scaring people too much ;-) ./libddraw.so: undefined reference to `DIB_CreateDIBSection' ./libddraw.so: undefined reference to `DIB_GetDIBWidthBytes' ./libddraw.so: undefined reference to `PROFILE_GetWineIniBool' ./libddraw.so: undefined reference to `WIN_FindWndPtr' ./libddraw.so: undefined reference to `WIN_ReleaseWndPtr' ./libddraw.so: undefined reference to `X11DRV_WND_GetXWindow' ./libddraw.so: undefined reference to `display' ./libddraw.so: undefined reference to `root_window' ./libddraw.so: undefined reference to `visual' ./libopengl32.so: undefined reference to `DC_GetDCPtr' ./libopengl32.so: undefined reference to `GDI_ReleaseObj' ./libopengl32.so: undefined reference to `XFONT_GetFontObject' ./libopengl32.so: undefined reference to `display' ./libopengl32.so: undefined reference to `root_window' ./libopengl32.so: undefined reference to `visual' ./libdinput.so: undefined reference to `MOUSE_Enable' ./libdinput.so: undefined reference to `USER_Driver' ./libwinedos.so: undefined reference to `DOSMEM_Available' ./libwinedos.so: undefined reference to `DOSMEM_FreeBlock' ./libwinedos.so: undefined reference to `DOSMEM_GetBlock' ./libwinedos.so: undefined reference to `DOSMEM_Init' ./libwinedos.so: undefined reference to `DOSMEM_MapRealToLinear' ./libwinedos.so: undefined reference to `DOSMEM_wrap_seg' ./libwinedos.so: undefined reference to `EXC_RtlRaiseException' ./libwinedos.so: undefined reference to `FILE_GetUnixHandle' ./libwinedos.so: undefined reference to `INSTR_EmulateInstruction' ./libwinedos.so: undefined reference to `INT_GetRMHandler' ./libwinedos.so: undefined reference to `INT_Int09SendScan' ./libwinedos.so: undefined reference to `INT_Int33Message' ./libwinedos.so: undefined reference to `INT_RealModeInterrupt' ./libwinedos.so: undefined reference to `INT_SetRMHandler' ./libwinedos.so: undefined reference to `VGA_Clean' ./libwinedos.so: undefined reference to `_LeaveWin16Lock' ./libwinedos.so: undefined reference to `full_argv0' ./libwineps.so: undefined reference to `CloseJob16' ./libwineps.so: undefined reference to `DC_GetDCPtr' ./libwineps.so: undefined reference to `DIB_GetBitmapInfo' ./libwineps.so: undefined reference to `DIB_GetDIBWidthBytes' ./libwineps.so: undefined reference to `DRIVER_RegisterDriver' ./libwineps.so: undefined reference to `DRIVER_UnregisterDriver' ./libwineps.so: undefined reference to `DrvGetPrinterData16' ./libwineps.so: undefined reference to `DrvSetPrinterData16' ./libwineps.so: undefined reference to `GDI_GetObjPtr' ./libwineps.so: undefined reference to `GDI_ReleaseObj' ./libwineps.so: undefined reference to `OpenJob16' ./libwineps.so: undefined reference to `PROFILE_EnumWineIniString' ./libwineps.so: undefined reference to `PROFILE_GetWineIniString' ./libwineps.so: undefined reference to `SelectClipRgn16' ./libwineps.so: undefined reference to `WriteSpool16' ./libmcicda.drv.so: undefined reference to `CDROM_Close' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_Stop' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_GetCDStatus' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_Play' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_GetTracksInfo' ./libmcicda.drv.so: undefined reference to `CDROM_CloseDev' ./libmcicda.drv.so: undefined reference to `CDROM_OpenDev' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_GetSerial' ./libmcicda.drv.so: undefined reference to `CDROM_Open' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_GetNumberOfTracks' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_Pause' ./libmcicda.drv.so: undefined reference to `CDROM_SetDoor' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_Seek' ./libws2_32.so: undefined reference to `SERVICE_Delete' ./libws2_32.so: undefined reference to `SERVICE_AddObject' ./libws2_32.so: undefined reference to `FILE_GetUnixHandle' ./libx11drv.so: undefined reference to `BITMAP_Driver' ./libx11drv.so: undefined reference to `BITMAP_GetWidthBytes' ./libx11drv.so: undefined reference to `CLIPBOARD_DeleteRecord' ./libx11drv.so: undefined reference to `CLIPBOARD_EmptyCache' ./libx11drv.so: undefined reference to `CLIPBOARD_GetFormatName' ./libx11drv.so: undefined reference to `CLIPBOARD_IsPresent' ./libx11drv.so: undefined reference to `CLIPBOARD_LookupFormat' ./libx11drv.so: undefined reference to `CLIPBOARD_ReleaseOwner' ./libx11drv.so: undefined reference to `CLIPPING_IntersectVisRect' ./libx11drv.so: undefined reference to `COLOR_IsSolid' ./libx11drv.so: undefined reference to `COLOR_PaletteLookupExactIndex' ./libx11drv.so: undefined reference to `COLOR_PaletteLookupPixel' ./libx11drv.so: undefined reference to `COLOR_gapEnd' ./libx11drv.so: undefined reference to `COLOR_gapFilled' ./libx11drv.so: undefined reference to `COLOR_gapStart' ./libx11drv.so: undefined reference to `COLOR_max' ./libx11drv.so: undefined reference to `COLOR_sysPal' ./libx11drv.so: undefined reference to `COLOR_sysPalTemplate' ./libx11drv.so: undefined reference to `DCE_InvalidateDCE' ./libx11drv.so: undefined reference to `DC_GetDCPtr' ./libx11drv.so: undefined reference to `DC_InitDC' ./libx11drv.so: undefined reference to `DIB_BitmapInfoSize' ./libx11drv.so: undefined reference to `DIB_CreateDIBFromBitmap' ./libx11drv.so: undefined reference to `DIB_GetBitmapInfo' ./libx11drv.so: undefined reference to `DIB_GetDIBImageBytes' ./libx11drv.so: undefined reference to `DIB_GetDIBWidthBytes' ./libx11drv.so: undefined reference to `DRAG_QueryUpdate' ./libx11drv.so: undefined reference to `DRIVER_RegisterDriver' ./libx11drv.so: undefined reference to `DeleteObject16' ./libx11drv.so: undefined reference to `EVENT_Synchronize' ./libx11drv.so: undefined reference to `FILE_DupUnixHandle' ./libx11drv.so: undefined reference to `FONT_LogFontWTo16' ./libx11drv.so: undefined reference to `GDI_AllocObject' ./libx11drv.so: undefined reference to `GDI_GetObjPtr' ./libx11drv.so: undefined reference to `GDI_ReleaseObj' ./libx11drv.so: undefined reference to `GetClipboardData16' ./libx11drv.so: undefined reference to `InputKeyStateTable' ./libx11drv.so: undefined reference to `KEYBOARD_SendEvent' ./libx11drv.so: undefined reference to `NC_IconForWindow' ./libx11drv.so: undefined reference to `Options' ./libx11drv.so: undefined reference to `PALETTE_Driver' ./libx11drv.so: undefined reference to `PROFILE_GetStringItem' ./libx11drv.so: undefined reference to `PROFILE_GetWineIniBool' ./libx11drv.so: undefined reference to `PROFILE_GetWineIniInt' ./libx11drv.so: undefined reference to `PROFILE_GetWineIniString' ./libx11drv.so: undefined reference to `PostMessage16' ./libx11drv.so: undefined reference to `REGION_LPTODP' ./libx11drv.so: undefined reference to `RestoreVisRgn16' ./libx11drv.so: undefined reference to `SELECTOR_AllocBlock' ./libx11drv.so: undefined reference to `SELECTOR_FreeBlock' ./libx11drv.so: undefined reference to `SERVICE_AddObject' ./libx11drv.so: undefined reference to `SERVICE_AddTimer' ./libx11drv.so: undefined reference to `SaveVisRgn16' ./libx11drv.so: undefined reference to `SelectClipRgn16' ./libx11drv.so: undefined reference to `SelectVisRgn16' ./libx11drv.so: undefined reference to `TWEAK_WineLook' ./libx11drv.so: undefined reference to `VIRTUAL_SetFaultHandler' ./libx11drv.so: undefined reference to `WIN_FindWndPtr' ./libx11drv.so: undefined reference to `WIN_GetDesktop' ./libx11drv.so: undefined reference to `WIN_InternalShowOwnedPopups' ./libx11drv.so: undefined reference to `WIN_LinkWindow' ./libx11drv.so: undefined reference to `WIN_LockWndPtr' ./libx11drv.so: undefined reference to `WIN_ReleaseDesktop' ./libx11drv.so: undefined reference to `WIN_ReleaseWndPtr' ./libx11drv.so: undefined reference to `WIN_RestoreWndsLock' ./libx11drv.so: undefined reference to `WIN_SuspendWndsLock' ./libx11drv.so: undefined reference to `WIN_UnlinkWindow' ./libx11drv.so: undefined reference to `WIN_UpdateWndPtr' ./libx11drv.so: undefined reference to `WIN_WindowNeedsWMBorder' ./libx11drv.so: undefined reference to `WND_Driver' ./libx11drv.so: undefined reference to `argv0' ./libx11drv.so: undefined reference to `get_config_dir' ./libx11drv.so: undefined reference to `pKeyStateTable' ./libttydrv.so: undefined reference to `BITMAP_Driver' ./libttydrv.so: undefined reference to `COLOR_gapEnd' ./libttydrv.so: undefined reference to `COLOR_gapStart' ./libttydrv.so: undefined reference to `COLOR_sysPal' ./libttydrv.so: undefined reference to `COLOR_sysPalTemplate' ./libttydrv.so: undefined reference to `DC_GetDCPtr' ./libttydrv.so: undefined reference to `DRIVER_FindDriver' ./libttydrv.so: undefined reference to `DRIVER_RegisterDriver' ./libttydrv.so: undefined reference to `GDI_GetObjPtr' ./libttydrv.so: undefined reference to `GDI_ReleaseObj' ./libttydrv.so: undefined reference to `PALETTE_Driver' ./libttydrv.so: undefined reference to `WND_Driver' -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Speeding up wineserver synchronization objects with shared memory
by Alexandre Julliard 26 Feb '01

26 Feb '01

"Robert O'Callahan" <roc+(a)cs.cmu.edu> writes: > So your concern is simply that if it's too simple to lock the mutex, then > you have an unacceptably high probability of a runaway process > accidentally locking the mutex, whereas you regard the probability of the > process accidentally calling AcquireMutex again (or executing the > protected control transfer on its own) as acceptably low. That seems > reasonable. No, that's not my concern. The probability of error doesn't matter at all, I don't mind if the process locks the mutex by accident. What must not be able to happen is that the process somehow corrupts the state as seen from the wineserver or other processes. That is, it doesn't matter if the process thinks it got the mutex when it didn't; but it must not be possible to make the wineserver see two processes holding the mutex, or some other inconsistent state. Any inconsistency must remain local to the process. > Yeah, but that doesn't seem fundamental --- the wineserver can always take > ownership of the mutex itself when it needs to do a complex atomic > operation. I'll let Gavriel work out the details :-). My point is that getting the details right is what is important; and if you are not interested in doing this, then there is no point in arguing any further. -- Alexandre Julliard julliard(a)winehq.com

1 0

undefined symbol: GetPrinterDataA
by Ian Pilcher 26 Feb '01

26 Feb '01

I am trying to modify the Wine PostScript driver to use GetPrinterDataA to read configuration information from the registry. I have added a line that reads "import winspool.drv" to wineps.spec, and Wine builds with no errors. When I try to run Wine, however, I get the following error: BUILTIN32_dlopen failed to load .so lib for builtin wineps.dll: /usr/lib/wine/libwineps.so: undefined symbol: GetPrinterDataA Ideas? -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

5 4

Re: Speeding up wineserver synchronization objects with shared memory
by Alexandre Julliard 26 Feb '01

26 Feb '01

"Robert O'Callahan" <roc+(a)cs.cmu.edu> writes: > Of course it has to be 100% reliable, but since you're dealing with > failing processes it's not 100% clear what 100% reliability is. Anyway, I > think 100% reliability is possible for any plausible definition. For a mutex the basic definition is obviously that you can never have two threads holding the mutex at the same time, and that when it is released some other thread has a chance at grabbing it. This has to be true no matter what the process does, including corrupting memory or crashing. You also need to make sure nothing a process does should be able to crash/hang the wineserver or another process (except if they fight over the same mutex of course), and then there is the small matter of respecting the Win32 semantics... Actually it is the last constraint that is the main problem. You can certainly provide some kind of mutexes using shared memory; but we don't need just 'some kind', we need Win32 mutexes. This means a mutex is identified by a handle that can be manipulated by CloseHandle or DuplicateHandle; it means you need to detect and handle abandoned mutexes; it means you must support WaitForMultipleObjects, including the 'all' case where you cannot grab the mutex unless all objects are signaled; all things that I didn't see in your implementation ;-) -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: undefined symbol: GetPrinterDataA
by gerard patel 26 Feb '01

26 Feb '01

At 08:30 PM 25/02/2001 +0600, you wrote: >I am trying to modify the Wine PostScript driver to use GetPrinterDataA >to read configuration information from the registry. I have added a >line that reads "import winspool.drv" to wineps.spec, and Wine builds >with no errors. When I try to run Wine, however, I get the following >error: > > BUILTIN32_dlopen failed to load .so lib for builtin wineps.dll: > /usr/lib/wine/libwineps.so: undefined symbol: GetPrinterDataA Note the differences between the Makefile for common dialog (where this works) and the Makefile for wineps : commdlg : # Generated automatically from Makefile.in by configure. TOPSRCDIR = ../.. TOPOBJDIR = ../.. SRCDIR = . MODULE = comdlg32 ALTNAMES = commdlg EXTRALIBS = $(LIBUUID) LDDLLFLAGS = -Wl,-Bsymbolic SYMBOLFILE = $(MODULE).tmp.o (...) wineps : # Generated automatically from Makefile.in by configure. TOPSRCDIR = ../.. TOPOBJDIR = ../.. SRCDIR = . MODULE = wineps SOVERSION = 1.0 ALTNAMES = wineps16 IMPORTS = user32 gdi32 kernel32 ntdll C_SRCS = \ (...) I think that the mechanism is not working because dlls separation is not done for wineps ;-) Gerard

1 0

Re: undefined symbol: GetPrinterDataA
by Ian Pilcher 26 Feb '01

26 Feb '01

lawson_whitney(a)juno.com wrote: > > I think maybe you have created a new dependency and need to run make > depend again? If I understand the import mechanism, something > (winebuild?) generates stubs for the functions you import and ties them > in to the import mechanism, so they shouldn't be left hanging for ld.so > to choke on. They should resolve to .spec.o. It looks to me as if the > .spec didin't get rebuilt. > If only it were that simple. I've rebuilt from scratch, with a clean source tree. -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

2 3

Re: various config files for various applications
by Alexandre Julliard 26 Feb '01

26 Feb '01

Martin Pilka <mpilka(a)codeweavers.com> writes: > another way could be have some additional (let's say > ~/.wine/app-config/1database.txt) file which will contain <regular > expression> --> <filename> mappings. that way wine have to open (and > read) only that file, and we're able to do that pretty fast (as i found > out when worked on registry patch). however, it has to evaluate all the > reg. expressions at runtime, but that is linear dependency. > > hmm, i don't know now. first letter or an additional file? This is getting way too complex IMO. I think having everything in the .wine/config file is much more reasonable; most people don't need that many different configurations anyway. What we should do is take advantage of the new config file format to create a deeper configuration hierarchy. So for instance the default x11drv config is under the registry key Wine\Config\x11drv, but we could create subtrees like Wine\Config\AppDefaults\Solitaire\x11drv which would contain the Solitaire-specific config values. This is then very fast to lookup, just try AppDefaults\<current module> and if not found fall back to the current method. I don't think we need regular expressions at all. -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: Re: undefined symbol: GetPrinterDataA
by Eric Pouech 26 Feb '01

26 Feb '01

>wineps : > ># Generated automatically from Makefile.in by configure. >TOPSRCDIR = ../.. >TOPOBJDIR = ../.. >SRCDIR = . >MODULE = wineps >SOVERSION = 1.0 >ALTNAMES = wineps16 >IMPORTS = user32 gdi32 kernel32 ntdll in this case, just add winspool.drv to the IMPORT list in the Makefile.in, rerun configure, and it should work. (If Alexandre didn't convert the Makefile.in for dll separation, there should be some good reasons... like using non exported symbols... which would require much more work) A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

2 1

Re: Speeding up wineserver synchronization objects with shared memory
by Alexandre Julliard 26 Feb '01

26 Feb '01

Gavriel State <gav(a)transgaming.com> writes: > Even without that approach though, I don't think that the new failure mode > is really likely to be that big a deal. If process A owns a mutex that process > B wants, they quite likely have some functional interdependance which would be > disrupted as much by any generic hang in process A as by a hang followed by > a failure to release the mutex. Imagine a process that does a SuspendThread() on one of its threads, but makes sure by some kind of internal protocol that the thread is never holding the mutex when it is suspended. This would work just fine under Windows or under the wineserver, but would fail with the shared memory approach. There is simply no point in implementing a mutex that works only 99% of the time, no matter how fast it is. The synchronization objects have to be 100% reliable, performance only comes next; and none of the shared memory approaches I've seen so far are 100% reliable. In fact the original implementation of the kernel objects was based on shared memory and signals. A lot of time was spent trying to make this work right, but it was simply not possible without assuming that all processes will always follow the protocol correctly, which is clearly not something we can assume when running arbitrary Windows code. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Speeding up wineserver synchronization objects with shared memory
by Michael McCormack 26 Feb '01

26 Feb '01

Two things: 1. How about expiring client's unix file descriptors by having wineserver writing a single non-zero byte[*] to the server-communication socket when another client modifies the fd? The code to validate fds before use could then be reduced from a server call to a single nonwaiting poll on NtCurrentTeb()->reply_fd. 2. How about using pipes to implement critical sections? InitCriticalSection would create a pipe and write one byte, EnterCritical section would do a poll on the pipe, followed by a read of one byte, and leave critical section would write one byte back to the pipe. [*] wineserver would write a zero byte when it wished to restart a client after a server call, and the client would need to check this. Mike -- __________________________________________________________________ mailto:Michael.McCormack@alcatel.com.au phone: (+82 11 430 0425)

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel