Re: Upgrade woes.

2008-11-23 Thread Thorsten Kampe
* Eric Roode (Thu, 20 Nov 2008 06:21:37 -0500)
 I do check www.cygwin.com before doing (what I think is going to be) a
 routine upgrade. If there's nothing in the news there, I assume that
 what I'm getting is just an upgrade of existing packages that I
 already have installed. Is that such a foolish assumption?

The real problem is deeper: setup.exe is completely broken by design in 
respect to upgrading. If you choose Install from Internet it will 
silently choose to upgrade all your outdated packages without telling 
you or presenting you the automatically chosen packages. You have to 
click on View  Partial to be able to see that on the last screen. But 
who knows about that option - or who thinks of that?

You might simply want to install wget - and you end up with an update of 
and a completely broken X.

Yaakov did a hell of a job[1], but I think he knew that - and I think 
this is not exaggerated -  probably more than fifty percent of all 
existing Cygwin X installations would be more or less broken after the 
update.

Thorsten
[1] hell of a job meaning something positive


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/



Re: xmkmf creates wrong MANPATH entry in Makefiles

2008-11-23 Thread Dr. Volker Zell
 Yaakov  writes:

 Dr. Volker Zell wrote:
 When generating Makefiles with latest xmkmf the resulting Makefiles have
 some bogus entries.

 Fixed in xorg-cf-files-1.0.2-7.  But I'm curious, what are you building
 that still uses imake so extensively?

I had a couple of old x11 binaries lying around and tried recompiling
with latest X11R7.4

e.g.: xkeycaps

Ciao
  Volker

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/



Re: [ANNOUNCEMENT] Updated: xorg-cf-files-1.0.2-7

2008-11-23 Thread Dr. Volker Zell
 Yaakov  writes:

 The following packages have been updated in the Cygwin net distribution:
 *** xorg-cf-files-1.0.2-7

 This release fixes the definitions of MANPATH, FONTDIR, and ENCODINGSDIR.

Actually only FONTDIR and ENCODINGSDIR.are fixed.

The line with MANPATH comes from Imake.tmpl and is still 

  MANPATH = /usr/man
  
in the generated Makefiles.


This is from Imake.tmpl:

#ifdef ProjectRoot
#define ManDirectoryRoot Concat(ProjectRoot,/man)
#else
#define ManDirectoryRoot SystemManDirectory
#endif
#endif
#ifndef ManPath
#define ManPath ManDirectoryRoot
#endif
:
:
  MANPATH = ManPath /* top of manual page tree */


and  ProjectRoot seems to be set in site.def:

#ifndef ProjectRoot
#define ProjectRoot /usr
#endif
  
 Yaakov
 Cygwin/X

Ciao
  Volker

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/



pmconfig from proxymngr-1.0.1-1 references to deprecated /usr/X11R6 hirarchy

2008-11-23 Thread Dr. Volker Zell
Hi

See subject:

09:40 PM [531] cat /usr/lib/X11/proxymngr/pmconfig | grep /X11
lbx managed /usr/X11R6/bin/lbxproxy

Ciao
  Volker
  

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/



Re: GLX on XWin (was Re: X server 1.5.3-2 candidate)

2008-11-23 Thread Jon TURNEY

Yaakov (Cygwin Ports) wrote:

On Thu, Nov 13, 2008 at 07:12:42PM -0600, Yaakov (Cygwin Ports) wrote:

Unfortunately I don't have a linux box to experiment with... :-(

There's always http://www.virtualbox.org/ if you want to get a virtual
linux system.


Thanks!  I setup up VirtualBox, installed Ubuntu 8.10 and set up
openssh-server in the VM, and configured the VirtualBox NAT port
forwarding per the user manual.

I then logged in with ssh -Y two different times, once from a VT running
in a XWin with GLX enabled, and then from a VT in another XWin with GLX
manually disabled (-extension GLX).  With XWin GLX enabled, glxinfo
showed all the correct information, and glxgears worked, albeit
*extremely* slowly.  With XWin GLX disabled, of course neither worked,
giving Xlib errors that GLX extension was not available.  Other X11
programs worked in both cases, but interestingly the Ubuntu GTK+ engine
was used only on the server with GLX enabled.

