Re: ghostscript weirdness

2004-09-05 Thread Tomasz Rojek
> You also need to make sure that /usr/X11R6/bin/gs gets picked up before
> /usr/bin/gs (i.e., that /usr/X11R6/bin is in your PATH before /usr/bin --
> which is usually done by default by /etc/profile.d/00xorg-x11-base.sh).
I have encountered the same problem - my PATH contains /usr/bin before
/usr/X11R6/bin. According to above info from Igor I run
/etc/profile.d/00xorg-x11-base.sh. This did not help (I closed old rxvt
session and opened new one). Of course manual fix to PATH solves the
problem.

-- 
Greetings

Tomasz Rojek





X11 becomes unresponsive. VERY unresponsive.

2004-09-05 Thread David Arnstein
Hello,
I have a problem with cygwin-x11 on my home machine, which runs 
Windows 2000 s.p. 4.

All X11 windows become unresponsive.  Really unresponsive. The windows 
don't repaint when exposed.  Right mouse button (context) menus do not 
pop up.

Earlier today, I reinstalled ALL of my cygwin packages, it did not help.
Just now, I started X11 and I had one xterm running bash.  X11 was 
working OK, as far as I could tell.  I left the computer for 10 
minutes; so it was completely idle.  When I returned, X11 was in the 
unresponsive state.

How can I debug this problem?  I close this e-mail with the contents 
of my /tmp/XWin.log file.  Is there anything else I can provide? 
Thanks for any suggestions!

Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 6.7.0.0-12
Contact: [EMAIL PROTECTED]
XWin was started with the following command line:
XWin -multiwindow -clipboard -silent-dup-error
ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1600 h 1200
winInitializeDefaultScreens - Returning
winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
(II) XF86Config is not supported
(II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more 
information
winPrefsLoadPreferences: /cygdrive/j/Users/David/.XWinrc
LoadPreferences:  .XWinrc Loaded
winDetectSupportedEngines - Windows NT/2000/XP
winDetectSupportedEngines - DirectDraw installed
winDetectSupportedEngines - DirectDraw4 installed
winDetectSupportedEngines - Returning, supported engines 0007
winSetEngine - Multi Window or Rootless => ShadowGDI
winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits 
per pixel
winAllocateFBShadowGDI - Creating DIB with width: 1600 height: 1166 
depth: 32
winFinishScreenInitFB - Masks: 00ff ff00 00ff
winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 
24 bpp 32
null screen fn ReparentWindow
null screen fn RestackWindow
InitQueue - Calling pthread_mutex_init
InitQueue - pthread_mutex_init returned
InitQueue - Calling pthread_cond_init
InitQueue - pthread_cond_init returned
winInitMultiWindowWM - Hello
winMultiWindowXMsgProc - Hello
winInitMultiWindowWM - Calling pthread_mutex_lock ()
winMultiWindowXMsgProc - Calling pthread_mutex_lock ()
(--) Setting autorepeat to delay=500, rate=31
(--) winConfigKeyboard - Layout: "0409" (0409)
(--) Using preset keyboard for "English (USA)" (409), type "81"
Rules = "xorg" Model = "pc105" Layout = "us" Variant = "(null)" 
Options = "(null)"
Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, 
removing from list!
winPointerWarpCursor - Discarding first warp: 800 583
winInitMultiWindowWM - pthread_mutex_lock () returned.
winProcEstablishConnection - Hello
winInitClipboard ()
winProcEstablishConnection - winInitClipboard returned.
winClipboardProc - Hello
DetectUnicodeSupport - Windows NT/2000/XP
winInitMultiWindowWM - pthread_mutex_unlock () returned.
winClipboardProc - DISPLAY=127.0.0.1:0.0
winMultiWindowXMsgProc - pthread_mutex_lock () returned.
winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0
winMultiWindowXMsgProc - pthread_mutex_unlock () returned.
winMultiWindowXMsgProc - DISPLAY=127.0.0.1:0.0
winClipboardProc - XOpenDisplay () returned and successfully opened 
the display.
winMultiWindowXMsgProc - XOpenDisplay () returned and successfully 
opened the display.
winInitMultiWindowWM - XOpenDisplay () returned and successfully 
opened the display.


Re: ghostscript weirdness

2004-09-05 Thread Igor Pechtchanski
On Mon, 6 Sep 2004, sven geier wrote:

> Igor Pechtchanski  cs.nyu.edu> writes:
>
> >You also need to make sure that /usr/X11R6/bin/gs gets picked up before
> >/usr/bin/gs (i.e., that /usr/X11R6/bin is in your PATH before /usr/bin --
> >which is usually done by default by /etc/profile.d/00xorg-x11-base.sh).
>
> So I finally has a little time to look at this, and there's a lot of things
> broken here apparently. In sequence:
>
> 1)
> [snip]
> IOW somewhere during startup the X11 directories get put in the path,
> then some other stuff gets prepended or such, then the order is wrong
> but the 00xorg file never does anything about this.
>
> Bug.

