Minor progress on Windows clipboard deadlock
>I'm not sure if you were using Xdmcp or if you were using -mutliwindow with ssh. >If you were using Xdmcp, then this may fix your problem; if you are only using >ssh, then it is unlikely to help. -multiwindow + ssh. I'm still on the lookout for when this happens, but I haven't run with -48 for very long. I would say that there is inconclusive evidence that this this deadlock does not occur under W2K with a single monitor, but only on a XP machine w/multiple monitors. Øyvind
Convenient script for starting an XFree86 xterm
I've seen some other postings on this subject recently, so I'm submitting
this contribution as a potential starting point for others.
I have convenient Windows desktop shortcuts to start up a Cygwin/Bash shell
window and an RXVT/Bash shell window. I was looking for something similar to
start up a Cygwin/XFree86 xterm. Of course, I didn't want to generate
multiple running copies of the 'XWin' server, nor did I want useless Command
prompt windows hanging around.
Here's what I came up with. I make no claim to generality, robustness,
cleverness, originality or anything else. It just works for me.
It consists of three parts:
1) A desktop shortcut with the following target:
C:\WINNT\SYSTEM32\WSCRIPT.EXE "C:\cygwin\invisible.vbs"
"C:\cygwin\XFree86xterm.bat"
2) A VB shell script named 'C:\cygwin\invisible.vbs' containing the single
line:
CreateObject("Wscript.Shell").Run & WScript.Arguments(0) & , 0,
False
3) A DOS shell script named 'C:\cygwin\XFree86xterm.bat' containing the
following lines:
---
@echo off
ps -ef | grep /usr/X11R6/bin/XWin > nul
if ERRORLEVEL 1 (
start /DC:\cygwin\usr\X11R6\bin /B XWin -multiwindow -clipboard
)
set DISPLAY=localhost:0.0
C:\cygwin\usr\X11R6\bin\xterm -fn 10x20 -sl 1000 -sb -leftbar -ms red -fg
yellow -bg black -e /usr/bin/bash --login -i
---
Description:
- The shortcut starts the Windows scripting language, which runs the simple
Visual Basic script.
- The VB script runs the DOS shell script without generating a Command
window.
- The DOS shell script
- Starts 'XWin' with my preferred switches as a background process if no
such process is already running,
- Sets DISPLAY to the 'localhost:0.0', which the 'xterm' will inherit, and
- Starts a login bash shell in an XFree86 xterm with some decent extra
settings.
john
Re: Takuma's Duplicate Display Check
Okay, I fixed it. It should work with Terminal Services now without causing problems with non-NT > 4.0 versions of Windows. The change has been committed to the CYGWIN tag in CVS. Harold
Cygwin/xFree from 2 users
Hello. I use a notebook computer so I can carry my computing environment around. This is WinXP and current versions of Cygwin and xFree as of a few weeks ago. I have several user 'accounts' that belong to various domains. Most of these accounts are 'js', as in [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], etc. I want all of these to use the same Cygwin home directory. Cygwin and X were installed from [EMAIL PROTECTED] When I'm not connected to a network, I use [EMAIL PROTECTED] Cygwin seems to work with both user accounts but X will not start from [EMAIL PROTECTED] The attached xwin.log came from running xinit. Trying to start kde gives an error that there is no write access to .ICEauthority. I believe the X problem is related to permissions within /home/js. I have tried to set up permissions for both user accounts on /home/js but I can't seem to make them stick. What permissions are needed? What file permissions are critical, which mearly convenient? Does the setup process replace the permissions on the user's home directory? How can Cygwin and X be configured for multiple users on a machine? and the big question - how can I configure Cygwin and X so that I can use the same /home/js directory from multiple 'js' accounts? Jim __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com XWin.log Description: XWin.log
Takuma's Duplicate Display Check
Takuma,
Your duplicate display check in InitOutput.c seems correct to me.
The only question I have is if the mutex allocated by CreateMutex is
visible by XWin.exe running under a different session on Terminal Services.
Oops, I just looked it up and answered my own question:
Terminal Services: The name can have a "Global\" or "Local\" prefix to
explicitly create the object in the global or session name space. The
remainder of the name can contain any character except the backslash
character (\). For more information, see Kernel Object Namespaces.
Windows XP: Fast user switching is implemented using Terminal Services
sessions. The first user to log on uses session 0, the next user to log
on uses session 1, and so on. Kernel object names must follow the
guidelines outlined for Terminal Services so that applications can
support multiple users.
Windows 2000: If Terminal Services is not running, the "Global\" and
"Local\" prefixes are ignored. The remainder of the name can contain any
character except the backslash character.
Windows NT 4.0 and earlier: The name can contain any character except
the backslash character.
Windows 95/98/Me: The name can contain any character except the
backslash character. The empty string ("") is a valid object name.
We can easily add "Global\" to the name, but I think we have to have a
way to detect that the NT version is greater than 4.0, since it sounds
like CreateMutex may fail on Windows 95/98/Me/NT 4.0 if you pass it a
"\" in the name.
I am going to add the "Global\" to CVS... and possibly a way to make
sure that "Global\" is only prepended for NT > 4.0.
Harold
Re: OpenGL header problems
Igor Pechtchanski wrote: Harold, What about the command that builds the static library that InitOutput.o is included into? Does it, by any chance, use a --kill-at linker flag? Otherwise I'm out of ideas. If you could either post the whole XWin.exe make log somewhere or send it to me privately, I'll see if I can spot something that's different in your test example. Posting it will, of course, allow everyone else to examine it as well. Igor Oops, forgot to include that command. Putting together a complete build log would be kinda tricky at the moment since I'm not really doing a complete build of things... it would just have what I have sent so far, plus the link command below and tons of additional notes on which directory it is going into to do nothing. I don't think that would be of much use. Harold ar clq libXWin.a InitInput.o InitOutput.o stubs.o winallpriv.o winauth.o winblock.o wincmap.o winconfig.o wincreatewnd.owincursor.o windialogs.o winengine.o winerror.o winglobals.o winkeybd.o winmisc.o winmouse.o winmsg.o winmultiwindowclass.o winmultiwindowicons.o winprefs.o winprefslex.o winprefsyacc.o winprocarg.o winregistry.o winscrinit.o winshaddd.o winshadddnl.o winshadgdi.o wintrayicon.o winwakeup.o winwindow.o winwndproc.o winclipboardinit.o winclipboardtextconv.o winclipboardthread.o winclipboardunicode.o winclipboardwndproc.o winclipboardwrappers.o winclipboardxevents.o winmultiwindowshape.o winmultiwindowwindow.o winmultiwindowwm.o winmultiwindowwndproc.o ranlib libXWin.a
Re: OpenGL header problems
On Mon, 1 Mar 2004, Harold L Hunt II wrote: Igor Pechtchanski wrote: > On Mon, 1 Mar 2004, Harold L Hunt II wrote: > >>As I mentioned in my email about enabling indirect OpenGL acceleration, >>there are some problems when trying to link to -lopengl32. >> >>I tracked this down to problems with the way that >>/usr/include/w32api/GL/gl.h decorates the function declarations for the >>gl* functions. There are some collisions between the way that the >>standard windows headers define WINGDIAPI and APIENTRY and the way that >>gl.h expects them to be. >> >>However, the problem is a little trickier than just that: I added a call >>to glPixelStorei in Xserver/hw/xwin/InitOutput.c (without #including any >>opengl headers) and instead made my own prototype for glPixelStorei. If >>I made it: >> >>void __stdcall glPixelStorei (unsigned int, int); >> >>then the linker would complain about how it had to fixup a reference to >>glPixelStorei as [EMAIL PROTECTED] But that is exactly what the >>__stdcall was supposed to do, so I am getting a little confused about >>why the prototype was being ignored. >> >>I need an expert on __stdcall and w32api headers to give me a hand here. >> Igor, I saw a post you made on this subject before, so I am counting >>on you :) >> >>Once this little trick is solved we will have to figure out how to get >>the proper headers in exports/include/GL/; that directory currently >>getes some Mesa headers in it. I'm not sure if we can cleanly disable >>that and point to the w32api OpenGL headers instead. >> >>Harold > > > Harold, > > I'm by no means an expert, and I can't seem to reproduce it. Could you > please post the exact gcc invocation that exhibits these symptoms? > Looking at ld's info page, there are a couple of options that could be > passed to the linker to modify this behavior. It may also be a problem > with the import lib, for all I know... Is the build seeing the right > libraries? > > Also, the GL/gl.h header doesn't actually use WINGDIAPI, and GLAPI is > defined to be "extern" on Cygwin. Your declaration, however, seems > correct. Just for kicks, could you try reverting to including GL/gl.h in > Xserver/hw/xwin/InitOutput.c and run the build command for that file with > a "-E" in CFLAGS? That should produce a preprocessed version of > Xserver/hw/xwin/InitOutput.c, so you can see exactly how glPixelStorei is > declared. I have attached a demo program and Makefile that closely models the way that XWin.exe is built: it builds a static library and links that static lib and some system libs into an executable, using most of the compilation flags that are being used when building XWin.exe and libXWin.a. Only one problem: it doesn't have any problems! :) The demo program can #include and it can #include , or it can leave both of those out and just include the resulting prototype for glPixelStorei: void __attribute__((__stdcall__)) glPixelStorei (unsigned int, int); Both of these approaches work just fine. I included the above prototype in InitOutput.c (and did another test in winshadgdi.c to be sure), did not include and checked the preprocessed file to make sure that the glPixleStorei prototype came through exactly as it was in the source. The program links to that function (however, I was able to achieve this before doing something similar), but I still get this silly warning that I do not get from the demo program: Warning: resolving _glPixelStorei by linking to [EMAIL PROTECTED] Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups I can't just ignore this warning because we call tons of other stdcall functions in Win32 DLLs (such as BitBlt from winshadgdi.c) and their prototypes look identical to the one above for glPixelStorei. So something weird is going on that is causing libopengl32.a to misbehave for stdcall functions while all other libraries are working just fine with stdcall functions. This unexplained discrepancy bothers me. I have checked the symbols from libgdi32.a and libopengl32.a and they look the same... so this doubly bothers me. Detailed commands are below for those that are interested. Harold InitOutput.o command gcc -c -O2 -fno-strength-reduce -Wall -Wpointer-arith -I. -I../../../../exports/include/X11 -I../../../../include/fonts -I../../../../programs/Xserver/fb -I../../../../programs/Xserver/mi -I../../../../programs/Xserver/miext/shadow -I../../../../programs/Xserver/miext/layer -I../../../../programs/Xserver/include -I../../../../programs/Xserver/os -I../../../../include/extensions -I../../../../exports/include/X11 -I../../../../programs/Xserver/render -I../../../../programs/Xserver/randr -I../../../.. -I../../../../exports/include -D__i386__ -DWIN32_LEAN_AND_MEAN -DX_LOCALE -D_X86_ -D__CYGWIN__ -D_XOPEN_SOURCE -D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DREN
Cygwin Openbox queries
Hi, I am having trouble with the Cygwin. I had downloaded and installed the complete suite fo the Cygwin including all the modules for the X Window System. I am trying to start the X server with Cygwin/X running in Rootless mode with the /openbox/ window manager running locally (one of the screenshots). However, I have no idea on how to do it. I tried running "openbox" but I got this error saying Connection to X server failed. I had checked the online user guide and searched the internet for any guide but failed. Do you have any script on how to start the X server with openbox window manager? Any website that I can refer to? Thank you so much in advance for your help. I really appreciate your help. Regards, Jophrey __ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools
Re: OpenGL header problems
Igor Pechtchanski wrote: On Mon, 1 Mar 2004, Harold L Hunt II wrote: As I mentioned in my email about enabling indirect OpenGL acceleration, there are some problems when trying to link to -lopengl32. I tracked this down to problems with the way that /usr/include/w32api/GL/gl.h decorates the function declarations for the gl* functions. There are some collisions between the way that the standard windows headers define WINGDIAPI and APIENTRY and the way that gl.h expects them to be. However, the problem is a little trickier than just that: I added a call to glPixelStorei in Xserver/hw/xwin/InitOutput.c (without #including any opengl headers) and instead made my own prototype for glPixelStorei. If I made it: void __stdcall glPixelStorei (unsigned int, int); then the linker would complain about how it had to fixup a reference to glPixelStorei as [EMAIL PROTECTED] But that is exactly what the __stdcall was supposed to do, so I am getting a little confused about why the prototype was being ignored. I need an expert on __stdcall and w32api headers to give me a hand here. Igor, I saw a post you made on this subject before, so I am counting on you :) Once this little trick is solved we will have to figure out how to get the proper headers in exports/include/GL/; that directory currently getes some Mesa headers in it. I'm not sure if we can cleanly disable that and point to the w32api OpenGL headers instead. Harold Harold, I'm by no means an expert, and I can't seem to reproduce it. Could you please post the exact gcc invocation that exhibits these symptoms? Looking at ld's info page, there are a couple of options that could be passed to the linker to modify this behavior. It may also be a problem with the import lib, for all I know... Is the build seeing the right libraries? Also, the GL/gl.h header doesn't actually use WINGDIAPI, and GLAPI is defined to be "extern" on Cygwin. Your declaration, however, seems correct. Just for kicks, could you try reverting to including GL/gl.h in Xserver/hw/xwin/InitOutput.c and run the build command for that file with a "-E" in CFLAGS? That should produce a preprocessed version of Xserver/hw/xwin/InitOutput.c, so you can see exactly how glPixelStorei is declared. I have attached a demo program and Makefile that closely models the way that XWin.exe is built: it builds a static library and links that static lib and some system libs into an executable, using most of the compilation flags that are being used when building XWin.exe and libXWin.a. Only one problem: it doesn't have any problems! :) The demo program can #include and it can #include , or it can leave both of those out and just include the resulting prototype for glPixelStorei: void __attribute__((__stdcall__)) glPixelStorei (unsigned int, int); Both of these approaches work just fine. I included the above prototype in InitOutput.c (and did another test in winshadgdi.c to be sure), did not include and checked the preprocessed file to make sure that the glPixleStorei prototype came through exactly as it was in the source. The program links to that function (however, I was able to achieve this before doing something similar), but I still get this silly warning that I do not get from the demo program: Warning: resolving _glPixelStorei by linking to [EMAIL PROTECTED] Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups I can't just ignore this warning because we call tons of other stdcall functions in Win32 DLLs (such as BitBlt from winshadgdi.c) and their prototypes look identical to the one above for glPixelStorei. So something weird is going on that is causing libopengl32.a to misbehave for stdcall functions while all other libraries are working just fine with stdcall functions. This unexplained discrepancy bothers me. I have checked the symbols from libgdi32.a and libopengl32.a and they look the same... so this doubly bothers me. Detailed commands are below for those that are interested. Harold InitOutput.o command gcc -c -O2 -fno-strength-reduce -Wall -Wpointer-arith -I. -I../../../../exports/include/X11 -I../../../../include/fonts -I../../../../programs/Xserver/fb -I../../../../programs/Xserver/mi -I../../../../programs/Xserver/miext/shadow -I../../../../programs/Xserver/miext/layer -I../../../../programs/Xserver/include -I../../../../programs/Xserver/os -I../../../../include/extensions -I../../../../exports/include/X11 -I../../../../programs/Xserver/render -I../../../../programs/Xserver/randr -I../../../.. -I../../../../exports/include -D__i386__ -DWIN32_LEAN_AND_MEAN -DX_LOCALE -D_X86_ -D__CYGWIN__ -D_XOPEN_SOURCE -D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DRENDER -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFree86Server -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DXWIN_CLIPBOARD
Re: xterm stops drawing
Here it is, thanks for taking the time to look at this. -Chad Harold L Hunt II wrote: Send in /tmp/XWin.log. Chad Haynes wrote: Unfortunately this did not help, the same problems are still happening. ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1280 h 1024 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winScreenInit - dwWidth: 1280 dwHeight: 1024 winSetEngine - Multi Window => ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winScreenInit - Monitors do not all have same pixel format / display depth. Using primary display only. winCreateBoundingWindowWindowed - User w: 1280 h: 1024 winCreateBoundingWindowWindowed - Current w: 1280 h: 1024 winAdjustForAutoHide - Original WorkArea: 0 106 1024 1280 winAdjustForAutoHide - Adjusted WorkArea: 0 106 1024 1280 winCreateBoundingWindowWindowed - WindowClient w 1174 h 1024 r 1174 l 0 b 1024 t 0 winCreateBoundingWindowWindowed - Returning winAllocateFBShadowGDI - Creating DIB with width: 1174 height: 1024 depth: 32 winAllocateFBShadowGDI - Dibsection width: 1174 height: 1024 depth: 32 size image: 4808704 winAllocateFBShadowGDI - Created shadow stride: 1174 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winCreateDefColormap - Deferring to fbCreateDefColormap () null screen fn ReparentWindow null screen fn RestackWindow winFinishScreenInitFB - Calling winInitWM. InitQueue - Calling pthread_mutex_init InitQueue - pthread_mutex_init returned InitQueue - Calling pthread_cond_init InitQueue - pthread_cond_init returned winInitWM - Returning. winFinishScreenInitFB - returning winScreenInit - returning winInitMultiWindowWM - Hello winInitMultiWindowWM - Calling pthread_mutex_lock () winMultiWindowXMsgProc - Hello winMultiWindowXMsgProc - Calling pthread_mutex_lock () InitOutput - Returning. MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: "0409" (0409) Rules = "xfree86" Model = "pc101" Layout = "us" Variant = "(null)" Options = "(null)" Could not init font path element /usr/X11R6/lib/X11/fonts/Speedo/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/Type1/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/100dpi/, removing from list! winPointerWarpCursor - Discarding first warp: 587 512 winBlockHandler - Releasing pmServerStarted winInitMultiWindowWM - pthread_mutex_lock () returned. winBlockHandler - pthread_mutex_unlock () returned winMultiWindowXMsgProc - pthread_mutex_lock () returned. winMultiWindowXMsgProc - pthread_mutex_unlock () returned. winMultiWindowXMsgProc - DISPLAY=127.0.0.1:0.0 winInitMultiWindowWM - pthread_mutex_unlock () returned. winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0 winProcEstablishConnection - Hello winProcEstablishConnection - Clipboard is not enabled, returning. winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display. winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. winDeinitMultiWindowWM - Noting shutdown in progress OsVendorReset - Hello winDeinitMultiWindowWM - Noting shutdown in progress
Re: xterm stops drawing
Send in /tmp/XWin.log. Chad Haynes wrote: Unfortunately this did not help, the same problems are still happening.
Re: xterm stops drawing
Unfortunately this did not help, the same problems are still happening. -Chad Harold L Hunt II wrote: Chad, Try the 'test' package XFree86-xserv-4.3.0-48. You get this by running Cygwin's setup.exe again (no need for reinstall) and manually select the 4.3.0-48 version by clicking on the "Keep" value several times until it says 4.3.0-48. Be aware that you have to do this *everytime* you run Cygwin's setup.exe, or else it will downgrade you to 4.3.0-47 again. Harold Chad Haynes wrote: Hello, I recently installed cygwin/X and everything was working pretty well. Today I installed the rxvt package and suddenly everything went nuts in multiwindow mode. Running the startxwin.sh script which worked fine before no longer functions properly. The window that appears is only half drawn and when I try to drag it around there is a ghost of the image on the other side of the screen. After the window has been dragged, it no longer draws anything other than the border. I reinstalled everything, but it has not helped. I have dual monitors connected and am using the command: Xwin -multiwindow -multimonitors I'm attaching my cygcheck, any help would be greatly appreciated.
Re: xterm stops drawing
Chad, Try the 'test' package XFree86-xserv-4.3.0-48. You get this by running Cygwin's setup.exe again (no need for reinstall) and manually select the 4.3.0-48 version by clicking on the "Keep" value several times until it says 4.3.0-48. Be aware that you have to do this *everytime* you run Cygwin's setup.exe, or else it will downgrade you to 4.3.0-47 again. Harold Chad Haynes wrote: Hello, I recently installed cygwin/X and everything was working pretty well. Today I installed the rxvt package and suddenly everything went nuts in multiwindow mode. Running the startxwin.sh script which worked fine before no longer functions properly. The window that appears is only half drawn and when I try to drag it around there is a ghost of the image on the other side of the screen. After the window has been dragged, it no longer draws anything other than the border. I reinstalled everything, but it has not helped. I have dual monitors connected and am using the command: Xwin -multiwindow -multimonitors I'm attaching my cygcheck, any help would be greatly appreciated.
xterm stops drawing
Hello, I recently installed cygwin/X and everything was working pretty well. Today I installed the rxvt package and suddenly everything went nuts in multiwindow mode. Running the startxwin.sh script which worked fine before no longer functions properly. The window that appears is only half drawn and when I try to drag it around there is a ghost of the image on the other side of the screen. After the window has been dragged, it no longer draws anything other than the border. I reinstalled everything, but it has not helped. I have dual monitors connected and am using the command: Xwin -multiwindow -multimonitors I'm attaching my cygcheck, any help would be greatly appreciated. -Chad Cygwin Win95/NT Configuration Diagnostics Current System Time: Mon Mar 01 16:19:41 2004 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: C:\cygwin\usr\X11R6\bin C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin c:\oracle\ora92\bin c:\Program Files\Oracle\jre\1.1.8\bin c:\Perl\bin\ c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\Common Files\Adaptec Shared\System c:\Python23\ c:\dev-cpp\bin c:\SWIG-1.3.19 c:\SFU\common\ Output from C:\cygwin\bin\id.exe (nontsec) UID: 1006(Chad Haynes) GID: 513(None) 513(None) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1006(Chad Haynes) GID: 513(None) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS HOME = `C:\cygwin\home\Chad Haynes' LD_LIBRARY_PATH = `C:\cygwin\usr\lib:\usr\X11R6\lib' MAKE_MODE = `unix' PWD = `/home/Chad Haynes' USER = `Chad Haynes' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options a: fd N/AN/A c: hd NTFS 38130Mb 47% CP CS UN PA FC d: cd N/AN/A e: cd N/AN/A m: net NFS64965Mb 5% CP n: net NFS10137Mb 85% CP C:\cygwin / system binmode C:\cygwin/bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode C:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts system binmode . /cygdrive system binmode,cygdrive Found: C:\cygwin\bin\awk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: c:\SFU\common\cat.exe Found: C:\cygwin\bin\cp.exe Found: c:\SFU\common\cp.exe Found: C:\cygwin\usr\local\bin\cpp.exe Found: C:\cygwin\bin\cpp.exe Found: c:\dev-cpp\bin\cpp.exe Found: C:\cygwin\bin\find.exe Found: c:\SFU\common\find.exe Found: C:\cygwin\bin\gcc.exe Found: c:\dev-cpp\bin\gcc.exe Found: C:\cygwin\bin\gdb.exe Found: c:\dev-cpp\bin\gdb.exe Found: C:\cygwin\bin\grep.exe Found: c:\SFU\common\grep.exe Found: C:\cygwin\bin\ld.exe Found: c:\dev-cpp\bin\ld.exe Found: C:\cygwin\bin\ls.exe Found: c:\SFU\common\ls.exe Found: C:\cygwin\bin\make.exe Found: c:\dev-cpp\bin\make.exe Found: C:\cygwin\bin\mv.exe Found: c:\SFU\common\mv.exe Found: C:\cygwin\bin\rm.exe Found: c:\dev-cpp\bin\rm.exe Found: c:\SFU\common\rm.exe Found: C:\cygwin\bin\sed.exe Found: c:\SFU\common\sed.exe Found: C:\cygwin\bin\sh.exe Found: C:\cygwin\bin\tar.exe Found: c:\dev-cpp\bin\tar.exe 237k 2003/11/18 C:\cygwin\usr\X11R6\bin\cygdps-1.dll 121k 2003/11/18 C:\cygwin\usr\X11R6\bin\cygdpstk-1.dll 28k 2004/01/16 C:\cygwin\usr\X11R6\bin\cygDtPrint-1.dll 282k 2003/10/28 C:\cygwin\usr\X11R6\bin\cygfreetype-9.dll 373k 2003/11/18 C:\cygwin\usr\X11R6\bin\cygGL-1.dll 439k 2003/11/18 C:\cygwin\usr\X11R6\bin\cygGLU-1.dll 74k 2003/11/18 C:\cygwin\usr\X11R6\bin\cygICE-6.dll 76k 2004/01/16 C:\cygwin\usr\X11R6\bin\cygMrm-2.dll 9k 2003/11/18 C:\cygwin\usr\X11R6\bin\cygoldX-6.dll 1271k 2003/11/18 C:\cygwin\usr\X11R6\bin\cygOSMesa-4.dll 20k 2003/11/18 C:\cygwin\usr\X11R6\bi
Re: Minor progress on Windows clipboard deadlock
Øyvind, I think I fixed at least part of your problem with the clipboard support when compiling from CVS. It turned out that my OsVendorReset function was not being called in the CVS version because -DDDXOSRESET was not being defined where the files in Xserver/dix/ could see it, thus no call was made to OsVendorReset since it is wrapped with #ifdef DDXOSRESET. I'm not sure if you were using Xdmcp or if you were using -mutliwindow with ssh. If you were using Xdmcp, then this may fix your problem; if you are only using ssh, then it is unlikely to help. Harold Øyvind Harboe wrote: I believe I've made a tiny step towards finding out when this happens. Before the deadlock happens copying from windows and pasting in e.g. Evolution no longer works. I.e. the paste behaves as if the clipboard is empty. At this point XWin is doomed. If you subsequently copy from e.g. Evolution and paste in any Windows app, that Windows app is deadlocked. Øyvind
xserv 4.3.0-48 problems
Ahem. Please ignore my previous post. As was kindly pointed out below, adding a line to ~/.ssh/config is all thats needed, which I did and everything is now bliss again. http://www.cygwin.com/ml/cygwin-xfree/2004-03/msg9.html To my feeble defense it isn't easy to work backwards from the symptoms to solution on this one, though I should have combed the mailing list more carefully. Harold writes: >The problem with your keyboard layout could be related to XF86Config >files no longer being supported. The keyboard problem was also the missing line in ~/.ssh/config, works fine now. Øyvind
Re: xserv 4.3.0-48 problems
Andrew is right, it sounds like most of your problems are due to the fun Trusted X11 change in OpenSSH. That is a problem that can be solved by reading OpenSSH documentation; it is not a Cygwin/X specific problem. The problem with your keyboard layout could be related to XF86Config files no longer being supported. If you were specifying a keyboard in that file, then you will have to change to instead specifying that keyboard on the command-line to XWin.exe, using the parameters that Alexander described a few days ago. Unless, of course, you still have the same keyboard problems even with XFree86-xserv-4.3.0-46, in which case your keyboard problems might also be caused by ssh... Harold
view these!!
FROM: EZEKWED CHAMBERS 575 Finchley Road London NW3 7BJ U.K NOTIFICATION OF BEQUEST My name is Mrs.riat austin, a legal practitioner ofEZEKWED CHAMBERS in London and personalrepresentative to Mr. John Ryerson who died on the 9thof february 2002On behalf of the Trustees and ExecutorS of the estateof Late Engr. John Ryerson, I once again try to notify you as my earlier letter toyou by Post was returned undelivered. I hereby attempt to reach you via your email. I wish to notify you that late Engr. John Ryerson made you a beneficiary to his will.He left the sum of Three Hundred and Fifty Thousand Dollars (US$350,000.00 ) to you in the codicil and last testament to his will. This may sound strange and unbelievable to you, but it is real and true. Being a widely traveled man, he must have been in contact with you in the past or simply you were nominated to him by one of his numerous friends abroad who wished you good. Engr, JOHN RYERSON until his death was a former managing director and pioneer staff of a giant construction company. He was a very dedicated religious man who loved to give out. His great philanthropy earned him numerous awards during his life time. Late Engr. John Ryerson died on the 9th day of February 2002 at the age of 82 years, and his Will is now ready for execution. Please If I reach you as I am hopeful, endeavor to get back to me as soon as possible to enable me execute the Will to conclude my job. You should forward along yourcurrent telephone and fax number, including your current mailing address. I hope to hear from you in no distant time. Mrs. rita austin(ESQ) Ezekwed Chambers.
RE: xserv 4.3.0-48 problems
Did you try the ForwardX11Trusted configuration that has been discussed here over the last few days? - Andy > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Øyvind Harboe > Sent: Monday, March 01, 2004 12:05 PM > To: [EMAIL PROTECTED] > Subject: xserv 4.3.0-48 problems > > > Note! This is *not* a complaint. I love CygWin + xfree86, and > I chose to > be at the bleeding edge because of it. > > Something terribly wrong happened when I upgraded to -48. Of course > CygWin setup.exe upgraded oodles of other stuff as well > > There is a raft of regressions, so I suspect there must be a common > cause. > > - copy&paste from windows to Evolution no longer works. > - copy&paste from linux to windows no longer works. > - When I press alt-2, I no longer get "@", but "2", Norwegian > keyboard. > - Evolution shows a disturbing error message upon startup: > 'Xlib: extension "RENDER" missing on display "localhost:10.0".' > - If I right click on my "Inbox" in Evolution, I no longer > get a menu as > I used to, but lots of error messages from Evolution(after which > Evolution is no longer responsive). > - Rendering in Office/Evolution is no longer double buffered, > and it is > considerably slower when rendering e.g. spreadsheets. > - I'm sure there are other problems, but it is a bit hard to take the > thing for a proper spin in its current state. > > Things tried: > > - compiled from source, but no difference in behaviour. > - downgraded to -46, same problem. > > The only thing that I can think of trying, is to wipe my CygWin > installation and reinstall from scratch. > > Øyvind > >
Re: OpenGL header problems
On Mon, 1 Mar 2004, Harold L Hunt II wrote: > As I mentioned in my email about enabling indirect OpenGL acceleration, > there are some problems when trying to link to -lopengl32. > > I tracked this down to problems with the way that > /usr/include/w32api/GL/gl.h decorates the function declarations for the > gl* functions. There are some collisions between the way that the > standard windows headers define WINGDIAPI and APIENTRY and the way that > gl.h expects them to be. > > However, the problem is a little trickier than just that: I added a call > to glPixelStorei in Xserver/hw/xwin/InitOutput.c (without #including any > opengl headers) and instead made my own prototype for glPixelStorei. If > I made it: > > void __stdcall glPixelStorei (unsigned int, int); > > then the linker would complain about how it had to fixup a reference to > glPixelStorei as [EMAIL PROTECTED] But that is exactly what the > __stdcall was supposed to do, so I am getting a little confused about > why the prototype was being ignored. > > I need an expert on __stdcall and w32api headers to give me a hand here. > Igor, I saw a post you made on this subject before, so I am counting > on you :) > > Once this little trick is solved we will have to figure out how to get > the proper headers in exports/include/GL/; that directory currently > getes some Mesa headers in it. I'm not sure if we can cleanly disable > that and point to the w32api OpenGL headers instead. > > Harold Harold, I'm by no means an expert, and I can't seem to reproduce it. Could you please post the exact gcc invocation that exhibits these symptoms? Looking at ld's info page, there are a couple of options that could be passed to the linker to modify this behavior. It may also be a problem with the import lib, for all I know... Is the build seeing the right libraries? Also, the GL/gl.h header doesn't actually use WINGDIAPI, and GLAPI is defined to be "extern" on Cygwin. Your declaration, however, seems correct. Just for kicks, could you try reverting to including GL/gl.h in Xserver/hw/xwin/InitOutput.c and run the build command for that file with a "-E" in CFLAGS? That should produce a preprocessed version of Xserver/hw/xwin/InitOutput.c, so you can see exactly how glPixelStorei is declared. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize that being between your mentor and his route to the bathroom is a major career booster." -- Patrick Naughton
xserv 4.3.0-48 problems
Note! This is *not* a complaint. I love CygWin + xfree86, and I chose to be at the bleeding edge because of it. Something terribly wrong happened when I upgraded to -48. Of course CygWin setup.exe upgraded oodles of other stuff as well There is a raft of regressions, so I suspect there must be a common cause. - copy&paste from windows to Evolution no longer works. - copy&paste from linux to windows no longer works. - When I press alt-2, I no longer get "@", but "2", Norwegian keyboard. - Evolution shows a disturbing error message upon startup: 'Xlib: extension "RENDER" missing on display "localhost:10.0".' - If I right click on my "Inbox" in Evolution, I no longer get a menu as I used to, but lots of error messages from Evolution(after which Evolution is no longer responsive). - Rendering in Office/Evolution is no longer double buffered, and it is considerably slower when rendering e.g. spreadsheets. - I'm sure there are other problems, but it is a bit hard to take the thing for a proper spin in its current state. Things tried: - compiled from source, but no difference in behaviour. - downgraded to -46, same problem. The only thing that I can think of trying, is to wipe my CygWin installation and reinstall from scratch. Øyvind ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1600 h 1200 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winScreenInit - dwWidth: 1600 dwHeight: 1200 winSetEngine - Multi Window or Rootless => ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winCreateBoundingWindowWindowed - User w: 1600 h: 1200 winCreateBoundingWindowWindowed - Current w: 1600 h: 1200 winGetWorkArea - Original WorkArea: 0 0 1166 1600 winGetWorkArea - Virtual screen is 2880 x 1200 winGetWorkArea - Virtual screen origin is 0, 0 winGetWorkArea - Primary screen is 1600 x 1200 winGetWorkArea - Adjusted WorkArea for multiple monitors: 0 0 1166 2880 winAdjustForAutoHide - Original WorkArea: 0 0 1166 2880 winAdjustForAutoHide - Adjusted WorkArea: 0 0 1166 2880 winCreateBoundingWindowWindowed - WindowClient w 2880 h 1166 r 2880 l 0 b 1166 t 0 winCreateBoundingWindowWindowed - Returning winAllocateFBShadowGDI - Creating DIB with width: 2880 height: 1200 depth: 32 winAllocateFBShadowGDI - Dibsection width: 2880 height: 1200 depth: 32 size image: 13824000 winAllocateFBShadowGDI - Created shadow stride: 2880 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winCreateDefColormap - Deferring to fbCreateDefColormap () null screen fn ReparentWindow null screen fn RestackWindow winFinishScreenInitFB - Calling winInitWM. InitQueue - Calling pthread_mutex_init InitQueue - pthread_mutex_init returned InitQueue - Calling pthread_cond_init InitQueue - pthread_cond_init returned winInitWM - Returning. winFinishScreenInitFB - returning winScreenInit - returning winMultiWindowXMsgProc - Hello winMultiWindowXMsgProc - Calling pthread_mutex_lock () winInitMultiWindowWM - Hello winInitMultiWindowWM - Calling pthread_mutex_lock () InitOutput - Returning. MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: "0414" (0414) (--) Using preset keyboard for "Norwegian" (414), type "4" Rules = "xfree86" Model = "pc105" Layout = "no" Variant = "(null)" Options = "(null)" Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from list! winPointerWarpCursor - Discarding first warp: 1440 600 winBlockHandler - Releasing pmServerStarted winBlockHandler - pthread_mutex_unlock () returned winMultiWindowXMsgProc - pthread_mutex_lock () returned. winMultiWindowXMsgProc - pthread_mutex_unlock () returned. winInitMultiWindowWM - pthread_mutex_lock () returned. winMultiWindowXMsgProc - DISPLAY=127.0.0.1:0.0 winInitMultiWindowWM - pthread_mutex_unlock () returned. winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0 winProcEstablishConnection - Hello winInitClipboard () winProcEstablishConnection - winInitClipboard returned. winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winClipboardProc - DISPLAY=127.0.0.1:0.0 winClipboardProc - XOpenDisplay () returned and successfully opened the display. winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning. winProcSetSelectionOwner - Clipboard not yet started, aborting. winProcSetSelectionOwner - Clipboard not yet started, aborting.
RE: mouse wheel support question
Here's something easy to try. Bring up the X server, then run "xev" and move the scroll-wheel. Do you see any Button 4 or Button 5 messages? If so, then the server supports them. If not, it doesn't. From: Daren Lim <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: mouse wheel support question Date: Fri, 20 Feb 2004 13:44:50 -0500 I've implemented a feature for an application that uses the mouse wheel on the Windows. I need to code it for XWindows. From what I have read so far the wheel sends mouse button presses of 4 and 5 in Xwindows. I'm not sure if trying to test through Cygwin is not letting me detect the messages in XWindows or if there is another reason. I found that for XFree86 4.2 "The mouse driver now has support for mouse wheel emulation." I tried xdyinfo | grep release to figure out which version of XFree86 I'm running... it returned "vender release number : 4020 So do I need to update my Xfree86 version ? Thanks, dAren _ Dream of owning a home? Find out how in the First-time Home Buying Guide. http://special.msn.com/home/firsthome.armx
Multi User with Xfree after a Terminal Server (windows)
Hi everybody ! I want to use cygwin under a clien terminal server with windows i install cygwin on a server modif cygwin.bat for multi user REM - @ECHO OFF d: chdir d:\cygwin\bin SET MAKE_MODE=UNIX set PATH=d:\cygwin\bin;%PATH% SET IS_CYGWIN=true set HISTSIZE=1200 set HOME=C:/Documents and Settings/%username%/CYGWIN set ENV=C:/Documents and Settings/%username%/CYGWIN/.bash_login SET D:/cygwin/tmp=D:/cygwin/%username%/tmp set CYGWIN=tty bash --login -i REM - and startxwin.bat REM - @echo off SET DISPLAY=127.0.0.1:0.0 REM REM The path in the CYGWIN_ROOT environment variable assignment assume REM that Cygwin is installed in a directory called 'cygwin' in the root REM directory of the current drive. You will only need to modify REM CYGWIN_ROOT if you have installed Cygwin in another directory. For REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will need REM to change \cygwin to \foo\bar\baz\cygwin. REM REM This batch file will almost always be run from the same drive (and REM directory) as the drive that contains Cygwin/XFree86, therefore you will REM not need to add a drive letter to CYGWIN_ROOT. For example, you do REM not need to change \cygwin to c:\cygwin if you are running this REM batch file from the C drive. REM SET CYGWIN_ROOT=\cygwin SET PATH=.;%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%PATH% REM REM Cleanup after last run. REM REM if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH if not exist %CYGWIN_ROOT%\%username%\tmp\.X11-unix\X0 goto CLEANUP-FINISH REM attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 REM del %CYGWIN_ROOT%\tmp\.X11-unix\X0 attrib -s %CYGWIN_ROOT%\%username%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\%username%\tmp\.X11-unix\X0 :CLEANUP-FINISH REM if exist %CYGWIN_ROOT%\%username%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix if exist %CYGWIN_ROOT%\%username%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\%username%\tmp\.X11-unix REM REM Startup the X Server, the twm window manager, and an xterm. REM REM Notice that the window manager and the xterm will wait for REM the server to finish starting before trying to connect; the REM error "Cannot Open Display: 127.0.0.1:0.0" is not due to the REM clients attempting to connect before the server has started, rather REM that error is due to a bug in some versions of cygwin1.dll. Upgrade REM to the latest cygwin1.dll if you get the "Cannot Open Display" error. REM See the Cygwin/XFree86 FAQ for more information: REM http://xfree86.cygwin.com/docs/faq/ REM REM The error "Fatal server error: could not open default font 'fixed'" is REM caused by using a DOS mode mount for the mount that the Cygwin/XFree86 REM fonts are accessed through. See the Cygwin/XFree86 FAQ for more REM information: REM http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-error-font-eof REM if "%OS%" == "Windows_NT" goto OS_NT REM Windows 95/98/Me echo startxwin.bat - Starting on Windows 95/98/Me goto STARTUP :OS_NT REM Windows NT/2000/XP/2003 echo startxwin.bat - Starting on Windows NT/2000/XP/2003 :STARTUP REM Brief descriptions of XWin-specific options: REM REM -screen scr_num [width height] REM Enable screen scr_num and optionally specify a width and REM height for that screen. REM Most importantly, any parameters specified before the first -screen REM parameter apply to all screens. Any options after the first -screen REM parameter apply only to the screen that precedes the parameter. REM Example: REM XWin -fullscreen -screen 0 -screen 1 -depth 8 -screen 2 REM All screens will be fullscreen, but screen 2 will be depth 8, while REM screens 0 and 1 will be the default depth (whatever depth Windows REM is currently running at). REM -multiwindow REM Start an integrated Windows-based window manager. Not to be used REM with -rootless nor -fullscreen. REM -rootless REM Use a transparent root window with an external window manager REM (such as twm). Not to be used with -multiwindow nor REM with -fullscreen. REM -fullscreen REM Use a window as large as possible on the primary monitor. REM -multiplemonitors REM Create a root window that covers all monitors on a REM system with multiple monitors. REM -clipboard REM Enable the integrated version of xwinclip. Do not use in REM conjunction with the xwinclip program. REM -depth bits_per_pixel REM Specify the screen depth to run at (in bits per pixel) using a REM DirectDraw-based engine in conjunction with the -fullscreen REM option, ignored if the -fullscreen option is not specified. REM By default, you will be using a DirectDraw based engine on any REM system that supports it. REM -unixkill REM Trap
Re: OpenGL header problems
On Mon, 1 Mar 2004, Harold L Hunt II wrote:
> However, the problem is a little trickier than just that: I added a call
> to glPixelStorei in Xserver/hw/xwin/InitOutput.c (without #including any
> opengl headers) and instead made my own prototype for glPixelStorei. If
> I made it:
>
> void __stdcall glPixelStorei (unsigned int, int);
>
> then the linker would complain about how it had to fixup a reference to
> glPixelStorei as [EMAIL PROTECTED] But that is exactly what the
> __stdcall was supposed to do, so I am getting a little confused about
> why the prototype was being ignored.
i've done some simple tests.
#include
#include
void __stdcall test_std(int x, int y);
void __fastcall test_fast(int x, int y);
void test(int x, int y);
void APIENTRY glPixelStorei (unsigned int, int);
int main(int argc, char *v[]) {
glPixelStorei(1,2);
test(1,2);
test_std(1,2);
test_fast(1,2);
return 0;
}
gcc test.c -lopengl32
/tmp/cc7SBe73.o(.text+0x45):test.c: undefined reference to [EMAIL PROTECTED]'
/tmp/cc7SBe73.o(.text+0x5c):test.c: undefined reference to [EMAIL PROTECTED]'
/tmp/cc7SBe73.o(.text+0x6e):test.c: undefined reference to [EMAIL PROTECTED]@8'
Without the APIENTRY on glPixelStorei it is
/tmp/cckNmsz4.o(.text+0x2e):test.c: undefined reference to `_glPixelStorei'
/tmp/cckNmsz4.o(.text+0x42):test.c: undefined reference to `_test'
/tmp/cckNmsz4.o(.text+0x56):test.c: undefined reference to [EMAIL PROTECTED]'
/tmp/cckNmsz4.o(.text+0x68):test.c: undefined reference to [EMAIL PROTECTED]@8'
> Once this little trick is solved we will have to figure out how to get
> the proper headers in exports/include/GL/; that directory currently
> getes some Mesa headers in it. I'm not sure if we can cleanly disable
> that and point to the w32api OpenGL headers instead.
A while ago I tried modifying the GL header shipped in xc/include. I had
to change the #if defined(WIN32) to if defined(WIN32) || defined(__CYGWIN__)
an I got the correct stdcall symbols ([EMAIL PROTECTED]) but got stuck with
some other undefined symbols (which were from a newer OpenGL API and not in
opengl32.dll)
bye
ago
--
[EMAIL PROTECTED]
http://www.gotti.org ICQ: 126018723
Chemnitzer Linux-Tag 2004 - 6. und 7. März 2004
http://www.tu-chemnitz.de/linux/tag
Re: Indirect OpenGL acceleration - New notes
On Sun, 29 Feb 2004, Harold L Hunt II wrote: > That should result in a compilation of the currently empty > GL/windows/indirect.c file, which will cause XWin.exe to fail to link > since it can't find the OpenGL functions. I am a little confused about > why XWin.exe fails to link on so many functions, since it seems that > -lopengl32 is providing those functions (look some of them up via 'nm -g > /usr/lib/w32api/opengl32.a | grep function_name')... I could use a few > pointers on what is happening there. the opengl32.dll implements an rather old OpenGL API (1.2 afair). But most vendors ship an opengl32.dll with their drivers which also implements the newer API. But those functions must be linked dynamicly. Another problem is the __stdcall issue. The windows dlls export symbols as [EMAIL PROTECTED] but normal GL headers define it as _glBitmap. This is due to the __stdcall call semantics. So all OpenGL definitions in GL/gl.h must be wrapped with the APIENTRY macros. OpenGL already has a GLAPI macros which simply must include the APIENTRY definition. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723 Chemnitzer Linux-Tag 2004 - 6. und 7. März 2004 http://www.tu-chemnitz.de/linux/tag