So now I'm somewhat reassured that I did the right thing with GLX,
although I certainly remain open to further discussion if anyone is
having different results, or if there is insight into the speed issue.


Curiouser and curiouser.

ssh-ing to an Ubuntu 8.10 VM, I am able to reproduce your results:

$ glxinfo | grep -E version|vendor|rendering
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
client glx vendor string: SGI
client glx version string: 1.4
GLX version: 1.2
OpenGL vendor string: Mesa Project
OpenGL version string: 2.1 Mesa 7.2
OpenGL shading language version string: 1.10

and glxgears works fine.

(surely direct rendering: Yes can't be right here?)

ssh-ing to an Ubuntu 8.04 VM I happen to have lying around...

$ glxinfo | grep -E version|vendor|rendering
direct rendering: No (If you want to find out why, try setting
LIBGL_DEBUG=verbose)
server glx vendor string: SGI
server glx version string: 1.2
client glx vendor string: SGI
client glx version string: 1.4
GLX version: 1.2
OpenGL vendor string:
OpenGL version string:

(this is with my patch from [1] applied, otherwise it the server segfaults 
trying to read the OpenGL version string, which is occurring because the 
_glapi_Dispatch  points to glapi_noop_table, ie. we have no GL context!)


[1] http://cygwin.com/ml/cygwin-xfree/2008-11/msg00279.html

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/



Re: X server 1.5.3-2 candidate

2008-11-23 Thread Jon TURNEY

Yaakov (Cygwin Ports) wrote:

Of course, we only have the choice of the latter, but if swrast_dri.so
is missing, the GLX (and SGI-GLX) extension is disabled.  So I prepared
mesa-7.2-2 and tried building that module, but after fixing up the build
system, I found that it wasn't so simple.  The build only links the
module against libmesa.a (a convenience lib that becomes part of libGL),
leaving several undefined references:

_glapi_Context
_glapi_Dispatch
_glapi_add_dispatch
_glapi_check_multithread
_glapi_get_context
_glapi_get_dispatch_table_size
_glapi_noop_enable_warnings
_glapi_set_context
_glapi_set_dispatch
_glapi_set_warning_func

My understanding -- and I may be wrong -- is that these symbols are left
undefined on purpose, because they are meant to be resolved by whatever
loads the module.  That may be a DRI-enabled libGL, an X server, etc.
But that doesn't work for us because DLLs must have all references
resolved at link time.

So what to do?  All the X servers have GLX support, but if I were to
resolve these symbols against e.g. XWin, then the other servers will
crash trying to load it.  (Yes, I tried it.)  So while our libGL doesn't
actually use the module, the only neutral solution was to link against
all of libGL instead of just part of it, and at least on the surface it
appears to work.


After doing some tracing into the server, and looking at the difference 
between the successful and failing remote cases, it seems that we really do 
have a direct context in the success case, whereas in the failure case we have 
an indirect context.


I think that due to your trick of linking dri_swrast.so with libGL, we have 
some duplicate symbols, as libGL provides glapi_Dispatch itself, but it's also 
defined in the server GLX code.


I think maybe creating the indirect context (which occurs deep inside swrast) 
isn't setting the instance of this symbol which the GLX functions dispatch 
through when we have an indirect context, instead they are dispatching through 
glapi_noop_table, hence the crash.


I tried to work around this by removing the files with duplicate symbols 
(glpapi.c and glthread.c) from the GLX code and linking XWin with libGL as 
well, which seems to work as far as running glgears goes...


(I still need to check that these files are actually functionally identical 
between xserver/GLX and mesa/glapi)


Attached is a rough patch

Cygwin/X: GLX crash workaround

Remove GL dispatcher symbols which are defined in libGL, and link 
with libGL for them instead (as dri_swrast.so is linked with libGL)

Paper over the cracks. Avoid a crash when we have a broken context.

Turn on GLX null context debugging

---
 xserver/glx/Makefile.am  |2 --
 xserver/glx/single2.c|3 +++
 xserver/hw/vfb/Makefile.am   |7 ++-
 xserver/hw/xnest/Makefile.am |7 ++-
 xserver/hw/xwin/InitOutput.c |   24 
 xserver/hw/xwin/Makefile.am  |8 +++-
 6 files changed, 46 insertions(+), 5 deletions(-)

Index: xorg-server-1.5.3/xserver/glx/single2.c
===
--- xorg-server-1.5.3.orig/xserver/glx/single2.c
+++ xorg-server-1.5.3/xserver/glx/single2.c
@@ -341,6 +341,9 @@ int DoGetString(__GLXclientState *cl, GL
 string = (const char *) CALL_GetString( GET_DISPATCH(), (name) );
 client = cl-client;
 
+if (string == NULL)
+  string = ;
+
 /*
 ** Restrict extensions to those that are supported by both the
 ** implementation and the connection.  That is, return the
Index: xorg-server-1.5.3/xserver/hw/xwin/InitOutput.c
===
--- xorg-server-1.5.3.orig/xserver/hw/xwin/InitOutput.c
+++ xorg-server-1.5.3/xserver/hw/xwin/InitOutput.c
@@ -134,6 +134,9 @@ const char *
 winGetBaseDir(void);
 #endif
 
+static
+void glx_debugging(void);
+
 /*
  * For the depth 24 pixmap we default to 32 bits per pixel, but
  * we change this pixmap format later if we detect that the display
@@ -1045,6 +1048,8 @@ InitOutput (ScreenInfo *screenInfo, int 
* Apply locale specified in LANG environment variable.
*/
   setlocale (LC_ALL, );
+
+  glx_debugging();
 }
 #endif
 
@@ -1127,3 +1132,22 @@ winCheckDisplayNumber ()
 
   return TRUE;
 }