Quite possibly.  .

> 2)
> [snip]
>
> I start "gs" by hand and Windows throws me an alert box that the
> application cannot run because "libICE.dll" was not found. A bit of
> googling finds that this is supposedly in /usr/X11R6/bin, but a 'find
> /usr/X11R6 -name libICE\* -a - print" on my disk finds it in .../lib:
>
> [18:59] Sven [ice:X11R6/bin] > find /usr/X11R6 -name libICE\* -a -print
> /usr/X11R6/lib/libICE-6.dll.a
> /usr/X11R6/lib/libICE.dll.a

Wrong.  Niether of the above is a DLL -- they're what's called "import
libraries" that allow linking with a DLL.  The DLL may not even be named
"libICE.dll", FWIW (and isn't, in the newer package versions).

> Maybe that was changed recently?
> Bug?

I believe this is a bug in ghostscript-x11 dependencies.  The gs
executable was linked against an older version of the ICE library, back
when it was still provided under the name of libICE.dll.  The Cygwin
package search page at  (which is where you
should have gone instead of searching your hard drive, which only works
when the package is already installed on your system) shows that
libICE.dll is in the XFree86-lib-compat package, and the ghostscript-x11
package should depend on that.  It doesn't, so the required package isn't
installed automatically.  The workaround is to install the package
yourself.

> 3)
>
> At this point I'm a little puzzled what to do next.
>
> - I include /usr/X11R6/lib in my $PATH:
>  No effect.
> - I symlink "ln -s /usr/X11R6/lib/libICE-6.dll.a /usr/X11R6/bin/libICE.dll.a":
>  No effect.

As I said above, ".dll" != ".dll.a".
Also FYI, symlinks to DLLs don't work in any case, since the Windows
dynamic loader doesn't grok Cygwin symlinks.

> - I *copy* the damn dll into /usr/X11R6/bin :
>  No effect.

It would have worked if you'd copied the actual DLL instead of the import
library.

> 4)
>
> I am now going to uninstall everything related to X and/or ghostscript
> and then reinstall from scratch. But I think something got broken there
> somewhere recently. During the transition to Xorg, maybe? Can someone
> confirm or deny that ghostscript actually works when it is part of a
> completely fresh, new, pristine cygwin install that is performed right
> now (i.e. doesn't run on some legacy files that happen to be floating
> around)?

I believe it shouldn't work on a pristine install, but since I don't use
it, I'll let someone else confirm or deny it.  I also think that once
ghostscript-x11 is made to depend on XFree86-lib-compat, it likely *will*
work on a pristine install.  You can check all the DLLs that are required
for the gs.exe in ghostscript-x11 by running "cygcheck
/usr/X11R6/bin/gs.exe".

HTH,
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!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw


Re: ghostscript weirdness

2004-09-05 Thread sven geier
Igor Pechtchanski  cs.nyu.edu> writes:

>You also need to make sure that /usr/X11R6/bin/gs gets picked up before
>/usr/bin/gs (i.e., that /usr/X11R6/bin is in your PATH before /usr/bin --
>which is usually done by default by /etc/profile.d/00xorg-x11-base.sh).

So I finally has a little time to look at this, and there's a lot of things 
broken here apparently. In sequence:

1)

[18:48] Sven [box:~] > echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/system32:/cygdri
ve/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem


Alright, it's there but not at the beginning. Why? I check out the named file 
(/etc/profile.d/00xorg-x11-base.sh) and it looks like this

  eval "/bin/echo ${PATH} | /bin/grep -q /usr/X11R6/bin"
  if ( $status ) then
# Path is not already in PATH, prepend it to PATH
setenv PATH "/usr/X11R6/bin:${PATH}"
  endif

IOW somewhere during startup the X11 directories get put in the path, then some 
other stuff gets prepended or such, then the order is wrong but the 00xorg file 
never does anything about this. 

Bug.

2) 

OK, no problem so far. I simply comment out the "if ..." parts and force the 
X11 element to the beginning of my $PATH (so it occurs twice, so who cares, 
right?). I start a new xterm (with and without "-l" to be sure) and the path 
seems to come out alright. 

[18:56] Sven [box:~] > echo $PATH
/usr/X11R6/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/s
ystem32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem

I start "gs" by hand and Windows throws me an alert box that the application 
cannot run because "libICE.dll" was not found. A bit of googling finds that 
this is supposedly in /usr/X11R6/bin, but a 'find /usr/X11R6 -name libICE\* -a -
print" on my disk finds it in .../lib:

[18:59] Sven [ice:X11R6/bin] > find /usr/X11R6 -name libICE\* -a -print
/usr/X11R6/lib/libICE-6.dll.a
/usr/X11R6/lib/libICE.dll.a

Maybe that was changed recently?

Bug?

3)

At this point I'm a little puzzled what to do next. 

- I include /usr/X11R6/lib in my $PATH: 
 No effect.
- I symlink "ln -s /usr/X11R6/lib/libICE-6.dll.a /usr/X11R6/bin/libICE.dll.a":
 No effect.
- I *copy* the damn dll into /usr/X11R6/bin :
 No effect.

4) 

I am now going to uninstall everything related to X and/or ghostscript and then 
reinstall from scratch. But I think something got broken there somewhere 
recently. During the transition to Xorg, maybe? Can someone confirm or deny 
that ghostscript actually works when it is part of a completely fresh, new, 
pristine cygwin install that is performed right now (i.e. doesn't run on some 
legacy files that happen to be floating around)?

Thanks for hints in advance...

-- S 



Re: gtk2-x11-devel is missing gdk/gdkwin32.h

2004-09-05 Thread Yaakov Selkowitz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Schulman wrote:
| I don't know if this file has been deliberately excluded from the package
| (version 2.4.4-1), but I needed it in order to build LablGtk2.  I had
to go
| and fetch it from http://www.gimp.org/~tml/gimp/win32/gtk+-dev-2.4.7.zip.
No, it's a problem with lablgtk2.  gdk/gdkwin32.h is only for the Win32
gdktarget; the Cygwin gtk2 packages use X11 and hence use gdk/gdkx.h.
For some reason, lablgtk2 assumes that Cygwin uses Win32.  The attached
patch will fix that and the install procedure.
Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBO5e/piWmPGlmQSMRAi3SAKD0zIMFgR3bZbi1JS/ypwE44Jrh/ACeJejc
WM3FyIdGPBzl3syzYq9rY94=
=ayHX
-END PGP SIGNATURE-
diff -urN -x .build -x .inst -x .sinst lablgtk-2.4.0-orig/src/Makefile 
lablgtk-2.4.0/src/Makefile
--- lablgtk-2.4.0-orig/src/Makefile 2004-07-15 04:43:35.0 -0400
+++ lablgtk-2.4.0/src/Makefile  2004-09-05 18:44:19.92450 -0400
@@ -206,34 +206,34 @@
 
 install:
mkdir -p "$(INSTALLDIR)" "$(BINDIR)" "$(DLLDIR)"
-   cp $(ALLOBJS:.cmo=.cmi) $(THOBJS:.cmo=.cmi) "$(INSTALLDIR)"
-   cp -p *.mli "$(INSTALLDIR)"
-   cp -p $(ALLOBJS:.cmo=.ml) $(ALLTHOBJS:.cmo=.ml) "$(INSTALLDIR)"
-   cp $(MLLIBS) $(THOBJS) $(INITOBJS) $(THINITOBJS) "$(INSTALLDIR)"
-   cp $(CLIBS) "$(INSTALLDIR)"
+   install $(ALLOBJS:.cmo=.cmi) $(THOBJS:.cmo=.cmi) "$(INSTALLDIR)"
+   install *.mli "$(INSTALLDIR)"
+   install $(ALLOBJS:.cmo=.ml) $(ALLTHOBJS:.cmo=.ml) "$(INSTALLDIR)"
+   install $(MLLIBS) $(THOBJS) $(INITOBJS) $(THINITOBJS) "$(INSTALLDIR)"
+   install $(CLIBS) "$(INSTALLDIR)"
cd "$(INSTALLDIR)" && $(RANLIB) $(CLIBS)
-   cp varcc$(XE) propcc$(XE) "$(INSTALLDIR)"
+   install varcc$(XE) propcc$(XE) "$(INSTALLDIR)"
if test $(THREADS_LIB) != system || test $(HAS_DLL_SUPPORT) != yes; \
-  then cp lablgtktop$(XE) "$(INSTALLDIR)"; \
+  then install lablgtktop$(XE) "$(INSTALLDIR)"; \
fi
-   cp -p *.h "$(INSTALLDIR)"
+   install *.h "$(INSTALLDIR)"
@if test -f lablgtk.cmxa; then $(MAKE) installopt; fi
@if test -f dlllablgtk2$(XS); then $(MAKE) installdll; fi
-   cp lablgtk2$(XB) "$(BINDIR)"
+   install lablgtk2$(XB) "$(BINDIR)"
if test -f lablgladecc$(XE); then \
-  cp lablgladecc$(XE) "$(BINDIR)/lablgladecc2$(XE)"; fi
+  install lablgladecc$(XE) "$(BINDIR)/lablgladecc2$(XE)"; fi
 
 installdll:
-   cp $(CLIBS:lib%$(XA)=dll%$(XS)) "$(DLLDIR)" || \
+   install $(CLIBS:lib%$(XA)=dll%$(XS)) "$(DLLDIR)" || \
   echo "Couldn't install dlls in default location: $(DLLDIR)"
 
 installopt:
-   cp $(MLLIBS:.cma=.cmxa) $(MLLIBS:.cma=$(XA)) "$(INSTALLDIR)"
+   install $(MLLIBS:.cma=.cmxa) $(MLLIBS:.cma=$(XA)) "$(INSTALLDIR)"
cd "$(INSTALLDIR)" && $(RANLIB) $(MLLIBS:.cma=$(XA))
-   cp $(ALLOBJS:.cmo=.cmx) "$(INSTALLDIR)"
-   cp $(INITOBJS:.cmo=$(XO)) "$(INSTALLDIR)"
+   install $(ALLOBJS:.cmo=.cmx) "$(INSTALLDIR)"
+   install $(INITOBJS:.cmo=$(XO)) "$(INSTALLDIR)"
if test -f gtkThread.cmx; then \
-  cp $(THOBJS:.cmo=.cmx) $(THOBJS:.cmo=$(XO)) "$(INSTALLDIR)"; fi
+  install $(THOBJS:.cmo=.cmx) $(THOBJS:.cmo=$(XO)) "$(INSTALLDIR)"; fi
 
 ifeq ($(TOOLCHAIN),msvc)
 liblablgtk2$(XA): $(COBJS)
diff -urN -x .build -x .inst -x .sinst lablgtk-2.4.0-orig/src/ml_gdk.c 
lablgtk-2.4.0/src/ml_gdk.c
--- lablgtk-2.4.0-orig/src/ml_gdk.c 2004-06-15 17:42:30.0 -0400
+++ lablgtk-2.4.0/src/ml_gdk.c  2004-09-05 18:38:44.83075 -0400
@@ -2,7 +2,7 @@
 
 #include 
 #include 
-#if defined(_WIN32) || defined(__CYGWIN__)
+#if defined(_WIN32)
 #include 
 #else
 #include 


Re: tcsh left running after closing down X server

2004-09-05 Thread Thomas Dickey
On Sun, 5 Sep 2004, Alexander Gottwald wrote:

> Jason Farrell Shepherd wrote:
>
> > Hey guys,
> >
> > I just installed cygwin on my laptop running XP.  It seems
> > to be running fine, no problems with the install; however,
> > I noticed that if I start several xterms running tcsh, and
> > then close the XWin, the tcsh.exe files are still reported
> > by windows as utilizing memory from the windows task
> > manager.  Is this a known problem?
>
> Yes. And there is no simple fix. This sometimes happens on
> linux too since this is caused by the TCP/IP design.

That's a little unclear - most of the instances where a shell is left
orphaned seem to be because the SIGHUP doesn't propagate into an su'd
process.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


Re: tcsh left running after closing down X server

2004-09-05 Thread Alexander Gottwald
Jason Farrell Shepherd wrote:

> Hey guys,
>
> I just installed cygwin on my laptop running XP.  It seems
> to be running fine, no problems with the install; however,
> I noticed that if I start several xterms running tcsh, and
> then close the XWin, the tcsh.exe files are still reported
> by windows as utilizing memory from the windows task
> manager.  Is this a known problem?

Yes. And there is no simple fix. This sometimes happens on
linux too since this is caused by the TCP/IP design.

bye
ago
NP: Terminal Choice - Deathwish
-- 
 [EMAIL PROTECTED]
 http://www.gotti.org   ICQ: 126018723


Re: Is RECORD extension included in cygwins' X server?

2004-09-05 Thread Alexander Gottwald
Ariel Burbaickij wrote:

> Well, what is RECORD extension? ;-)
> Sorry, no clue. I only know that
> this extension is refered to by
> authors of xnee tool in article in
> Linux Journal -- http://www.linuxjournal.com/article.php?sid=6660
> and I also know that I was able to compile xnee for cygwin but
> I get "error on display ... " as soon as I try
> to start it. I also know that the XFree86 Server as included
> in FreeBSD ports probably has this extension because
> xnee is also officially ported to FreeBSD too.

The record extension is compiled into the Xserver.
xdpyinfo gives
number of extensions:24
...
DEC-XTRAP
...
RECORD
...
XTEST

These are the extensions named in the article. If the programs
still fail then you should probably ask the developers of the
program for help too.

bye
ago
NP: Terminal Choice - Deathwish
-- 
 [EMAIL PROTECTED]
 http://www.gotti.org   ICQ: 126018723