+
+/* GLX debugging helpers */
+#include ../glx/glapi.h
+
+static
+void warn_func(void * p1, const char *format, ...) {
+  va_list v;
+  va_start(v, format);
+  vfprintf(stderr, format, v);
+  va_end(v);
+  fprintf(stderr,\n);
+}
+
+static
+void glx_debugging(void)
+{
+  _glapi_set_warning_func(warn_func);
+  _glapi_noop_enable_warnings(TRUE);
+}
Index: xorg-server-1.5.3/xserver/glx/Makefile.am
===
--- xorg-server-1.5.3.orig/xserver/glx/Makefile.am
+++ xorg-server-1.5.3/xserver/glx/Makefile.am
@@ -38,10 +38,8 @@ glapi_sources =  \
dispatch.h  \

PATCH: Fix Numlock/Capslock synchronization

2008-11-23 Thread Jon TURNEY


xorg-server-1.5.3-3 temporary disabled the NumLock/CapsLock synchronization
between X and windows as it was badly broken. (In 1.5.3-2, if NumLock or 
Capslock was on, it would toggle everytime an X window gained focus)


This patch repairs that synchronization, so the X server's idea about these 
locking keyboard modes is updated correctly when an X window regains focus
Cygwin: Fix the keyboard mode key synchronization

Fix the code which generates fake keypresses when an X window gains focus to
bring the X servers idea of the state of these mode keys in to sync with any
changes which might have taken place whilst unfocused.

With MPX changes, the place the server stores the current mode key state has
changed, appears they are now only held on the virtual core keyboard.

---
 xserver/hw/xwin/winkeybd.c |   15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

Index: xorg-server-1.5.3/xserver/hw/xwin/winkeybd.c
===
--- xorg-server-1.5.3.orig/xserver/hw/xwin/winkeybd.c
+++ xorg-server-1.5.3/xserver/hw/xwin/winkeybd.c
@@ -49,10 +49,6 @@
 
 static Bool g_winKeyState[NUM_KEYCODES];
 
-/* Stored to get internal mode key states.  Must be read-only.  */
-static unsigned short const *g_winInternalModeKeyStatesPtr = NULL;
-
-
 /*
  * Local prototypes
  */
@@ -209,7 +205,6 @@ winKeybdBell (int iPercent, DeviceIntPtr
 static void
 winKeybdCtrl (DeviceIntPtr pDevice, KeybdCtrl *pCtrl)
 {
-  g_winInternalModeKeyStatesPtr = (pDevice-key-state);
 }
 
 
@@ -295,19 +290,15 @@ winKeybdProc (DeviceIntPtr pDeviceInt, i
 }
 }
 #endif
-
-  g_winInternalModeKeyStatesPtr = (pDeviceInt-key-state);
   break;
   
 case DEVICE_ON: 
   pDevice-on = TRUE;
-  g_winInternalModeKeyStatesPtr = (pDeviceInt-key-state);
   break;
 
 case DEVICE_CLOSE:
 case DEVICE_OFF: 
   pDevice-on = FALSE;
-  g_winInternalModeKeyStatesPtr = NULL;
   break;
 }
 
@@ -369,7 +360,7 @@ winRestoreModeKeyStates ()
   unsigned short   internalKeyStates;
 
   /* X server is being initialized */
-  if (!g_winInternalModeKeyStatesPtr)
+  if (!inputInfo.keyboard)
 return;
 
   /* Only process events if the rootwindow is mapped. The keyboard events
@@ -382,7 +373,9 @@ winRestoreModeKeyStates ()
 mieqProcessInputEvents ();
   
   /* Read the mode key states of our X server */
-  internalKeyStates = *g_winInternalModeKeyStatesPtr;
+  /* (stored in the virtual core keyboard) */
+  internalKeyStates = inputInfo.keyboard-key-state;
+  winDebug(winRestoreModeKeyStates: state %d\n, internalKeyStates);
 
   /* 
* NOTE: The C XOR operator, ^, will not work here because it is

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: pmconfig from proxymngr-1.0.1-1 references to deprecated /usr/X11R6 hirarchy

2008-11-23 Thread Yaakov (Cygwin Ports)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dr. Volker Zell wrote:
 09:40 PM [531] cat /usr/lib/X11/proxymngr/pmconfig | grep /X11
 lbx managed /usr/X11R6/bin/lbxproxy

lbxproxy is obsolete and long gone, so this is harmless.


Yaakov
Cygwin/X
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkkp8MUACgkQpiWmPGlmQSOdUACfeptU0Wd9hLYgBPlt9MO4Useu
fDoAn3oC5aLM0RbMj/sf6359BsIb6W+Q
=ZUwj
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/



Re: [ANNOUNCEMENT] Updated: xorg-cf-files-1.0.2-7

2008-11-23 Thread Yaakov (Cygwin Ports)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dr. Volker Zell wrote:
 Actually only FONTDIR and ENCODINGSDIR are fixed.

My true feelings about imake are simply not printable.  What other
package this size would take 8 releases to (maybe) get right?

At least cygport takes care of /usr/man - /usr/share/man, which perhaps
is why I didn't notice this when building nas.

Thanks again for the report,


Yaakov
Cygwin/X
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkkp8NAACgkQpiWmPGlmQSOttQCgjG9PQob6xy/x6gR/vQRWijUa
MLcAoNGsnXp+rkSuTn9ITAfLVYYj8jmq
=88++
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/



Re: Xinerama

2008-11-23 Thread Jon TURNEY

Yaakov (Cygwin Ports) wrote:

Looking further into Xinerama, I think I brushed it off too early.  It
is *very* widely supported[1], and while XRandR is supposed to replace
it, actual implementation and usage may be some time off.

I also think that there may be some potential flaws in windowed
multiplemonitor mode that Xinerama support would fix.  While the current
behaviour makes sense in multiwindow mode, I'm not sure that it does in
windowed mode.  Since X window managers have no sense of what is really
happening in that case, placing a dialog in the centre of the X display
could easily land on the seam between two monitors.  (I know, I tried
it.)  With Xinerama support, however, they would have the necessary
information to DTRT.


Actually, -multiwindow mode is equally deficient.  If we presented the the 
monitors as separate screens to X (rather than one large screen which spans 
the entire Windows virtual desktop), X apps could do sensible placement with 
their windows also)



I think that the implementation may be simpler than we thought.  To see
the situation as it stands:

1) Build and install xineramaproto;
2) Remove the --disable-xinerama flag from xorg-server and rebuild;
3) Build and install libXinerama;
4) Remove --without-xinerama from xdpyinfo and rebuild.


This part is fine with me


For this example, on my single-head system I launched XWin with:

X +xinerama -nodecoration -screen 0 640x480 -screen 1 640x480+640+0

This gives :0.0 and :0.1 side-by-side.  If you have a multihead system,
you could just as easily run:

X +xinerama -nodecoration -screen 0 @1 -screen 1 @2

Now, let's see what xdpyinfo has to say:

$ xdpyinfo -ext XINERAMA | tail
[snip]
XINERAMA version 1.1 opcode: 128
  head #0: 640x480 @ 0,0
  head #1: 640x480 @ 0,0

AFAICS that implies that the X geometry overlaps.  Indeed, if you run an
X client, both screens show exactly the same thing, but only screen 0
accepts input.  Compare this to -xinerama, where each screen is
completely independent from the other, as if you were running :0 and :1.


Yes, I think what I was trying to say back here [1], is that there isn't much 
value in enabling Xinerama until there is code in the server to set the 
monitor layout somehow.



On Linux, after defining the Screens, you must define their relationship
in ServerLayout, e.g.[2]:

Section ServerLayout
Identifier  Simple Layout
Screen Screen 2
Screen Screen 1 RightOf Screen 2
InputDevice Mouse1 CorePointer
InputDevice Keyboard1 CoreKeyboard
EndSection

So if we were to add additional parameters to the -screen flag, e.g.:

X +xinerama -nodecoration -screen 0 640x480 -screen 1 640x480+640+0
- -rightof 0


The problem is that these native windows containing server screens are 
movable!  Xinerama can't deal with dynamic changes to the layout (whereas I 
think XRandR will be able to)


I'm not sure there's a need for any additional command line parameters.  We 
can imply that screen 1 (in your example) is to the right of screen 0 from the 
 co-ordinates it's given.


In -fullscreen -multimonitor or -multiwindow mode, we could use the 
Windows GetMonitorInfo() API to discover the monitor geometry (it's perhaps an 
acceptable limitation that the server will need to be restarted to notice any 
changes to this)


[1]
http://sourceforge.net/mailarchive/forum.php?thread_name=48F0B732.2040100%40dronecode.org.ukforum_name=cygwin-ports-general


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/



[ANNOUNCEMENT] Updated: {aalib/libaa1/aalib-devel}-1.4rc5-3: An ascii art library

2008-11-23 Thread Dr. Volker Zell
Hi

New versions of 'aalib/libaa1/aalib-devel' have been uploaded to a server near 
you.


Cygwin NEWS:


 o Recompiled against latest X11R7.4


DESCRIPTION:

AA-lib is a low level gfx library just as many other libraries are.
The main difference is that AA-lib does not require graphics device. In
fact, there is no graphical output possible. AA-lib replaces those
old-fashioned output methods with powerful ascii-art renderer.


UPDATE:
===
To update your installation, click on the Install Cygwin now link on the
http://cygwin.com/ web page.  This downloads setup.exe to your system.
Save it and run setup, answer the questions and pick up 'aalib' from
the 'Libs' category (it should already be selected).

DOWNLOAD:
=
Note that downloads from sources.redhat.com (aka cygwin.com) aren't
allowed due to bandwidth limitations.  This means that you will need to
find a mirror which has this update, please choose the one nearest to you:
http://cygwin.com/mirrors.html

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

--
Dr. Volker Zell
volunteer cygwin aalib maintainer

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=
To unsubscribe to the cygwin-announce mailing list, look at the
List-Unsubscribe:  tag in the email header of this message.  Send email
to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/



Re: X server 1.5.3-2 candidate

2008-11-23 Thread Yaakov (Cygwin Ports)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jon TURNEY wrote:
 After doing some tracing into the server, and looking at the difference
 between the successful and failing remote cases, it seems that we really
 do have a direct context in the success case, whereas in the failure
 case we have an indirect context.
 
 I think that due to your trick of linking dri_swrast.so with libGL, we
 have some duplicate symbols, as libGL provides glapi_Dispatch itself,
 but it's also defined in the server GLX code.
 
 I think maybe creating the indirect context (which occurs deep inside
 swrast) isn't setting the instance of this symbol which the GLX
 functions dispatch through when we have an indirect context, instead
 they are dispatching through glapi_noop_table, hence the crash.
 
 I tried to work around this by removing the files with duplicate symbols
 (glpapi.c and glthread.c) from the GLX code and linking XWin with libGL
 as well, which seems to work as far as running glgears goes...

No regression with my Ubumtu 8.10 VM.

 (I still need to check that these files are actually functionally
 identical between xserver/GLX and mesa/glapi)

I checked, and they are practically identical.

 Attached is a rough patch

I modified the build system part of that patch, and added it and the
NumLock/CapsLock sync patch to SVN.  Could you please test 1.5.3-4?


Yaakov
Cygwin/X
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkkqERYACgkQpiWmPGlmQSN9AgCeP1+0ikWowKAzwM0j5dHGEfXy
NjgAn3PO2/HnE1Mgf78QWFsz+54rhFEl
=kxj9
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/



Re: Cygwin X-Win scripting help

2008-11-23 Thread tbishop

Jon,

Of course I did that :) :) :)  It doesn't work and I am lost, that's
all the opening of several windows at least they pop up confuses me
until there is only one.. and it's like an empty Cygwin window...
and the X session is dead,, who knows like we haven't heard Vista
is full of bugs :( :( :(  any more ideas please let me know..

Tom




Jon TURNEY wrote:
 
 tbishop wrote:
 I have used XP and have used this script for a long time as a bat file to
 get
 to my UNIX box:
 ===
 @echo off
 
 
 C:
 chdir C:\cygwin\bin
 
 bash --login -c \XWin.exe -query 128.49.000.44 -from 128.23.77.149
 
 for some reason on Vista it seems NOT to work the same, way, it opens up
 3
 command
 tools, the 3rd one blank and a blank Xsession... nothing on the screen
 but
 an X
 in the middle does anyone have any ideas???
 
 If this is a new computer with Vista on it you'll need to change the
 -from 
 IP address to match.
 
 
 --
 Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
 Problem reports:   http://cygwin.com/problems.html
 Documentation: http://x.cygwin.com/docs/
 FAQ:   http://x.cygwin.com/docs/faq/
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Cygwin-X-Win-scripting-help-tp20614082p20655494.html
Sent from the cygwin-xfree mailing list archive at Nabble.com.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/



RE: where is /usr/X11R6/lib/libGLw.a on cygwin?

2008-11-23 Thread Phan, Linh H
Hi Marco,

 I went to setup-1.7.exe to get the libGLw-devel.  setup put libGLw.dll in
/usr/lib/libGLw.dll.a but it also put all these files:

XWin.exe  cygSM-6.dll   cygXaw3d-7.dllcygXi-6.dll  cygXrender-1.dll
cygGL-1.dll   cygUil-2.dll  cygXcursor-1.dll  cygXm-2.dll  cygXt-6.dll
cygGLU-1.dll  cygX11-6.dll  cygXdmcp-6.dllcygXmu-6.dll cygXtst-6.dll
cygGLw-1.dll  cygXau-6.dll  cygXext-6.dll cygXmuu-1.dllcygfontenc-1.dll
cygICE-6.dll  cygXaw-7.dll  cygXfixes-3.dll   cygXpm-4.dll cygxkbfile-1.dll
cygMrm-2.dll  cygXaw-8.dll  cygXft-2.dll  cygXrandr-2.dll

in /usr/bin and removed it from my /usr/X11R6/bin.  It also removed alot of 
other
files from /usr/X11R6/bin (eg glxgears) and /usr/X11R6/lib.  Luckily I had 
another
working cygwin system and copied the glxgears from there to the updated cygwin
system but then the glxgears didn't work.  I finally had to copy all files from
/usr/X11R6/{bin,lib} on my working cygwin to my updated cygwin and then things
work again.  The last mirror I used to update cygwin was 
http://mirrors.xmission.com.
Why are the mirrors not consistent in that some put files in /usr/bin and some 
in
/usr/X11R6/bin?  What is a good mirror that you usually use?

Thank you Marco,

Linh

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marco Atzeri
Sent: Saturday, November 22, 2008 2:14 PM
To: cygwin-xfree@cygwin.com
Subject: Re: where is /usr/X11R6/lib/libGLw.a on cygwin?

--- Phan, Linh H  ha scritto:

 Hi,

   I am getting this undefined reference to
 `_glwM2DrawingAreaWidgetClass' error:

 $ g++ componentTest.o libInventorWidget.a
 -lInventorXt -lInventor -lstdc++ -L/usr/X11R6/lib
 -L/usr/local/lib -limage -ljpeg -liconv -lFL
 -lfreetype -lGL -lGLU -lXm -lXt -lXext -lXi -lX11
 -lm   -o componentTest

libInventorWidget.a(MyTextureEd.o):MyTextureEd.c++:(.text+0x6b3a):
 undefined reference to
 `_glwM2DrawingAreaWidgetClass'

 and it is due to this line in MyTextureEd.c++:

 Widget glx = XtCreateWidget(paletteGLX,
 glwMDrawingAreaWidgetClass, parent, args, n);

 glwMDrawingAreaWidgetClass is defined in:
 /usr/X11R6/include/GL/GLwDrawA.h:#  define
 glwMDrawingAreaWidgetClass
 glwM2DrawingAreaWidgetClass

 I know on linux glwM2DrawingAreaWidgetClass is
 defined in /usr/X11R6/lib/libGLw.a.
 Does any one know where /usr/X11R6/lib/libGLw.a is
 on cygwin-1.7?


For this question
http://cygwin.com/packages/
is your friend.

I presume replaced by libGLw.dll.a

http://cygwin.com/cgi-bin2/package-cat.cgi?file=libGLw-devel%2FlibGLw-devel-7.2-2grep=libGLw

libGLw-devel: X11 OpenGL libraries
(widgets libdevel)
(installed binaries and support files)

usr/include/GL/GLwDrawA.h
usr/include/GL/GLwMDrawA.h
usr/lib/libGLw.dll.a
usr/lib/pkgconfig/glw.pc


 Thank you,

 Linh


Regards
Marco





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/



Re: where is /usr/X11R6/lib/libGLw.a on cygwin?

2008-11-23 Thread Yaakov (Cygwin Ports)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Phan, Linh H wrote:
  I went to setup-1.7.exe to get the libGLw-devel.  setup put libGLw.dll in
 /usr/lib/libGLw.dll.a but it also put all these files:
 in /usr/bin and removed it from my /usr/X11R6/bin.  It also removed alot of 
 other
 files from /usr/X11R6/bin (eg glxgears) and /usr/X11R6/lib.  Luckily I had 
 another
 working cygwin system and copied the glxgears from there to the updated cygwin
 system but then the glxgears didn't work.  I finally had to copy all files 
 from
 /usr/X11R6/{bin,lib} on my working cygwin to my updated cygwin and then things
 work again.  The last mirror I used to update cygwin was 
 http://mirrors.xmission.com.
 Why are the mirrors not consistent in that some put files in /usr/bin and 
 some in
 /usr/X11R6/bin?  What is a good mirror that you usually use?

Please read the upgrade announcement:

http://cygwin.com/ml/cygwin-xfree-announce/2008-11/msg0.html


Yaakov
Cygwin/X
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkkqXIkACgkQpiWmPGlmQSN5aQCcCzGaIs6kTasq66XUkEruoDvE
YvkAn1JQLIy3hIrpEeuJ89C1xdTpVvk0
=oQuQ
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/