Re: [ANNOUNCEMENT] Uploads for 12 August
On 8/13/2013 2:09 PM, Yaakov (Cygwin/X) wrote: For now, I think you'll have to add a wrapper script. Which would cause issues (dos boxes, etc) when launching from a shortcut, unless you use run.exe or run2.exe. With run2 (assuming the upcoming(?) release fixes the known issues), you can set environment vars directly in the xml script: ?xml version=1.0 encoding=us-ascii? Run2Config xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:noNamespaceSchemaLocation=run2.xsd Global Environment Set var=G_SLICE value=always-malloc/ /Environment Target filename=/usr/bin/emacs.exe startin=~ Arg...various stuff.../Arg Arg...various stuff.../Arg Arg...various stuff.../Arg /Target /Global /Run2Config ...ought to work. But there are still extant issues with run2 IIRC (been on vacation for a while so my memory from pre-vacation is still fuzzy). -- Chuck -- 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 1.7.22 calls dumper when starting X
On 8/1/2013 7:19 AM, Angelo Graziosi wrote:
Charles Wilson wrote:
Is there a way to test run-2.0? What is the syntax to replace:
C:\Cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe
Sure:
and how to replace
C:\cygwin-2\bin\run.exe bash -l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*};
XWin -nowgl -multiwindow -clipboard -silent-dup-error 2/dev/null '
(which works fine with run-1.2!)
I have tried this:
$ cat /home/angelo/XWinServer.xml
?xml version=1.0 encoding=UTF-8?
Run2Config
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;;
xsi:noNamespaceSchemaLocation=run2.xsd
SelfOptions /
Global
Environment /
Target filename=/usr/bin/bash.exe startin=/usr/bin
Arg-l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*}; XWin -nowgl
-multiwindow -clipboard -silent-dup-error 2/dev/null '/Arg
/Target
/Global
/Run2Config
with this target in the link (.lnk):
C:\cygwin-2\bin\run2.exe /home/angelo/XWinServer.xml
Two errors: the extra semicolon after XMLSchema-instance, and you do
need to use the 'amp;' construction instead of ''. See attached.
(I'm not sure why you need at all; unless it allows the bash shell to
exit, where otherwise it would hang around?)
FWIW, I've never tested run2 with multibyte UTF-8, so...you might be
better off setting the encoding to us-ascii.
--
Chuck
?xml version=1.0 encoding=UTF-8?
Run2Config
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation=run2.xsd
SelfOptions /
Global
Environment /
Target filename=/usr/bin/bash.exe startin=/usr/bin
Arg-l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*}; XWin -nowgl -multiwindow -clipboard -silent-dup-error 2/dev/null amp;'/Arg
/Target
/Global
/Run2Config
--
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 1.7.22 calls dumper when starting X
On 7/31/2013 9:41 AM, Jim Reisert AD1C wrote: [1] http://cygwin.com/ml/cygwin/2013-07/msg00532.html Yeah, I need to add even more runtime-debugging in run-1.0 and put out a test release, so we can figure out what's going wrong there. Is there a way to test run-2.0? What is the syntax to replace: C:\Cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe Sure: 1. create an XML file describing the program you want to launch. Here's an example: ?xml version=1.0 encoding=us-ascii? Run2Config xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:noNamespaceSchemaLocation=run2.xsd SelfOptions / Global Environment / Target filename=/usr/bin/bash.exe startin=/usr/bin Arg-l -c /usr/bin/startxwin.exe/Arg /Target /Global /Run2Config 2. Make sure all the arguments you want to pass to the target program are represented in (the|one of the) Arg / elements. Be sure that all sequences of two '-' characters are replaced by -!- (e.g. -!-login for --login, etc). 3. Create a shortcut with the following target: C:\cygwin\bin\run2.exe /cygwin/path/to/your/xml/file Enjoy. (Try C:\cygwin\bin\run2.exe --debug=3 --notty /cygwin/path/to/your/xml/file if it doesn't work). -- Chuck -- 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: coredumps with fc-cache, fc-list
On 8/28/2012 4:26 AM, Yaakov (Cygwin/X) wrote: Fontconfig is WJFFM (Win7 x64, 290 .ttf files in Windows fontdir, none with spaces). I suspect you have a corrupt or otherwise incorrect font file in your Windows fontdir. What happens if you remove that directory from /etc/fonts/fonts.conf? Can you try to narrow it down further to a specific font file? Yes, that was it. The Thai font Angsana New (Regular) was corrupt; removing it and all the other Angsana TTF files fixed that problem. Now I'm back to debugging, on the Vista machine where gdb actually works [1], the original problem with rxvt-unicode which I encountered on W7 -- that is, whenever I do anything interesting (like, say, simply starting vi), my rxvt-unicode terminal crashes with a SIGABRT: Program received signal SIGABRT, Aborted. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x77015490 in ntdll!ZwWaitForSingleObject () from /c/Windows/system32/ntdll.dll #2 0x757b9aa4 in WaitForSingleObjectEx () from /c/Windows/system32/kernel32.dll #3 0x0564 in ?? () #4 0x in ?? () No idea why. I have debugging symbols available but...the abort appears to occur down in ntdll somewhere, and I have nothing informative in the remaining backtrace. Sigh. I'm pretty much stumped at this point; my next try will be to build a completely minimal, zero frills, version and see if it works better. If so, then slowly add features back... [1] Space key + gdb: http://cygwin.com/ml/cygwin/2012-08/msg00571.html -- Chuck -- 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/
coredumps with fc-cache, fc-list
While trying to debug the problem with my new build of rxvt-unicode, I find that I am getting a segfault way down deep in libfreetype. I rebuilt libfreetype with the new cygport, so I could get those handy debug symbols, and spent some time trudging thru that. Then, since libfreetype is actually called by libfontconfig, and not directly by rxvt-unicode, I decided to download the -src package and rebuild THAT, too -- again, so I could have debug symbols for a few of my intervening stack frames. The (re)build of fontconfig-2.8.0-2 went fine, but when setup installed it, I got an error during postinstall. Setup.log.full says: 2012/08/28 01:38:48 running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile /etc/postinstall/fontconfig.sh /etc/postinstall/fontconfig.sh: line 2: 4164 Segmentation fault (core dumped) /usr/bin/fc-cache -r Ick. So, I reinstalled the real version...and I got the same message: 2012/08/28 01:53:01 running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile /etc/postinstall/fontconfig.sh /etc/postinstall/fontconfig.sh: line 2: 6856 Segmentation fault (core dumped) /usr/bin/fc-cache -r Running 'fc-list : family' also coredumps (using the official fontconfig-2.8.0-2). *=-=-=-=-=-=-=-=-=* I next ran 'fc-cache -fsv' as Adminstrator, and everything went swimmingly...until I got to the Windows dir: ... /usr/share/texmf-dist/fonts/type1/urw/times: caching, new cache contents: 4 fonts, 0 dirs /usr/share/texmf-dist/fonts/type1/urw/zapfchan: caching, new cache contents: 1 fonts, 0 dirs /usr/share/texmf-dist/fonts/type1/urw/zapfding: caching, new cache contents: 1 fonts, 0 dirs /cygdrive/c/Windows/Fonts: Segmentation fault (core dumped) FWIW, I have 469 true type fonts in Windows/Fonts. There are a mixture of fonts identified by Windows as TrueType and OpenType even tho they all end in .ttf. Three of the font files have spaces in their names. /cygdrive/c/Windows/Fonts/Envy Code R Bold.ttf /cygdrive/c/Windows/Fonts/Envy Code R Italic.ttf /cygdrive/c/Windows/Fonts/Envy Code R.ttf I tried removing those three offenders, just in case, and re-running fc-cache but it still dumped core. Any ideas? I'm going to try, just for grins and giggles, installing a self-built version of fontconfig-2.10.$latest and see if that helps matters...but I won't be able to do so until Thursday at the earliest. -- Chuck -- 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: Built XWin on mingw - with patches
On 11/10/2011 11:29 AM, Ryan Pavlik wrote: On Wed, Nov 9, 2011 at 1:11 PM, Charles Wilson wrote: You *think* you're safe in assuming that WIN32 == !__CYGWIN__, but...#includejpeg.h breaks all your assumptions. But jpeg.h *did nothing wrong*. It's better to be explicit. -- Chuck OK, so this leads me to the next question: The existing codebase has substantial numbers of places with #if defined(WIN32) - do these all imply #if defined(WIN32) !defined(__CYGWIN__) ? That I don't know. I generally avoided touching things I didn't have to, A good policy. but this may be worth clarifying codebase-wide. Perhaps -- I'll leave that call to others. I suspect a global patch that affected only #if lines should be a separate patch from any other changes, if taking this action was desirable. -- Chuck -- 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: Built XWin on mingw - with patches
On 11/9/2011 1:46 PM, Jon TURNEY wrote: On 07/11/2011 19:36, Charles Wilson wrote: But this isn't true if you ever #include any of the w32api headers. Then you get WIN32 defined, even on cygwin... True. I guess what I meant to say is that there isn't any compiler which defines both WIN32 and CYGWIN (I hope :-)). Any portable code which includes w32api headers before checking if WIN32 is defined isn't going to be very portable :-) But it's perfectly portable to check for __CYGWIN__ (or, for that matter, __MINGW32__) instead of WIN32 before #including w32api headers, because you know that the windows API will be available in those cases as well. The difference is, IF you do this (perfectly fine, legal, and portable) thing: #if defined(WIN32) || defined(__CYGWIN__) # include windows.h #endif then you can no longer rely on #if defined(WIN32) ...stuff that applies only for truly native windows (e.g. ...msvc or mingw), but not cygwin #endif even though both hunks above are legal and make perfect sense *in isolation*. The problem occurs when both hunks are present in the same translation unit -- and that's not always under your control. What if libjpeg's header does the first hunk (it doesn't, but assume that it does for argument's sake), and your project's headers only do the second? You *think* you're safe in assuming that WIN32 == !__CYGWIN__, but...#include jpeg.h breaks all your assumptions. But jpeg.h *did nothing wrong*. It's better to be explicit. -- Chuck -- 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: Built XWin on mingw - with patches
On 11/7/2011 1:10 PM, Jon TURNEY wrote: I see what you are trying to do here, but I'm not sure it actually adds any clarity. I think I'd just prefer to assume the knowledge that WIN32 and CYGWIN are mutually exclusive, so '#if defined(WIN32) !defined(__CYGWIN__)' can just be written '#ifdef WIN32' But this isn't true if you ever #include any of the w32api headers. Then you get WIN32 defined, even on cygwin... windef.h: #ifndef WIN32 #define WIN32 #endif #ifndef _WIN32 #define _WIN32 #endif -- Chuck -- 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: rsh from other linux machines on the network to my cygwin machine
On 2/16/2011 6:17 PM, Srikanth Katkam wrote: I can do rsh/ssh onto other linux machines in the network and use all the resources on those machines but I cannot do the reverse, i.e., rsh on to my windows machine (i.e., Cygwin X server), why the other machines not able to see my cygwin/windows machine? This is why I am not able to run any DISPLAY required applications on the other linux machines (which rsh'ed on to from my cygwin/windows machine). The main reason is when I set the DISPLAY environment variable on the linux machines as my_windows_machine:0.0 it says cannot open DISPLAY Your title does not appear to match the question you are asking. If you are logged on to a linux box, and want to rsh over to your cygwin box ... then you need to set up the rshd server on your cygwin box. See /usr/share/doc/Cygwin/rsh-server.README If you are logged on to a linux box, and want to ssh over to your cygwin box ... then you need to setup up the sshd server on your cygwin box. See /usr/share/doc/Cygwin/openssh.README (but basically, run /usr/bin/ssh-host-config and answer the questions). That answers what your TITLE appears to ask. However, the TEXT of your question appears to ask a completely different question: You are ssh'ing from cygwin to linux, and want to run an X application on the linux machine, and have the display show up on your local cygwin box -- but it's not working. OK, FIRST you have to install and configure the cygwin Xserver, and have it running. SECOND, you need to be able to display X apps LOCALLY on cygwin box. e.g. launch an xterm on the cygwin box. THEN, from /that xterm/ on your cygwin box, do this: ssh -Y remote_linux_host FINALLY, once logged on to the linux host, launch an X app. It should work. Read about the -Y (and -X) options... -- Chuck -- 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: Can't use mintty instead of rxvt for ssh -Y using cygwin xserver
On 10/11/2010 1:21 PM, Christopher Faylor wrote: You probably could try to figure out if the X server is working and then see which display is being used from that but I really don't think it makes sense to slow down mintty to perform this check. FWIW, this wouldn't work with the linux console either. IMO, it just boils down to a situation where, if the user wants to have things display remotely, they have to go to the effort to properly set the DISPLAY environment variable. Modifying mintty, the cygwin console, or any other non-X application to do the right thing isn't the way to go. FYI, the 'checkX' program from the run2 package could be useful here, as part of a script the end user could run, within mintty or the cygwin console... -- Chuck -- 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 no longer launches urxvtc-X
On 8/20/2010 10:48 AM, Jay Goldman wrote: I have the following menu items in my .XWinrc: Black EXEC /bin/urxvtc-X -fg green -bg black -cr dodgerblue -g 80x40 -e /bin/bash -l -I dodger EXEC urxvtc-X -fg white -bg dodgerblue -cr blue -g 80x42 -e /bin/bash -l -I Which have been working for months . Today I upgraded my cygwin install and all my menu items like the above no longer work. (as noted above I've tried both simply urxvtc-X and /bin/urxvtc-X If, however, I open up a command window using rxvt and then enter the above Line (by copy and paste) it works fine. My first guess was that the urxvt daemon (urxvtd-X) was not running, so the client failed. But if you can launch the client using some incantation, then that means the daemon is running. Note, menu items like: Xterm exec xterm Work correctly, While menu items such as: Notepad exec notepad Do not. Ah. Here's the clue: launching a native win32 program fails. I bet this is related to the change in cygwin-1.7.6 where the cygwin current working directory and the win32 CWD are no longer automatically kept in sync (there are good reasons for this new behavior). This change has caused a number of problems, and it is not yet clear how they will be resolved. Stay tuned to the main cygwin list -- and meanwhile, revert to cygwin-1.7.5. -- Chuck -- 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: problem with startxwin.exe and a possible solution
Marco Atzeri wrote: Today I start some experiments and I have found that changing the menu target from C:\cygwin2\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe to C:\cygwin2\bin\run.exe -p /usr/bin /usr/bin/startxwin.exe all the problems seem gone. The Xserver is stable and all the Xterms run smoothly. I suppose that my login shell redefine some parameters that startxwin.exe needs, while a much simpler run.exe -p /usr/bin is what is really needed. The real issue, I think, is that your mechanism doesn't allow you to set OTHER environment variables that might need to be defined before launching XWin, such as LC_ALL etc -- which would get set by the original formula, since 'bash -l' reads your startup files like ~/.bash_profile where they might get set. Another (untested!) possibility is to use run2.exe (which is kinda wierd: use a launcher to start a launcher that starts X...) == startxwin.xml === ?xml version=1.0 encoding=us-ascii? Run2Config xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:noNamespaceSchemaLocation=run2.xsd Global Environment !-- set environment variables here -- Append var=PATH value=/usr/bin/ Set var=LC_ALL value=en_US.UTF-8/ /Environment Target filename=/usr/bin/startxwin.exe startin=~ /Target /Global /Run2Config Shortcut target: C:/cygwin/bin/run2.exe --notty /usr/bin/startxwin.xml -- Chuck -- 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: xserver bug?
Jon TURNEY wrote: On 20/01/2010 09:13, Sylvain RICHARD wrote: Charles Wilson wrote: I've noticed that with XWin 1.7.3 (and perhaps earlier versions; not sure), the key combination CTRL-SHIFT-0 (zero) doesn't generate any events. CTRL-SHIFT-1 thru -9, alphabetic keys, no problem -- just not zero. I'm afraid I can't reproduce this problem; xev and urxvt both respond to ctrl-shift-0. Humph. Well, good, I guess. (Even if it doesn't work for me, this means that OTHER users will probably be able to use the ISO14755 entry mode without trouble). snip Is this a bug, or a designed behavior, in XWin? This may be designed behaviour /in windows/. Just out of curiosity, can you check your language bar options. If I remember correctly, you can set Ctrl+Shift global hotkeys there to shift between keyboard layouts and input languages. My user account doesn't have the language bar enabled at all. Hmm...maybe it's sticky. I *used* to have it enabled, and I *used* to have hotkeys enabled -- but the only hotkey was/is left-alt + shift. Not ctrl+shift. If it is the case that Windows is treating ctrl-shift-0 as a special keypress for some reason and processing it without offering it to applications, starting the X server with the -keyhook option should help. Odd. With -keyhook, I do NOT see Alt-Tab being intercepted by the Xserver. BUT, CTRL-ALT-0 does work. $ startxwin -- :0 -keyhook Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.7.3.0 (10703000) Build Date: 2009-12-22 Contact: cygwin-xfree@cygwin.com XWin was started with the following command line: X :0 -keyhook -multiwindow winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 (II) xorg.conf is not supported ... Vista SP2, 32bit. Oh, WIERD. Now, I just tried it again *without* -keyhook, and CTRL-SHIFT-0 still works. That's just bizarre. All I can figure is, I turned on the language bar, switched keyboards, switched back, and then turned off the language bar. And now, I can't break the CTRL-SHIFT-0. Well...I'm happy, I guess. -- Chuck -- 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/
xserver bug?
I've noticed that with XWin 1.7.3 (and perhaps earlier versions; not sure), the key combination CTRL-SHIFT-0 (zero) doesn't generate any events. CTRL-SHIFT-1 thru -9, alphabetic keys, no problem -- just not zero. This came up as I was testing the new rxvt-unicode release; it has a special ISO14755 entry mode, where you hold down CTRL-SHIFT and type the unicode value (in hex) of the codepoint you want, and then release the CTRL-SHIFT keys -- urxvt inserts the correct character. This works -- as long as the unicode value doesn't contain 0. e.g. CTRL-SHIFT 3-b-2 gives 'beta' CTRL-SHIFT 2-0-a-c should be the Euro symbol, but the '0' never has any effect. As I said, you can verify this behavior (this missing 0 events) using xev, so it's not specific to rxvt-unicode. Is this a bug, or a designed behavior, in XWin? -- Chuck -- 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: xinit-1.2.0-2
Yaakov (Cygwin/X) wrote: IMPORTANT: THE startxwin.bat AND startxwin.sh SCRIPTS ARE NO LONGER SUPPORTED. This release replaces those scripts with a startxwin executable. facepalm! Sounds like a good idea, but I wish I'd known this was coming before wasting time on: 2009-12-29 run2-0.4.0 (release) ... * Improve checkX behavior when used as 'barrier' in startxwin. ... Oh, well. -- Chuck -- 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: xinit-1.2.0-2
Yaakov (Cygwin/X) wrote: On 29/12/2009 16:27, Charles Wilson wrote: Sounds like a good idea, but I wish I'd known this was coming before wasting time on: * Improve checkX behavior when used as 'barrier' in startxwin. Sorry about that, Chuck, but this was just the latest of a long string of issues involving these scripts. We've been talking about replacing them for a while, and the recent traffic on the list was enough of an impetus to make me finally stop bandaging the scripts and find a better solution. Plus, we gain argument handling and .startxwinrc, something the scripts would likely never do. Like I said, it sounds to me like a good idea; there's just so many issues that can go (and have gone) wrong in these scripts -- PLUS, whose idea was it to have TWO, one .sh and one .bat?!!? Yeeesh. We're well rid of them. Honestly, this wasn't even checkX's fault, so we weren't expecting you to fix it. The real problem here is a corner-case bug in the server; the race condition that checkX was causing was just the trigger. We still need to get to the bottom of that, but in the meantime we have a solution that completely avoids the problem and gives us new features to boot. Yes, it definitely seemed like some sort of race going on -- I even noticed sometimes that checkX would return success (e.g. was able to call XOpenDisplay()), but that the very next command in my startxwin.sh script would fail with a can't open display error. Err...what? So, yeah, I think startxwin.exe/.startxwinrc is a really excellent step forward. -- Chuck -- 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 fails to start
Feng Dai wrote: The root cause is checkX doesn't work properly. It cause XWin failed on initClipboard and exit itself. The work around is either comment out checkX or have a sleep 3 to let XWin server startup before checkX runs. It's actually not checkX's fault that the Xserver dies. All checkX does is try to call XOpenDisplay(). However, in the current usage by the startup scripts, checkX will do so /repeatedly/ during the period when the Xserver is just getting started. XWin appears to be fragile at that stage in its execution. So, the latest version of checkX tries to be gentle with the Xserver when that Xserver is just launching. To try it out, you should make the relevant part of startxwin.bat look like this: ... %RUN% bash -l -c XWin -multiwindow -clipboard -silent-dup-error REM Make sure XWin is ready to accept connections before proceeding checkX -d %DISPLAY% -t 12 ... That is, don't use %RUN% to invoke checkX. -- Chuck -- 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 fails to start
Charles Wilson wrote: So, the latest version of checkX I guess I should be specific: that's checkX from the run2-0.4.0-1 package, which should begin hitting the mirrors soon. -- Chuck -- 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: X11R7.5 and C.UTF-8
Linda Walsh wrote: C.UTF_8 doesn't exist. You're wrong. Please read the whole of this thread -- and the last two months' worth of cygwin-developers. mintty is broken. No, it isn't. It just doesn't work the way *you* expect it to. Might want to try 'Console' nstead of using mintty. Not perfect either, but fewer compatibility problems that I've noticed. Examples of valid LANG values: C, ca_FR, en_US, fr_FR, it_IT, nl_NL, wa...@euro You can't have C and UTF-8, because C means no encoding (default). No, it doesn't. C means POSIX and is defined here: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html Note how all the glyphs are defined in terms of character NAMES, not hexadecimal values? That's because C, all by itself, just doesn't SPECIFY any encoding. You're still allowed to HAVE one -- in fact, you ALWAYS have one. On most systems, that has historically been the plain ASCII 7-bit encoding; many others used the EBCDIC encoding and were not considered in violation of the POSIX C locale specification. Now, many systems are starting to use the UTF-8 encoding by default, even in the C locale. C/POSIX locale (without an additional .ENCODING suffix) is encoding-AGNOSTIC, that's all. So, you're allowed to add an .ENCODING suffix to force a specific encoding if you like, without violating POSIX. (And your system is also allowed, in that case, to IGNORE that .ENCODING suffix, and still be Posix-compliant IIUC, so it's rather a hole in the spec IMO). UTF-8 IS an encoding, so they are mutually exclusive. I don't know under what circumstances C might imply UTF-8. Whenever the platform decides to use UTF-8 as its default encoding, which is perfectly acceptable according to Posix. Cygwin-1.7 has decided to do that. So, on cygwin-1.7, C implies .UTF-8. X11R7.5 doesn't yet know that, without outside help (e.g. explicitly setting $LANG to C.UTF-8 by default, so that XWin knows about the new default behavior). If the definition of C changes? It might be easier than changing c (as used in physics). My understanding of locale issues is also limited and subject to change or re-education... Uhm, yeah. -- Chuck -- 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: xterm not working
Thomas Dickey wrote: On Mon, 30 Nov 2009, Andy Koppe wrote: The latest termcap, which was automatically generated from terminfo, has entries longer than 1K in it. ok... (I thought cygwin was using GNU termcap, which supposedly works with longer entries - though I recall _that_ being fixed more than once). Red herring. The problem IS with the latest /etc/termcap, but it isn't an entry too long problem. It is an entries contain multiple :tc= options problem. This can be fixed by generating /etc/termcap using tic's '-r' option. Look for a new /etc/termcap soon. It'd be nice if xterm didn't coredump, but I suspect the coredump actually occurs inside code from the (obsoleted on cygwin) libtermcap.a -- so there's nothing to fix, except to recompile xterm on cygwin to not use libtermcap and instead use libncurses. Which is exactly what Yaakov has already done, for cygwin-1.7 only. -- Chuck -- 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: xterm not working
Corinna Vinschen wrote: Isn't xterm linked against ncurses? The new 1.7 xterm is. The old 1.5 xterm is still termcap based. Why does it break on a termcap file at all? 1.5 only, and it breaks because the termcap file was NOT generated using '-r' to limit the number of allowed ':tc=' options in a single termcap definition. Will be fixed soon. -- chuck -- 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: xterm not working
Yaakov (Cygwin/X) wrote: On 29/11/2009 21:28, Joe Java wrote: Gone for Thanksgiving break, return and update cygwin, and now xterm does not show anymore. I have not upgraded to the latest 1.7 (I am waiting for the official release). I read the other messages and nothing seems to work. Does anyone have a SIMPLE solution to this problem. Downgrade the termcap package until there is another update thereto. Should be fixed by termcap-5.7_20091114-4 (cygwin-1.5) or termcap-5.7_20091114-13 (cygwin-1.7). -- Chuck -- 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: checkX problems
Lothar Brendel wrote: Unfortunately the situatiuon with ``startxwin.bat'' is worse now: * ``checkX -t 12'' still doesn't wait (?!?) I can't reproduce this. * After again inserting a sleep between checkXing and starting the xterm, the latter is marginally successful: The process is shown as running but no xterm is showing up :-( That's an xterm/XWin issue. I really would investigate this further, but I only get diagnostic output from ``checkX'' (--verbose or --debug) when running it from within an xterm, and that's obviously pointless. Thus, how to obtain output from ``checkX`` in Windows' Command Prompt, how to get it in Cygwin's bash window? checkX --notty --debug -t 12 -- Chuck -- 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: Problem with new xinit - console window doesn't open (but bash starts)
Jon TURNEY wrote: This is typical of the current issue we have where 'run xterm' blocks when xterm tries to output 'Warning: Missing charsets in String to FontSet conversion' Any one of: - installing the CJK fonts - having 'tty' in the CYGWIN environment variable - having the LANG environment set to a non-UTF-8 locale should work around this problem Note that the environment variable will have to be set via the system applet in the Windows control panel, as only that controls the environment for the startxwin.bat started from the start menu... There's another option. In startxwin.bat, you could use run2.exe instead of run. Instead of: %RUN% bash -l -c XWin -multiwindow -clipboard -silent-dup-error Use %RUNTWO% /usr/bin/XWin.xml where XWin.xml is something like the following (untested): ?xml version=1.0 encoding=us-ascii? Run2Config xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:noNamespaceSchemaLocation=run2.xsd SelfOptions / Global Environment !-- either of these, or both, and modified as desired -- Set var=LANG value=C.ASCII/ Append var=CYGWIN value= tty/ /Environment Target filename=/usr/bin/bash.exe startin=~ Arg-l/Arg Arg-c/Arg ArgXWin -multiwindow -clipboard -silent-dup-error/Arg /Target /Global /Run2Config -- Chuck -- 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: checkX problems
Lothar Brendel wrote: checkX fails due to a missing cygustr-1.dll. That's contained in which package? From http://cygwin.com/packages/ and typing in 'cygustr-1.dll', I get: libustr1 This *should* have been installed by setup automatically, as the run2 package now lists libustr1 as a dependency. -- Chuck -- 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: checkX problems
Lothar Brendel wrote: It should list, but it doesn't: $ grep -A9 '@ run2' setup-2.ini ^^^ This was the clue. As it happens, the union mount stuff had an override for setup.hint, but not the entire directory. So, the tarballs themselves magically showed up in the release-2 area when I installed them in the release/ area, but release-2 retained the old setup.hint. Fixed. Thanks for tracking it down. -- Chuck -- 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: checkX problems
I've integrated Lothar's patch into run2/checkX (along with some other internal changes), and published a test release. Please try run-0.3.1-1 and let me know if it fixes your problems with checkX. -- Chuck -- 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: checkX problems
Lothar Brendel wrote:
Ok, this can be cured by
if (pthread_cond_timedwait (cv_xopenOK, mtx_xopenOK, then) ==
ETIMEDOUT) {
xopenOK = XSERV_TIMEDOUT; /* it's okay, we have the mutex */
xopenTrying = 0; /* allow open_display() to give up */
+ pthread_mutex_unlock(mtx_xopenOK); /* allow for a last minute
change */
}/* else open_display() was successful */
pthread_detach(id); /* leave open_display() on its own */
Not, that won't do it -- because now that you've unlocked the mutex, you
can't guarantee that the worker thread hasn't locked it again by the
time you try to destroy the mutex. You can't move the
pthread_mutex_destroy call to the worker thread -- because what if there
never IS a successful return from the call to XOpenDisplay? And finally
-- a little bit later in the main thread you are going to USE the value
of xopenOK to compute your return value -- but it's not an atomic
operation so you don't know if the worker thread is going to change
xopenOK's value in the middle of that operation.
AFAICT, the cure for all of these problems is worse than the disease
-- and the only *total* fix is for the main thread to always join() the
worker. Which is precisely what we want to avoid.
There are a few *minor* tweaks that could improve things, but I'm
willing to go ahead with the current as a test release (as soon as my
ITP for libustr is approved; it's a new dependency for run2).
But the problem is not so much destroying a locked mutex, but rather
locking a destroyed mutex, right?
Well, frankly by the time that could happen I really don't care what the
worker thread does, so long as it doesn't crash the whole process. We've
already detached from it, and just want it to finish its call to
XOpenDisplay() and terminate.
This happens in your race condition but also whenever ``delay'' is
shorter than the time spent in a successful XOpenDisplay(). The failure
doesn't really harm, but we can be less dirty by checking the result of
pthread_mutex_unlock(), cf. the new patch.
No, I don't think we should unlock the mutex in the main thread, at
least until after we've computed the return value. And once we DO
unlock the mutex, there just is NO WAY to guarantee that the worker
won't (successfully) lock the mutex, but not also have unlocked it, by
the time we try to call pthread_mutex_destroy -- except by waiting until
the worker thread exits (e.g. pthread_join()). Which we don't want to
do. (If you try to relock the mutex in the main thread, you're right
back where we started...)
--
Chuck
--
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: checkX problems
Lothar Brendel wrote:
Charles Wilson already set up this kind of infrastructure, I just had to
introduce one more communication variable, cf. the patch below
(positively tested on my system).
Yep, there are really two different purposes for a setting a timeout [i)
Just check whether an X server is available, but don't struggle with
that too long. and ii) There *should* be an X server coming up, just
be a little patient.], but now both can be achieved by choosing either
a short or a long duration.
Looks pretty good. There's still one problematic case -- but it
actually already existed; your change doesn't make it any worse than
what was already there.
+ do
+if((dpy = (*(data-xopendis))(data-displayname))) {
The call to XOpenDisplay can take up to 12 seconds. Suppose the main
thread times out after say 5 seconds, and then just after that we have a
*successful* return in the worker thread. The worker thread tries to
get the mutex:
+ (*(data-xclosedis))(dpy);
+ pthread_mutex_lock (mtx_xopenOK);
But the main thread, if you follow the timed-out codepath, never
releases the mutex. Instead, it destroys it while still having it
locked. Then, it evaluates xopenOK to compute the return value. The
spec says:
It shall be safe to destroy an initialized mutex that is unlocked.
Attempting to destroy a locked mutex results in undefined behavior.
So, the child thread might be stuck waiting for a mutex that has already
been destroyed. That could be a problem -- but a very very rare one, I
think. It only happens if you time out on the worker -- and THEN,
before the main app gets to exit(), the worker successfully returns from
XOpenDisplay. (If the main thread exits(), that should kill the worker
thread...so it never gets a chance to return successfully or otherwise).
+ xopenOK = XSERV_FOUND;
+ pthread_cond_signal(cv_xopenOK);
+ pthread_mutex_unlock (mtx_xopenOK);
+}
+ while (xopenTrying xopenOK == XSERV_NOTFOUND);
pthread_exit((void*)0);
}
However, (a) it's working now, even if it is technically wrong to do
it that way, and (b) it gets real complicated to figure out how to
guarantee the mutex is unlocked, in both threads, before destroying it
-- without forcing the calling thread to join() the worker, which is
explicitly what we DON'T want to do in this case.
So, I'm just going to leave it, and take your patch as-is.
Thanks!
--
Chuck
--
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: checkX problems
Jon TURNEY wrote: But why would you fix the timeout problem by doing some horrible horrible iteration in the DOS batch script (horrible) (which would probably have to busy-wait (also horrible) as there's no sleep command), when you can fix checkX, which has the bonus of fixing other uses of it? I actually wrote a version of this. It IS horrible -- but no need for a busywait, I used the ping trick: C:\windows\system32\ping -n 2 127.0.0.1nul sleeps for (n-1)==1 seconds. Since more people seem to have this problem (cf. also Olivia's post), I repeat my question (essentially already posed by Ken Brown: http://www.mail-archive.com/cygwin-xfree@cygwin.com/msg19402.html): Why using ``run'' at all? If we really need a wrapper (do we?) wouldn't ``sh'' be a better one? I guess we use run for the reason run exists: to hide the console window, which otherwise would be shown? But checkX is compiled as a GUI program, so it really shouldn't need run to hide its (non-existent) console: $ objdump -p /usr/bin/checkX.exe | grep ^Subsystem Subsystem 0002(Windows GUI) Now, in startxwin.bat, we actually use: %RUN% checkX -wait other args run.exe is peculiar. The first argument is the target, and IF the VERY NEXT argument is -wait, run usurps that argument. That is, run will invoke: checkX other args and checkX will never see -wait. So, what does run.exe do with -wait? It...waits. run.exe won't exit, until after the inferior does. So, if checkX takes 12 seconds to come back, then run will take 12 seconds ... and the entire script is paused until checkX exits. HOWEVER, since checkX is a GUI program, you SHOULD get the same result from both of these two commands: %RUN% checkX -wait other args checkX other args Perhaps if you look how startxwin.bat is started from the start menu shortcut, (as 'run startxwin.bat') you can see why this might be useful? To push this even further: Do we really need two *independent* scripts, ``starxwin.bat'' and ``starxwin.sh''? Why can't the former just delegate to the latter? Indeed. They are useless to me for starting the server and a continual source of problems. I would be quite happy to just delete them completely. :-) Well, I think the OP is suggesting that one or the other go away, not both. g However, what is /your/ preferred way of starting the Xserver from a shortcut, Jon? launching xinit via run? or do you always start the server from within an existing shell session? Looking forward to reading your patches to address any of these problems. It shouldn't be too hard to add an option to checkX to make it retry if ECONNREFUSED. This would have to manually track the elapsed time for each attempt, charging against the specified -t waittime. Just look at run2-0.3.0/lib/checkX.c::try_with_timeout(). Some function signatures might need to be changed in order to pass opt.retry down to that level, but it'd be a nice short project for someone. I'll try to get to this but it'll be a few weeks, unless somebody sends me a patch sooner. -- Chuck -- 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: X11R7.5 and C.UTF-8
Thomas Dickey wrote: On Wed, 28 Oct 2009, Ken Brown wrote: X11R7.5 doesn't like the (default) locale C.UTF-8. If I start the server technically speaking, there's no such locale as C.UTF-8, so I'd not expect portable code to accept it (C and UTF-8 are mutually exclusive). No, actually they are not. The C or POSIX locale is defined entirely in terms of character values -- not hexidecimal equivalents. That is, the set alpha shall contain 'a', 'b'... etc. The standard actually doesn't require that an implementation specify the encoding in which those character values are represented at all. You can, if you want, use 'HEX_CHAR', 'OCTAL_CHAR', and 'DECIMAL_CHAR' representations -- which implicitly require a specific encoding -- but the standard defines the 'C' locale entirely in terms of CHAR and CHARSYMBOL, which are encoding-agnostic. http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html#tag_07_03 Personally, I think it's a hole in the standard that it doesn't actually talk about the POSIX locale with encoding Y -- but then, they don't want to show preference between ASCII and EBCDIC, so UTF-8 sneaks in there. -- Chuck -- 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] [1.7] Updated: xinit-1.1.1-5
Angelo Graziosi wrote: In 'startxwin.bat' I see: %RUN% bash -l -c XWin -multiwindow -clipboard -silent-dup-error Shouldn't it be %RUN% bash -l -c XWin -multiwindow -clipboard -silent-dup-error ? No, run implicitly puts the target in the background, unless you add the '-w' (wait) option. -- Chuck -- 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: [1.7] On checkX
Angelo Graziosi wrote:
Charles Wilson wrote:
Unfortunately, I can't reproduce.
Ugh! I forgot to say that I start those scripts with links on desktop...
For example:
mkshortcut -AD \
-n ${urxvt} \
-a bash -l start_urxvt.sh \
-i /usr/bin/XWin.exe \
-d Console unicode \
/usr/bin/run.exe
Using a short cut to my script, just like your shortcut (except mine is
on my own desktop, not all-users'), I...can't reproduce your problem. WJJFM.
Indeed, if I start the script from Cygwin.bat, there is not
checkX.exe.stackdump in the HOME! It is created ONLY starting the script
with the link...
...and, in that case, the lines:
[...]
while ! /usr/bin/checkX
do
printf waiting for xserver to start\n
sleep 1
done
[...]
cause a NON-empty checkX.exe.stackdump:
$ cat checkX.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=6E7C3CD0
I don't know what to tell you. Please try to use the -debug options, as
I recommended before.
Not only, also a bad interference between XWin and clipboard: trying to
copy/paste (double click in urxvt shell), they hang and when I try to
'Restart Now' the PC, Windows says 'xwinclip has not finished yet...'
Also can't reproduce. WJFFM.
Now, If I want start your script from the link, How can I capture the
output?
For example, I have tried modifying it with:
Try this:
#!/bin/sh
export DISPLAY=127.0.0.1:0.0
let -a n=0
DBGLVL=1
start_XWin()
{
# Cleanup from last run.
rm -rf /tmp/.X11-unix
printf starting xserver\n ~/checkX_${n}.log
XWin -multiwindow -clipboard -silent-dup-error 2/dev/null
}
/usr/bin/checkX --debug=$DBGLVL ~/checkX_${n}.log 21 || start_XWin
n=`expr $n + 1`
while ! /usr/bin/checkX --debug=$DBGLVL ~/checkX_${n}.log 21
do
printf waiting for xserver to start [$n]\n ~/checkX_${n}.log
sleep 1
n=`expr $n + 1`
done
sleep 1
/usr/bin/urxvt-X
--
Chuck
--
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: [1.7] On checkX
Charles Wilson wrote:
Angelo Graziosi wrote:
Charles Wilson wrote:
Unfortunately, I can't reproduce.
Ugh! I forgot to say that I start those scripts with links on desktop...
For example:
mkshortcut -AD \
-n ${urxvt} \
-a bash -l start_urxvt.sh \
-i /usr/bin/XWin.exe \
-d Console unicode \
/usr/bin/run.exe
Using a short cut to my script, just like your shortcut (except mine is
on my own desktop, not all-users'), I...can't reproduce your problem. WJJFM.
Hmm. Spoke too soon. It appears, that if I turn on --debug, then I get the
5 [main] checkX 5048 fhandler_console::fixup_after_fork_exec:
error opening input console handle for /dev/console after fork/exec,
errno 13, Win32 error 5
2342 [main] checkX 5048 fhandler_console::fixup_after_fork_exec:
error opening output console handle for /dev/console after fork/exec,
errno 13, Win32 error
errors in my log, but only when launching from a shortcut. However, I
think that's expected...since checkX deliberately does not allocate a
console, and is *supposed* to use the presence/absence of a console to
determine whether to create MessageBoxes for log entries, or send them
to the (redirected?) stdout.
Try adding --notty to each invocation of checkX...that works for me.
It's annoying, but it works and allows you to see the debug messages.
Interestingly, the log files are now much smaller as expected -- what
isn't expected is they STILL get the fhandler_console error messages.
I wonder if /that/ is just a cygwin bug, in that it tries to open the
consoles of an exec'ed program, even if that program is not a console
program...I'll look in to that, later.
--
Chuck
--
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: Problems starting rxvt from startxwin.bat
Jon TURNEY wrote: Is there a reason why we can't do 'checkx -d %DISPLAY% -t 30' rather than counting up to 30 ourselves? Well, -t with a number larger than 12 is not useful. Xlib itself will timeout after 12 seconds if it can't contact the xserver. The -t option for checkx (and run2) simply says how long checkx will wait for the worker thread that's actually trying to contact the Xserver, before giving up and detaching the thread. -- Chuck -- 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: [1.7] On checkX
[Redirecting to cygwin-xfree; Reply-To set] Angelo Graziosi wrote: /usr/bin/checkX || start_XWin [...] Now, it happens that, often (perhaps always), if the x-server is not running, then checkX stackdumps, in the sense I find checkX.exe.stackdump in HOME, but it is empty! 0 bytes. What version of checkX.exe? Please do: $ cygcheck -cd checkx run2 Also, $ uname -a -- Chuck -- 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: [1.7] On checkX
[redirecting, AGAIN, to cygwin-xfree. This is OT for the main cygwin list]
Unfortunately, I can't reproduce. Try running checkX with (progressively):
--no-silent
--verbose
--debug
--debug=2
--debug=3
--debug=4
this should help to narrow down how far it gets (and perhaps why) before
dying. You may also need to use the --nogui option, and redirect stderr
to a logfile.
--
Chuck
#!/bin/sh
export DISPLAY=127.0.0.1:0.0
start_XWin()
{
# Cleanup from last run.
rm -rf /tmp/.X11-unix
XWin -multiwindow -clipboard -silent-dup-error 2/dev/null
}
/usr/bin/checkX || start_XWin
while ! /usr/bin/checkX
do
printf waiting for xserver to start\n
sleep 1
done
sleep 1
/usr/bin/urxvt-X
--
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: broken checkx on mirrors
Guenter Millahn wrote: just now I tried an update of my CygWin. I realized that checkx-0.2.1-1.tar.bz is broken on all mirrors. The checkx-0.2.1-1 package is an empty upgrade helper. It is present only to force an update to the new package, which is called run2 -- this should have happened automatically. If it didn't, then just use setup to install the run2 package manually. run2 contains the old checkx program, as well as a new, enhanced version of run.exe, that combines the capabilities of checkx, run, and some new features. -- Chuck -- 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: [1.7] Updated: cygwin-1.7.0-45
Thomas Wolff wrote: Now that cygwin supports UTF-8 in a standard fashion, I think it's time to also add Unicode fonts to the Cygwin/X distribution. Otherwise the additional value of running xterm or rxvt in UTF-8 mode is quite limited. I would be willing to provide the Unicode versions of the standard misc-fixed fonts (source: http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html) as a package maintainer, if that's accepted. (I would appreciate some positive feedback before taking the effort to prepare the package.) I think this is a great idea. Please do prepare a package and post an official ITP (I'm not sure if X-specific package proposals should be ITP'ed on cygwin-xfree or cygwin-apps). I'm hoping that cygwin-1.7 + rxvt-unicode-8.x (+ ncurses configured for wide char support?) will replace the need for your earlier unicode shims contribution to rxvt-unicode. It'd certainly be easier to test that with some unicode fonts already in the distro... It might also be a good idea to supplement the existing font-bitstream-vera-ttf package with the DejaVu fonts http://dejavu-fonts.org/wiki/index.php?title=Main_Page (or DejaVu-LGC [Latin-Greek-Cyrillic] for the less-ambitious). Fedora packages them as dejavu-sans-fonts dejavu-sans-mono-fonts dejavu-serif-fonts dejavu-fonts-common since unicode fonts can get rather large... -- Chuck -- 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: New Maintainer
Christopher Faylor wrote: On Thu, Mar 27, 2008 at 08:58:17PM -0500, Charles Wilson wrote: DRC wrote: Is there a spec for which files go in which packages, etc.? Any other advice to get started, or should I just start downloading and tinkering? Given the new modular structure of the X.org releases, it seems to me that each module should be treated independently. However, that being said, each module may represent multiple tarballs. E.g. I don't think it makes sense to invent a new scheme for what goes where. Just pick a distro (Fedora, Gentoo, SuSE, Ubuntu, etc.) and mimic that. Chris, this is NOT a new scheme, and the linux distros' methods cannot be directly mapped to cygwin with regards to shared libraries, because .so's != dlls, and ld.so != Windows Runtime Loader. There will always be some differences between our packaging and the *nixes. But in this particular case, what is new about the breakdown iisted below? Doesn't it map almost exactly to how Fedora distributes libXext in rpms? libXext-1.0.3-1-src.tar.bz2 libXext-1.0.3-1.tar.bz2 libXext-devel-1.0.3-1.tar.bz2 libXext6-1.0.3-1.tar.bz2 (These filenames were taken directly from Yaakov's libXext cygport.) The only real difference is that the *nixes would provide only the DLL (so) package 'libxext6' and the -devel package 'libxext-devel'; there's nothing specific in this case that really needs to go in a base package 'libxext'. However, in Cygwin's case I've noticed that setup.exe (at least in the past) got annoyed if you have: foo-*-src.tar.bz2 libfoo6-*.tar.bz2 (external-source: foo) libfoo-devel-*.tar.bz2 (external-source: foo) but do not have foo-*.tar.bz2 Maybe this is a bug in setup and we should fix it, or maybe it is not a problem anymore. In any case, we need to put the cygwin README, and the normal README/THANKS/AUTHORS/ChangeLog goobledygook somewhere. Might as well be in the (otherwise empty) foo-*.tar.bz2 package. As it happens, Yaakov chose to put the man3 docs in the main foo-* package, instead of the libfoo-devel-* package. I'd probably do it more like the *nixes, in this case. But really, is THIS significant? We can and should, of course, use the Linux distro's packaging choices as informed guidance, and I'm sure that's exactly what Yaakov did when he created his cygports. (The *nixes whose X components are based on the modular X.org source DO treat each module as independent subsets [that is, separate *.src.rpm's, separate lib*N rpms, separate lib*-devel rpms etc]...although they naturally tend to update/release them in simultaineous waves). Frankly, I'd want to make things as easy as possible for the new X maintainer -- and since an experienced, knowledgeable person has already done a HUGE portion of the necessary work, I'd /start/ with Yaakov's cygports...and *maybe* make some slight modifications if SuSe/Fedora/Debian did something the new X maintainer particularly likes. (Not the other way around, as you seem to suggest). My email was an attempt to explain the general way that dll-providing cygwin packagesets are and should be subdivided, with a short description of the 'why' behind it all. It's the way I've been providing DLL packagesets since 2002 or before. I'm surprised you consider it new. -- Chuck -- 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: Checking if the X Server is running
O. Olson wrote: Is there any way of checking if the X Server is currently running? Because if you try this again, it gives you “A fatal error” … which does not crash your computer – but is a bit annoying to me. The checkX program is written specifically to do this. #!/bin/sh if checkX ; then # X is running else # X is not running fi -- Chuck -- 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: Xterm, rxvt, mrxvt, etc....
often notifies me directly of upcoming changes and asks for testing. So who is the 'C' maintainer: probably Bruno, but I reckon I help, somewhat. Anyway, back on topic: I apologize for ignoring category C; that confusion is what led to our miscommunication (see below). When I've seen - say - more than 10% of your work in the latter, you'll have something to argue about. You're not there. Fine. In your opinion I'm a bad maintainer. But I do release updates, and I do fix bugs. Since rxvt has no 'A', nor 'C' -- you call it unmaintained. We say it IS maintained -- because there is a 'B' maintainer (and let's defer arguing about how *well* it is maintained, even in the 'B' sense, ok?) Now, consider xterm: it has an 'A' maintainer, and a 'C' maintainer -- both you. However, on the cygwin lists, we'd call it unmaintained -- because there is no 'B' at all. In fact, cygwin's xterm package is almost two years old: http://www.cygwin.com/ml/cygwin-apps/2005-05/msg00327.html And Harold, who released that package, is no longer with cygwin, having taken a job with StarNet(?) -- there were some contractual issues, IIRC. Because there is no 'B' maintainer, I'd say that *xterm* is unmaintained -- at least as far as *cygwin* is concerned -- even though cygwin users of Harold's ancient package still benefit from your support. Don't try to retcon this thread. that remark reflects poorly on you. For the casual reader, google suggests that Charles Wilson called me a liar. No, it looked to me like you were trying to redefine the terms used in earlier emails, to change the meaning of those emails to something other than what they meant at the time they were originally sent. I now realize that both you *and* I were using different semantics ALL ALONG. Sorry for the confusion. Frankly, I prefer rxvt-unicode on X -- even in non-unicode mode -- because yes (does cygwin finally have unicode support? - no one's mentioned it on this list at all). No, cygwin does not. Cygwin's rxvt-unicode port has limited unicode support because Thomas Wolff provided me with a patch (to rxvt-unicode) that shims unicode support by intercepting certain X calls. You're apparently still confused: the terminal emulator can certainly implement something, but if the applications running in it can't (except as implied, for self-contained locale support), then it's of limited use. That's why I said it was limited, and why I said *I* only used it regularly in non-unicode mode. However, if you LC_CTYPE=en_US.UTF-8 urxvt-X.exe you WILL get UTF-8 support on display, and with appropriate kbd settings in your X-server and .inputrc, limited UTF-8 input support. Also, the 'mined' package provides a fully unicode-aware editor that works pretty well within a unicode-mode urxvt window. See /usr/share/doc/Cygwin/rxvt-unicode-X-7.7.README But all that's not important. Forget that 'unicode' appears in the name of the package, or that the package has some limited support for unicode if you jump thru enough hoops and use some limited set of application progs that understand unicode. Let's call it rxvt-new-version, instead: rxvt-new-version has an upstream maintainer, and active upstream development. So there is an 'A' maintainer for rxvt-new-version. I figured 'A' + 'B' is better than 'B' alone; so I'm promoting rxvt-new-version over plain old rxvt, even if nobody EVER sets LC_CTYPE to anything other than C. But I still maintain (in the 'B' sense, badly, if you like) plain old rxvt. Look, it's not a competition. I like rxvt-new-version AND plain old rxvt, so I'll keep maintaining both for cygwin (however bad I may be doing at that job, in your opinion). If the rest of the world switches to using xterm, more power to 'em, I'll cheer them on. xterm has an 'A' maintainer, and a 'C' maintainer -- both you. It'd be nice if it had a 'B' maintainer, tho... [[[ subthread #2 ]]] Again, if there were an upstream _maintainer_ for rxvt (the point of this thread), they'd have done something useful with the win32 bits mentioned. Well, back when there WAS an upstream maintainer, they kinda DID do something useful with the win32 bits that existed at that time. All of the /old/ win32 bits are in the upstream CVS (such as it is). But all that happened when SteveO was still around, and was the 'B' maintainer for cygwin's rxvt (he also worked closely with the 'A' folks). But all of them, and SteveO, disappeared long ago. So I picked up the pieces as best I could: the current cygwin version of rxvt has a few additional patches beyone what those guys did, but nothing spectacular. Mostly mechanical, and adapting to our build systems (first g-b-s, then cygport). The really *new* win32 bits are in the (currently incomplete) standalone libW11 package, but that and rxvt-W, is a wholly separate effort. There's certainly no cygwin maintainer for that, Here, I believe you mean
Re: Xterm, rxvt, mrxvt, etc....
Thomas Dickey wrote: On Sat, 5 May 2007, Charles Wilson wrote: The fact is, rxvt upstream is dead, dead, dead. It has shuffled off this mortal coil. Joined the choir invisible. It is an EX-terminal. The terminal is terminal. thanks for agreeing with me. It has no maintainer. Not so fast, Thomas. I did not and do not agree with your previous posts: neither of your messages claimed that upstream rxvt has no maintainer. (If they did, then I would have agreed with that.) Your messages claimed that rxvt had no cygwin maintainer. That claim is false: I am the cygwin maintainer for rxvt. Don't try to retcon this thread. Frankly, I prefer rxvt-unicode on X -- even in non-unicode mode -- because yes (does cygwin finally have unicode support? - no one's mentioned it on this list at all). No, cygwin does not. Cygwin's rxvt-unicode port has limited unicode support because Thomas Wolff provided me with a patch (to rxvt-unicode) that shims unicode support by intercepting certain X calls. -- Chuck -- 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: rxvt-20050409-4 compilation issues
Jason Curl wrote:
Hello all,
I'm having compilation issues with RXVT-20050409-4, after following
instructions in the /usr/share/doc/Cygwin/rxvt-20050409.README file.
In particular I'm doing:
cygport ./rxvt-20050409-X.cygport all
and it appears to fail because the xpm.h libraries don't exist. I
checked the W11 directory, and sure enough it isn't there.
That's because the rxvt cygport file has this:
src_prep_init_hook() {
cd ${SRC_DIR}
apply_patch ${origsrcdir}/${PN}-import-xpm.patch
}
But the official cygport has not yet integrated my patches that enable
this bit of magic to work. You need a modified cygport...this is true
of a lot of my packages, unfortunately. I needed facilities that were
not present in cygport, so I added 'em and posted my cygport patches (7
or 8 of them, at last count) to the mailing list. However, Yaakov is
quite busy at the moment
(http://cygwin.com/ml/cygwin-talk/2006-q4/msg00159.html) so rather than
delay my packages until the cygport changes were integrated, I released
them anyway.
But you can't build them without the update cygport. This particular
.cygport requires the patch posted here:
http://cygwin.com/ml/cygwin/2006-11/msg00719.html
patch #1
--
Chuck
--
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/
gtk2/glib version mismatch?
The current version of glib2 on cygwin is 2.10.3-1.
The current version of gtk2 on cygwin is 2.6.10-1.
gtk2 (prior to 2.8.x) uses the GMemChunk interface. 2.8.x and later use
the slice allocator.
glib-2.10.x deprecates the GMemChunk interface:
#if !defined (G_DISABLE_DEPRECATED) || defined (GTK_COMPILATION) ||
defined (GDK_COMPILATION)
typedef struct _GAllocator GAllocator;
typedef struct _GMemChunk GMemChunk;
...
Now, this causes no problems when building gtk2(2.6.x) *itself*, thanks
to the GTK_COMPILATION switch. However, many of gtk2(2.6.x)'s public
interfaces use the GMemChunk symbol:
gtk-2.0/gtk/gtkstatusbar.h
---
...
struct _GtkStatusbarClass
{
GtkHBoxClass parent_class;
GMemChunk *messages_mem_chunk;
...
---
This means that gtk clients may NOT compile with -DG_DISABLE_DEPRECATED.
Disallowing deprecated interfaces is a good thing -- because
deprecated interfaces bitrot quickly. However, on cygwin we're stuck,
because our gtk2 packages are older than our glib, and use/expose
interfaces that are deprecated in our newer glib.
Gerritt -- can you update the gtk* packages to 2.10.x?
--
Chuck
--
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: Default directory is C:\PROGRA~1\RATIONAL\RATION~1\NUTCROOT\mksnt\?
Larry Hall (Cygwin X) wrote: Without the benefit of all the info that http://cygwin.com/problems.html recommends, I can hazard a guess that you have a copy of the MKS tools installed. These tools will conflict with the like named tools in Cygwin. Your best bet is to remove them. You'll likely find little advantage to having them both and you certainly invite difficulties if you decide to keep them both. Not entirely true, Larry. If he *were* to remove that installation of MKS, he would then discover that his Rational Rose/Clearcase/Clearquest installation was broken. IBM's Rational toolkit relies on having those MKS tools available (and no, they cannot be coerced into using cygwin's tools instead). (It's the automation stuff behind the scenes which requires MKS, not the cmdline 'cleartool' app; you can still call the cmd line 'cleartool' executable from cygwin if you want, without conflicting with MKS) If you want both installed, you must make sure that one environment doesn't see the other. That includes manipulating your PATH appropriately and all your other shell variables. In particular, you've already found that MKS has set SHELL to point to it's version. Yep, that's the key. I simply set my cygwin dotfiles to override those nasty Rational variable values. PATH TERM SHELL TERMINFO will do it. (you can include the dir in which cleartool.exe lives in your cygwin PATH; that's a different dir than the MKS junk). You'll likely see other problems like this as well. As I said, the easiest thing to do is to uninstall MKS and rely on the Cygwin version of these tools for your needs. Unless, of course, he actually wants to be able to USE the Clearcase/Clearquest/Rose tools AT ALL. Which is likely, as he's got them installed. Obviously, you are free not to take this advice but your configuration will generally be considered non-standard by those who frequent the Cygwin lists so further problems you may have as a result your MKS installation is likely to fall on deaf ears. ;-) Or, he could get it working and assist Corinna in testing the latest snapshot... - Reintroducing the dirent member d_ino. 1.5.20 tries hard to return a useful d_ino value, which is supposed to be also the same as st_ino as returned by stat(2) in all cases, regardless of the obstacles to do this on Windows. Do you have strange file systems like HPFS or ClearCase? -- Chuck -- 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: Looking for Cygwin/X maintainer
Alan Hourihane wrote: But, yet more thoughts. Given that Chris Corinna want a more active person to maintain Cygwin/X - I should stand down anyway. Thanks for having me. Please don't go away mad. :-) Better, please don't go away, even if you do stand down. Even beyond the be really active on the mailing list thing, tho, the current status of cygwin/x needs a bit of explanation if ANYbody is going to take over the maintainership. I'd be a bad choice -- heck, I'm doing a pretty poor job with the packages I supposedly DO maintain -- so I'm not volunteering -- but I can see some issues even so. Before Alan steps down, or during his transition period, there are a few questions that need answering before the next sucker^Wvolunteer could even begin to get a handle on things. What is the current status of cygwin/X source code, release methodology, and what are the plans for the future and the status of their implementation? I'll tick off what I think is true, and look forward to being corrected. 6.8.2.0-x (where x=1,2,3,4 depending on the specific package) The current stable cygwin-xorg release is 6.8.2.0, which is a monolithic imake-driven build and lives in /usr/X11R6. It can be built by either downloading all the relevant -src packages, unpacking them in the same location, OR doing a cvs checkout from the CYGWIN branch cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xorg co -r CYGWIN-6_8_2-MERGE xc I'm ignoring cygwin-x-docs for right now. Because this is a monolithic release, the instructions here or here http://x.cygwin.com/docs/cg/prog-build-native.html http://x.cygwin.com/docs/cg/prog-build-cross.html will work. This release was originally packaged by Alexander Gottwald in July 2005. It is a mystery how this packaging was accomplished, as http://x.cygwin.com/docs/cg/prog-distribution.html was never updated (it currently reads Wait for these instructions to be updated, sometime after 2004-04-03.) ago is still around, monitors the list, and maintains a few (non-core) X-related packages like X-startup-scripts, X-start-menu-icons, and run. However, he is unavailable for advice or assistance with the core cygwin/x stuff: http://cygwin.com/ml/cygwin-xfree/2005-07/msg00118.html 6.8.99.901-1 -- The cygwin-xorg test release is 6.8.99.901-1 which is a monolithic imake-driven build, based off of one of the final release candidates for xorg-6.9.0 (aka X11R6.9). It also lives in /usr/X11R6. It can be built by either downloading all the -src packages, unpacking them in the same location, or doing a cvs checkout from the main branch cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xorg co -r XORG-6_8_99_901 xc Again, ignoring cygwin-x-docs. Also again, because this is a monolithic release, these instructions http://x.cygwin.com/docs/cg/prog-build-native.html http://x.cygwin.com/docs/cg/prog-build-cross.html will work. This release was originally packaged by Alan Hourihane in October 2005. Obviously there were changes to the source code between 27 Oct 2005 (when Alan packaged our 6.8.99.901 version) and 21 Dec 2005 (when the real xorg 6.9.0 was released, and the xc monolithic tree was frozen). It is unknown if any of those changes materially affect cygwin/X. Again, the packaging is a mystery, because while Alan stated in http://cygwin.com/ml/cygwin-xfree/2005-10/msg00100.html that currently the scripts that build and package Cygwin/X are based on the monolithic tree I, at least, can't find those scripts in the cvs repository. BUGS: - Nicholas Wourms reported in http://cygwin.com/ml/cygwin-xfree/2005-10/msg00127.html that 'xcursorgen and the icon sets' were missing from this test package. (He also mentioned the DPS libraries, but that's not a bug: they are being phased out by xorg team). This release is still in 'test' after four months. Plans and status thereof (1) CYGWIN branch merge-to-HEAD Alan originally planned to migrate any specific changes in the CYGWIN branch over to HEAD: http://cygwin.com/ml/cygwin-xfree/2005-10/msg00122.html I'll be working on getting whatever changes exist on [the CYGWIN] branchover into the mainline trunk code next. But that statement was made AFTER the 6.8.99.901 test release and there is no indication of whether that actually happened -- or if it was even necessary (it's possible that there were no differences between the CYGWIN branch and the HEAD branch as of 27-Oct-2005). Nor is it known whether any of these CYGWIN-branch-only changes, IF they even exist, were merged to the modular codebase. (2) Migration to modular tree Because xorg is transitioning to a modularized build architecture using the autotools instead of imake, X11R6.9 is the last monolithic release -- and the xc directory is now CLOSED for any further development as of 21 Dec 2005 (http://lists.freedesktop.org/archives/xorg/2005-December/011752.html). Thus, any
Re: rxvt fonts size setting problem for X/Cygwin
Igor Pechtchanski wrote: I don't know of an easy way to dispatch to a font name based on whether you're running X or native. You could try playing with window names and using this as a selector in your .Xdefaults... Igor Here's what I do: (1) ~/.Xdefaults has the following (if you ignore the silly mailer line wrapping): rxvt*background:#40 rxvt*foreground:#bf rxvt*scrollBar: true rxvt*scrollBar_right: true rxvt*font: -bitstream-bitstream vera sans mono-medium-r-normal--*-120-*-*-m-*-iso8859-1 rxvt*boldfont: -bitstream-bitstream vera sans mono-bold-r-normal--*-120-*-*-m-*-iso8859-1 rxvt*saveLines: 1 rxvt*loginshell:true rxvt.backspacekey: ^H (2) I have a shortcut to start rxvt-X with the following target (where 'runrxvt.exe' is a copy of run.exe): C:\cygwin\bin\runrxvt.exe -display 127.0.0.1:0.0 -tn rxvt-cygwin -e /usr/bin/bash --login -i One thing I haven't worked out is, if I click this shortcut with no X server running, I get a gigantic rxvt-native window with absolutely huge font. But that's my error; I just close the window, start the X server, and go again. Problem solved. (3) I have a shortcut to start rxvt-native with the following target (ditto runrxvt.exe): C:\cygwin\bin\runrxvt.exe -display :0 -fn Bitstream Vera Sans Mono-16 -tn rxvt-cygwin-native -e /usr/bin/bash --login -i The colors and other settings from the .Xdefaults file are actually used by both versions -- but the rxvt-native one uses the command line -fn font instead of the .Xdefaults value. (I also have 'rxvt' aliased depending on the current value of $TERM, so that subsidiary rxvt windows launched from the command line 'inherit' X-ness or Native-ness, but that's a different issue). -- Chuck -- 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: Consensus about man and doc X11 directory structure
Yaakov S (Cygwin Ports) wrote: What does Cygwin native mean? If Cygwin is meant to be a POSIX environment, then X11 should be the standard for GUI apps. Not gonna happen: it has been stated before on this list that 'insight' *must* run without X -- which means that tk will remain Win32GUI. It may be possible, eventually, to have both win32GUI-cygwin-runtime-tk and XGUI-cygwin-runtime-tk on the same machine, but nobody has undertaken the daunting task to make that happen. Ditto gtk. However, I don't see the problem in assuming that GUI apps are presumed to be X-flavor (with the tk exception, above). If at some point somebody figures out how to build a similar GUI app/toolkit in the opposite flavor, it can go in /opt/. -- Chuck -- 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: Consensus about man and doc X11 directory structure
Yaakov S (Cygwin Ports) wrote: Others have mentioned building *NIX tcl/tk on Cygwin, and I wouldn't call building gtk2 daunting; Daunting to build it in such a way that (a) the win32 version doesn't interfere with the X version, (b) vice versa, and (c) you're SURE that nothing win32-runtime 'leaks' into either version, but ONLY win32-GUI gets into the win32 version. I'm not personally interested, as I'm focusing on the X11 ports. What's stopping us from moving the Win32 tcltk in /opt/win32, and making new *NIX tcl and tk packages in /usr? Then all that's necessary for insight is to add /opt/win32 to PATH (either through a script, profile.d, or manually). Similar packages (i.e. that have both X11/*NIX and Win32 flavors) could use /opt/win32 as well. All of this mucking about with tk and insight requires the concurrence of -- and oodles of extra work by -- the tk maintainer and the insight maintainer. Plus, speculation alert given the centrality of the debugger to the GNUPro product, this sort of change might meet resistance from the PowersThatBe channeled thru our local Benign Dictator(s). Good luck with that. -- Chuck -- 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: Emacs problem after rebaseall: some progresses?
Angelo Graziosi wrote: After the new release of rebase-2.4-1, the problem remains BUT this time reinstalling, with setup, ONLY the package libncurses7 (whose current release is 5.3-4), EMACS works again! Rebasing all and then reinstalling a package that has just rebased : is it a valid procedure? Sure, this is fine. But what you're really saying is that one of the dlls in libncurses7 used by xemacs /usr/bin/cygform7.dll /usr/bin/cygmenu7.dll /usr/bin/cygncurses7.dll /usr/bin/cygpanel7.dll is not rebase-able. I'm not clear on the history; there was a time when a number of DLLs were considered not rebase-able but I don't remember why, or whether the issue was ever fixed (in rebase.exe, or in the DLLs themselves). *I* wonder, if xemacs were rebuilt against the CURRENT ncurses libraries (libncurses8), would it still have similar problems -- e.g. would you need to rebaseall and then reinstall libncursesEIGHT? If so, it's a problem I need to track down, as the ncurses maintainer. If not, then the XEmacs maintainer should simply release a new version, recompiled against the new ncurses. -- Chuck -- 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: Emacs problem after rebaseall: some progresses?
Angelo Graziosi wrote: as the title of this mail says, it is Emacs (21.2-13, 21.3.50-2, started from X), NOT XEmacs (21.4.17-1, 21.5.16-1), that has problems after rebasing all the system. Fine, Emacs, XEmacs, whatever. That's not the point The problem. There are applications that need rebasing (... unable to remap...). But after rebasing all, Emacs does not show its window and take almost 100% of CPU (one can only kill it). If one reinstall libncurses7-5.3-4, Emacs works again as it should. For what I know, Emacs is the only X application that has this problem. And, is it the only X application that links against an obsolete version of the ncurses library? e.g. is it simply that cygncurses-7.dll cannot be rebased without causing troubles for client apps -- and cygncurses-8.dll, used by all other X apps, is fine? The *E*macs maintainer should relink/rebuild *E*macs against cygncurses-8.dll, rebase, and see if the problem (e.g. the necessity of undoing the rebase of cygncurses-8.dll by reinstalling that package) remains. If the new *E*macs works with a rebased cygncurses-8.dll, then the problem is solved: cygncurses-7.dll is broken, and if it weren't obsolete it should be fixed. But, since it IS obsolete... Now, if the *E*macs maintainer does all this and the problem remains -- after rebasing, *E*macs is broken unless cygncurses-8.dll is reinstalled -- THEN we'll have something to talk about. -- Chuck -- 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: Obtaining older packages...
Don't forget the Cygwin Time Machine: http://www.fruitbat.org/Cygwin/index.html#cygwintimemachine ftp://www.fruitbat.org/pub/cygwin/circa/index.html -- Chuck
Re: Tcl/Tk wish and Cygwin/X
Markus Jung wrote: I have a strange effect with my cygwin/x environment. I've downloaded a Tcl/Tk application called secpanel. secpanel is a application tho manage ssh connection with a x-window interface. Now, my problem is if I start the secpanel application with wish, it won't come up in my windowmaker x-environment. It comes up in my normal XP environment an thats not the way I want it. I need this application in my x-window environment. Search the archives for tcl/tk and X. It comes up every blue moon, but cygwin's tcl/tk package is really only there as a prerequisite for the insight debugger. Which, if you're debugging an X app -- or any embedded app for, say, Red Hat eCOS -- you want the debugger to appear as a native Windows app. No X server. So, cygwin's tk package is MSWin, not X. There was some talk about providing a split personality version of tk (either X or MSWin, like XEmacs is) -- but that talk only got to the dabbling stage. The current maintainer of tcl/tk, cgf, is understandably not enthusiastic about embarking on this effort. However, if somebody else would like to make it happen, cgf might be convinced to turn over official maintainership of the package to that person. Maybe. -- Chuck
Re: Installing tcltk does not force installation of XFree86-prog
Marc Daumas wrote: ...although X11/Xlib.h is needed. You've stuck your finger right on a sore spot. tcltk is a *native MS windowing* port of tk (tcl is GUI-agnostic; tk is the important bit wrt display technology). The X11/Xlib.h file that cygwin's tk wants is NOT the one distributed by cygwin-xfree. Neither will tk work with the X11/Xlib.h file distributed with xpm-nox. Both tk and xpm-nox have their own fake Xlib.h files -- xpm-nox ships it in /usr/local/xpm-nox/X11/xlib.h. cygwin's tk doesn't ship its version of that file at all. Go here http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/ and download tk-includes-8.4.tar.bz2 Unpack it somewhere so that you can explicitly use -I /this/way/to/tk's/X11/Xlib.h but be careful not to clobber the real X11/Xlib.h -- Chuck
Re: libtool created import libs broken? was RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault
Brian Ford wrote: Charles Wilson, Could you look at the problem discovered in the thread below and give us a comment? Thanks. http://www.cygwin.com/ml/cygwin-xfree/2003-12/msg00053.html There are a couple of problems. 1) OOB, DDD uses libtool-1.4.2 -- which has very minimal support for cygwin. It works (barely) -- and it takes a whole chapter in the autobook http://sources.redhat.com/autobook/ to explain the differences from normal unix shared lib creation. The new 1.5+ procedure (with binutils/gcc autoimport, autoexport, and .dll.a naming convention support) is much more unix-like. Although ltmodules don't seem to work very well, except in toy cases. :-( 2) Old libtool, when it finds a .la file (which specifies the DLL name and the static lib name, AND the import lib name) doesn't appear to handle the implib properly -- it thinks that it does not exist, and attempts to recreate it from scratch using the export table from the DLL. But it uses old, buggy, obsolete, unmaintained, code to do so. Now, there are only four libraries in your link list that have .la files: expat, fontconfig, freetype, and Xm. And whaddaya know -- those are precisely the libs that cause problems in your link command. QuickNDirty answer: hide those four .la files and re-run configure. Long answer: update to the most recent autotools (relibtoolize). However bash-2.05b$ autoreconf --install --force These are just warnings, so I think this part worked fine. I guess the ddd people should clean these up? Yes, they should -- when they are ready to move to autoconf-2.5x, automake-1.7.x, and libtool-1.5+. But as you can see, there are incompatibilities between autoconf-2.13 and -2.5x. Basically, you CAN write a configure.in file that works with both -- but 2.13 was much more forgiving than 2.5x, so most existing configure.in's need to be brought up to 'spec' in order to work with 2.5x. And the _easiest_ way to do THAT is to make changes to the configure.in that are NOT backwards compatible with 2.13! So, it's possible to allow both versions to work with your configure.in, but much harder than just upgrading in a non-backwards-compatible way. So most projects (like gcc/binutils until recently) have taken a wait-and-see approach to autoconf-2.5x. Which leaves us poor cygwin folks, who NEED libtool-1.5 for decent DLL support, out in the cold -- because libtool-1.5 requires automake-1.7.x which requires autoconf-2.5x... (And, even though it is conceivable to use ac-2.5x with old-style automake-1.4p6, the cygwin wrapper system doesn't let you do that. So, if you re-autoconf with ac-2.5x, you'll also need to re-automake with am-1.[67].x -- which brings its own share of possible incompatibilities in the Makefile.am's. And you'll want to add -no-undefined to the libX_LDFLAGS setting for any libraries that DDD builds) configure.ac:248: warning: AC_CANONICAL_HOST invoked multiple times autoconf/specific.m4:363: AC_CYGWIN is expanded from... configure.ac:248: the top level autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' autoheader: WARNING: and `config.h.top', to define templates for `config.h.in' autoheader: WARNING: is deprecated and discouraged. autoheader: autoheader: WARNING: Using the third argument of `AC_DEFINE' and autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without autoheader: WARNING: `acconfig.h': autoheader: autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1, autoheader: [Define if a function `main' is needed.]) autoheader: autoheader: WARNING: More sophisticated templates can also be produced, see the autoheader: WARNING: documentation. Yep, you're gonna have to take care of this stuff by hand. I believe that support for config.h.top etc will be going away in autoconf-2.60, but that's **just** a guess. And anyway, 2.60 isn't expected for at least several months (and 2.59 won't go 'poof' then, anyway) Here is where we should have stopped, although I don't know how to do that with autoreconf. The following are errors from subdirectories that use older (circa 2.13) autoconf scripts. autoreconf does not support mixed versions, I guess? No, not at all. That's why Zack Weinberg (Nathaniel Nerode?) over on the gcc list are updating gcc's (and friends') configure.in's by hand, one directory at a time. Bringing the autotool infrastructure up to snuff for a large project, like DDD, is a significant challenge. And it's not a job that anyone really wants to do -- so if you've the itch, the only person who will scratch it is you. You'll need to do all this work yourself, and then send your patches back to the DDD developers as a fait accompli, and HOPE that they are ready to 'take the plunge', accept your patch, and **force all of their developers to switch to using the new autotools**. It's that last bit that causes trouble. And until they accept the patches and take the plunge, you'll
Re: Updated: xfig-3.2.4-4 and xfig-lib-3.2.4-4
Harold L Hunt II wrote: 2) Consolidate the packages into xfig-lib (graphic symbols library), xfig (everything else). When you remove packages completely, you need to provide a compatibility package that has the same name but higher version number. That way, setup.exe will Do The Right Thing: 1) update obsolete package xfig-etc (or whatever) --- remove xfig-etc(old version) --- install xfig-etc(new version) 2) update xfig --- remove xfig(old) --- install xfig(new == consolidated) But setup reshuffles this into remove and install: 1) remove xfig-etc(old version) remove xfig(old) 2) install xfig-etc(new version = empty, so this is a no-op) install xfig(new == consolidated) And everything Just Works. If you DON'T do that, then setup.exe would just update xfig -- but both xfig-etc(old) and xfig(new) would claim to own the files that were consolidated into xfig(new). So, compatibility packages. (Now, it's possible that setup.exe could [does?] support conflicts: and obsoletes: keywords, in which case that's a better solution than compat pkgs. Ask Robert...) Me, since I'm paying attention, I'll just do it manually: setup-remove all currently installed xfig-related packages, and then setup-install just the new pkgs. But not everybody pays attention -- or reads these little announcements. -- Chuck
Re: AW: cygwin.rules - Enabling shared libXt finally?
Errm, this isn't going to change the public interface is it? That is, if Harold releases another libXt with this change, would that break the recently re-compiled and released lesstif, etc etc? -- Chuck Ralf Habacker wrote: Not sure I understand. What should be changed in the current version of the Xt code? only note 1, chaning the label. The second note is only for completeness. Attached are my curent xc/lib/Xt/[Initialize.c|IntrinsicP.h] files. Please send a diff against these if anything should be changed. Note that these are intentionally from the 4.3 branch. --- Initialize-old.c 2003-10-21 20:21:18.0 +0200 +++ Initialize.c 2003-10-21 20:23:25.0 +0200 @@ -236,8 +236,8 @@ asm (.data\n\ .globl __XtInherit\n\ - __XtInherit: jmp *_$$y \n\ - _$$y: .long ___XtInherit \n\ + __XtInherit: jmp *__$XtInherit \n\ + __$XtInherit: .long ___XtInherit \n\ .text \n); #define _XtInherit __XtInherit
Re: [ITP] freetype2 2.1.5
Harold L Hunt II wrote: Original from http://www.freetype.org/ Questions for other maintainers === 1) freetype2 is built as part of XFree86 right now as a shared library, but configuring with --enable-shared and --disable-static doesn't produce a .dll when building the standalone tree. 2) Any tips for getting the standalone tree to emit a shared library? I tried relibtoolizing it (aclocal, autoheader, autoconf, libtoolize, forcing copy of files) to no avail. Well, it's a bit confusing to me without actually running configure myself, but I can't tell if fontconfig really actually use autoconf/automake/libtool the right way, or if instead it merely uses them to generate a JamFile for the 'jam' package building tool. 3) There is a warning coming from libtool: libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries Well, that's either (a) a warning that the relevant libtool link command line does not contain the -no-undefined flag, which indicates that the maintainer asserts that the library will have no undefined symbols at link time, or (b) an indication that, contrary to expectations, the library DID have undefined symbols at link time. When I get a chance, I'll download your source and see what I can make of it. Ping me if you don't hear in a few days. -- Chuck
Re: AW: Enabling SHM support in default build of XWin.exe
Ralf Habacker wrote: ... if linked to the static ipc-library. Using the cygipc dll results in an additional runtime dependency, which will produce windows runtime linking errors if the cygipc package isn't installed, which will produce more support noise dealing with this issue. Using the static library avoids this problem. I think that you *should* use the DLL. And add cygipc to the setup.hint requires: of XFree86. Not because I think that everyone should or will 'turn on' the daemon, but because: you can't use libtool to make a DLL that has static dependencies (without heroic effort). Now, I know that XFree86 does not use libtool, but maybe I want to build gtk or something that (a) does, and (b) links to XFree86 libs. Since, in this scenario, the XFree86 libs will have a link time dependency on libcygipc.a -- I won't be able to build a DLL version of gtk (without heroic effort). What's the support issue you're worried about, Ralf? One more requires: library? When Harold is busy spinning out expat, fontconfig, and freetype -- what's one more? -- Chuck
Re: cygwin 1.5.3-1
Ralf -- What happens when you run your cygipc-based build of X11, but do not have the ipc-daemon running? You can't run KDE, of course, but does the Xserver itself still work properly? Can non-KDE X apps work? -- Chuck Harold L Hunt II wrote: Well, that makes it easy. SHM will not be supported by this new build. Harold Christopher Faylor wrote: On Thu, Sep 04, 2003 at 04:45:34PM -0400, Harold L Hunt II wrote: I am not sure. How automagically is the IPC daemon installed? If it requires user intervention, then we cannot really have XShm in the default install. You could make it a setup.hint dependency, of course, but that's only half the battle. The next step would be to get the cygipc daemon started. I don't think you want to go through that pain unless there is a clean fallback for when cygipc isn't working right.
Re: Error building glib-2.2.1 from source 8-(
You have to re-libtoolize using the latest libtool. I posted a patch (for 2.2.0) to the main cygwin list on Jan 03, 2003. --Chuck Chris Olive wrote: I'm trying to build glib from source (from www.gtk.org FTP mirror), and I end up with the following error during make: OUTPUT make[2]: Entering directory `/cygdrive/c/xfer/glib-2.2.1/gobject' /bin/sh ../libtool --mode=link gcc -g -O2 -Wall -o libgobject-2.0.la -rpath /usr/local/lib -version-info 200:1:200 -export-dynamic -no-undefined gboxed.lo gclosure.lo genums.lo gobject.lo gparam.lo gparamspecs.lo gsignal.lo gsourceclosure.lo gtype.lo gtypemodule.lo gtypeplugin.lo gvalue.lo gvaluearray.lo gvaluetransform.lo gvaluetypes.lo ../glib/libglib-2.0.la -lintl *** Warning: This system can not link to static lib archive ../glib/libglib-2.0.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. libtool: link: warning: `/lib/libintl.la' seems to be moved /OUTPUT I've tried ./configure --enable-shared=yes (it's 'yes' by default anyway), but this seems to have no effect. As to the libtool warning after the error, '/lib/libintl.la' seems to be moved, this seems to be bogus since the file IS there. My guess is that somehow libtool is not resolving libraries properly, but I'm not really at all familiar with how this all works under Cygwin (I know there are .a and .DLL mapping things going on, but that's about it.) My version of libtool is 1.4.3. Any help getting over this hump would be appreciated. I loathe bothering people on lists unless I'm just out of options, which I feel I a (again after much research). I don't see any other options under ./configure for building glib-2.2.1 that present any other possibilities. Even if there is no known solution, if someone could just help me decipher the above errors -- what it probably means -- I can go from there most likely.
Re: how to enable magic cookies on W2K cygwin X11?
Alexander Gottwald wrote: [some stuff about magic cookies] cygutils contains the mcookie program from util-linux, if that helps. (It may not; I don't know much about X) NAME mcookie - generate magic cookies for xauth SYNOPSIS mcookie [-v] [-f filename ] DESCRIPTION mcookie generates a 128-bit random hexadecimal number for use with the X authority system. Typical usage: xauth add :0 . `mcookie` --Chuck
Re: new runtime pseudo-reloc in cygwin 1.3.18
Alexander Gottwald wrote:
So I don't even know where _XtInherit is called and whats different with the
relocation.
gdb revealed:
Dll1 (libXt) defines void _XtInherit(). Dll2 (libXaw) uses _XtInherit and
passes it to a function in libXt which does
if (x == _XtInherit) { foo() };
Unfortunatly it is not the same if _XtInherit is used in libXt or libXaw.
the statement x = _XtInherit for example resulted in
x = 0xb38478 for libXt and
x = 0x641550 for libXaw. And thats why the if condition failed.
I seem to remember that pointer comparisons across a DLL boundary is a
Bad Thing; relocations and such. But I don't remember where I saw that
-- MSDN or ld docs, and I can't find it now. :-(
--Chuck
Re: new runtime pseudo-reloc in cygwin 1.3.18
Alexander Gottwald wrote: Alan Hourihane wrote: I'm about to commit a patch to the XFree86 CVS that uses the new relocation code in cygwin 1.3.18. This allows us to create the last few libraries as shared code. How will this affect people with cygwin 1.3.18? It won't affect them (adversely). All that matters is that the developer's system has cygwin = 1.3.18 (and developer also means anyone who is attempting to *compile* an X-based program, not just those who are compiling XFree86 itself). E.g. pure users who don't compile anything, will be fine. They can run the new binaries. --enable-pseudo-reloc tells the linker don't worry about multi-word data imports; the runtime will fix them up. And, the runtime is actually a snippet of *static* code that gets linked into the dll/exe -- this static code is included in libcygwin1.a. Since it's static (e.g. not in cygwin1.dll), every compiled program/dll that needs it will have its very own copy; it doesn't matter if the user has an old version of cygwin1.dll. --Chuck
Re: 8 bit PseudoColor problem
Harold L Hunt II wrote: I wouldn't say that PseudoColor support is sketchy. I mean, it works fine either in fullscreen or if you are running Windows in 8 bit color mode. Granted, PseudoColor is not available when you are running in windowed mode with Windows set at higher than 8 bit color. Correct. Are you telling me that Cadence still does not work with Cygwin/XFree86 even when you are using one of the two options outlined above? That would be disappointing because I did put a lot of time into the PseudoColor support and I was pretty certain that it was working properly. Hmm... Well, it's also the fact that *cadence* uses PsuedoColor poorly. It wants a private colormap, which means lots of fun colorflashing, unless you have support for multiple 256color psuedocolor maps within the same display. AFAIK, only Solaris's Xserver actually implements this. Now, Cadence is ALSO ugly when hosted by XWin32. *But*, because Xwin32 supports multiple windows, the ugliness only affects cadence, and not any other windows you might have open. In my case, if I'm using an Xserver in full screen mode, then I tend to open up xterms and other windows inside it -- which means they all get affected by the 8bit colorflashing. OTOH, if I'm Xhosting an app using an Xserver that supports multiple windows, then I open up cygwin rxvt (native) rxvt windows, and native windows editors, etc. And only cadence is affected by the 8bit issue -- so it's tolerable. As I said, it has been a long time since I've tried it using the cygwin-xfree server, but that's my recollection. --Chuck
Re: 8 bit PseudoColor problem
He's referring to a very old message on this list concerning 8bit PseudoColor support in cygwin-xfree and Cadence. Cadence is a CAD package that requires that feature -- and since PseudoColor support in cygwin-xfree is sketchy at best, you can't really use it to xhost cadence. (Which is the primary reason I'm still using XWin32, personally). Stephen -- nope, I don't think you can xhost cadence using cygwin-xfree yet. (And next time, include a little background. Not everybody instantly recalls every message on this list from the past four years) --Chuck Harold L Hunt II wrote: Wow, with all of that information that you gave, we will be sure to answer your question very quickly! Harold Allott, Stephen wrote: I have just run across this problem using Cadence and wondered if it ever got solved?
Re: Incorrect version in packages names
Ralf Habacker wrote: The naming was probably inherited from linux, where it is possible to have both kde (1) and kde (2) and kde (3) all installed on the same machine. Therefore, each needs different basename. If the kde-cygwin folks want to maintain that package-name distinction, then they should just use kdelibs_2 instead of kdelibs-2 as their basename. Then upset and setup will be happy -- and end users will be able to install both kdelibs_2 and kdelibs_3. What about kde-x. Must it be named kde_x ? No, kde-x is fine. The problem is, the parser can't tell if the grouping after a '-' is part of the package name or package version, when the grouping begins with a numeral. kde-2 -- confusinng kde-x -- not confusing --Chuck
Re: [packages] gtk+, glib, imlib
Nicholas Wourms wrote: So? Your point? I don't want to run linux on this machine. My question above was partially a joke and partially a rhetorical one. I don't need to be lectured on the joy and simplicity of the explorer interface (tho neither seem to apply). Let's not turn this into a Microsoft lovefest. My point was that Rootless mode is a fluff setting, something that really isn't that important. Perhaps a better use of time could be spent figuring out how to profile and improve the performance of the X server? Or perhaps making truetype fonts easier for people to use in X? Nicholas -- There are lots of worthy areas why Xserv on cygwin can be improved. You have your priorities, other people have theirs. Unfortunately, you ARE in the extreme minority, so you're going to have to sit back and watch rootless be discussed an implemented. Probably before TT or profiling or ... Why? Go read the Slashdot thread from Sunday, 7 July 2002. Almost every third message was It's pretty good, but it doesn't have a rootless mode. All commercial Xservs on windows have one; this won't be a [serious|real|usable|finished] product until it does, too. There was even one message that basically said This thing sucks ***. It doesn't have a rootless mode. Okay, so the guy was a troll, but nobody contradicted him... We even got two or three spill-over questions which were obviously stimulated by the Slashdot story, where folks we'd never heard of wrote to the mailing list to say Cygwin Xserver is really cool, but I [won't|can't] use it until it has a rootless mode. When will that be? Finally, and most importantly, Harold *wants* to work on a rootless mode. He's scratching his own itch. If you want to work on TT support, nobody is stopping you. -- go scratch. g --Chuck
Re: Incorrect version in packages names
Christopher Faylor wrote: upset would probably do the right thing with the above but I really don't see any reason to use it, regardless. I don't see any reason why a user would need to know that these are kdelibs-2 when it is pretty obvious from the version number. The naming was probably inherited from linux, where it is possible to have both kde (1) and kde (2) and kde (3) all installed on the same machine. Therefore, each needs different basename. If the kde-cygwin folks want to maintain that package-name distinction, then they should just use kdelibs_2 instead of kdelibs-2 as their basename. Then upset and setup will be happy -- and end users will be able to install both kdelibs_2 and kdelibs_3. --Chuck
Re: Problem with cygwin1.dll and xfree
Nicholas Wourms wrote: If I'm not mistaken, I believe WinCVS does tell them to put the dll in system. If so, then they should be vigorously insulted, and possibly shunned. Think of the frenchmen in Monty Python's The Holy Grail. However, I can't find anything prominent on their site that says put cygwin1.dll in naughty places. --Chuck
Re: New xlauncher (was: Re: Success with Java prog in XFree)
Harold Hunt wrote: I haven't had any comments on this program yet because, while it is a neat exercise and will be useful for other work, it will not be distributed with Cygwin/XFree86 until it is written in a language that can be compiled with a free software compiler, preferrably gcc or g++. That's a bit harsh. If you're following the main list, you'll note that there is a large effort right now to get libgcj and the java extensions to gcc working, in the default cygwin gcc package. If you can compile java code with cygwin's gcc, then java progs should be just dandy. Of course, your java app must not rely on opaque native methods (e.g. the Java Foundation Crap^WClasses from MS) --Chuck
Re: New xlauncher (was: Re: Success with Java prog in XFree)
Harold Hunt wrote: That's fine about Java... but that last I knew this xlauncher was a Delphi app. What have you got to say about that :) WTF? I don't follow the xfree list all that closely, but didn't this thread start out as Success with Java prog in XFree? I just assumed that 'xlauncher' WAS that Java prog. Sorry for the confusion. You're right about delphi. :-) On the other hand, there's no reason that Tim couldn't create a package, create a setup.ini, put it up on a web page, and tell folks to point setup there. In fact, setup in its current form, without ANY changes, could be used to install just about anything that's shipped as a tarball -- the end user need only NOT select any official cygwin mirrors, and add user URLs for the desired targets. --Chuck
Re: New xlauncher (was: Re: Success with Java prog in XFree)
Harold Hunt wrote: WTF? I don't follow the xfree list all that closely, but didn't this thread start out as Success with Java prog in XFree? I just assumed that 'xlauncher' WAS that Java prog. Sorry for the confusion. You know... sometimes I'm just not paying any attention at all. What has happened to me?!? A Java xlauncher sounds fine to me, for now. I'd eventually prefer that it be written in C or C++. How large are the Java runtimes for Cygwin? I'm sure we'll get complains along the lines of, ``before I had to install 100 MB for Cygwin/XFree86, now I have to install XX MB more for the xlauncher program, blah''. So I'm not really excited about sticking with Java forever. Feeling like an idiot, You shouldn't. You were correct originally. The xlauncher program IS written in Delphi. The first message in this thread contained the following postscript: PS: I am working on a xlauncher based on the one made available by Tim Thomson but for Cygwin(not only the cuted package from him). I want to include a file text that will contains some definition of servers to access (as IP address, OS, and so on). I will try to make it available. Where should I send it when ready (probably in 1 or 2 weeks) ? That launched the subthread, which was properly marked using the [was: ] construction. The problem here was *my* connection between the xlauncher subthread --- and java. You're not the idiot -- I am. --Chuck
Re: Using only the X server of Cygwin
Hey, Nicholas -- don't squish Rhialto that quickly. He's probably one of our new users who knows nothing about the cygwin project except what he read on slashdot this morning. The fact is, Rhialto, we focus on cygwin -- as an environment all by itself, *and* independent of any specific intended use or resource availability(*). You have a specific setup, where you want to leverage you existing resources (e.g. a local linux-based font server) to avoid downloading extra stuff. You are an advanced (linux) user, with a very specific purpose in mind. That's not the target of the cygwin (or cygwin-xfree) project. It *IS* possible to do what you want -- but there isn't a super-simple one-click path to do it. [Think about user interface design: there can only be a limited number of 'easy' [one-click, two-click] configurations. We use those for the normal users -- folks who want the cygwin environment, not folks who want JUST 'Xwin -broadcast' and nothing else -- or JUST ssh and nothing else). However, it SHOULD be possible -- and checking the ml archives on this will help -- to create a custom 'setup.ini' script or pseudo-package that setup.exe can read, to install ONLY what you want -- but this will take a little work on your part. Again, check the archives. The basic thing is, setup is configured to install the 'Base' package by default (think Debian's 'base' category). Base is about 50Meg unpacked I think. Then, on top of that, there are certain things that the xserv program itself needs -- like libpng's DLL, zlib's DLL, etc. And it downloaded a lot more which it apparently did not even install, such as bash, diff, diffutils, fileutils, etc. These are all part of the 'Base' category. If you explicitly de-selected specific items -- even if they are in the 'Base' category -- then setup shouldn't even download them. There may be a bug in setup.exe's handling of the Base category. Sorry about that. (*) that is, cygwin-xfree should work OOB on a standalong machine without any external font server, at least by default. Do we really want a windows newbie to understand oh, I also need to install the fonts. Of course not -- we do that by default IF the user installs X. [Linux distros do this too, you know -- if you install XFree86 on Red Hat, you *will* get the fonts.] --Chuck
gcc-3.1.x [was: Re: Using only the X server of Cygwin]
[follow up to the cygwin list; this is getting off-topic for cygwin-xfree.] Nicholas Wourms wrote: Hey, Nicholas -- don't squish Rhialto that quickly. He's probably one of our new users who knows nothing about the cygwin project except what he read on slashdot this morning. I am still cranky about the refusal to include objc in cygwin/gcc-3.1. Look, now is NOT the time for objc. It's too early. gcc-3.1.x is a MAJOR change from 2.95.3. Let's make sure the transition hasn't broken the frontends we CURRENTLY have, before we worry about adding more frontends. (IMO, this holds for java/libgcj, too) gcc-2.95.3: provides gcc,g++, and g77. gcc works in -mno-cygwin mode and regular mode. g++ doesn't really work in -mno-cygwin mode, but it does work in regular mode, with certain threading and exception caveats. g77 is regular only. gcc-3.1.x: Let's insure that cygwin's gcc-3.1.x still works in regular and -mno-cygwin mode. Ditto g++ (and since cgf already made changes to enable better -mno-cygwin operation in g++, let's verify that, too). Does g77 still work? The spec file has been totally rewritten. Can we still build DLLs? Does auto-import still work (technically a binutils issue, but that's been upgraded for the first time in eight months just now, too). How about exceptions and threading? Supposedly those are better behaved now -- is it true? What about raising exceptions from within DLLs -- cgf hinted that this probably won't work; also there's a recent binutils patch from Egor that should help with that issue but it hasn't yet been accepted b/c egor needs to fill out the assignment paperwork for FSF...PLUS egor has a cygwin kernel patch that USES his binutils patch... My point: there's a LOT to do right now, with just gcc and g++. Let's not borrow ObjC/Ada/Java trouble just yet. Good grief, the first test release of cygwin-gcc-3.1 was ONLY released less than 24 hours ago. !! Test what we HAVE, before piling on with feature requests !! Boy, I'll bet cgf now knows what Linus feels like the day after a kernel freeze is announced... --Chuck P.S. follow up to the cygwin list; this is getting off-topic for cygwin-xfree.
Re: Possible bug of the M$ windows manager ? or, XFree bug ?
Nicholas Wourms wrote: People, For the love of God, bzip2 is there for a reason, please use it. Some of us have high mail volume and low mailbox quotas. actually, bzip2 would probably not do a very good job compressing a png. (I said PROBABLY. No need to post 27 counterexamples). However, pngcrush would probably help. --Chuck
Re: By the way...
Harold Hunt wrote: 2) In libiconv-1.7-2.sh, prefix is set to 'prefix=/usr/local'. That should be changed to '/usr' before this package is released, right? Yes. I'm sorry Chuck. I just read the link that you sent to an email that you wrote... with very detailed answers to both of my questions. Don't sweat it. What Cygwin directory do you think libiconv should go in? The regular one -- cygwin/release/*. It's not x-specific. But now that I look closer, you should probably refactor the .sh script to package things up right from the beginning: release/iconv/ release/iconv/iconv-1.7-X.tar.bz2 (*) release/iconv/iconv-1.7-X-src.tar.bz2 release/iconv/libiconv2/libiconv2-1.7-X.tar.bz2 (**) release/iconv/libcharset1/libcharset1-1.7-X.tar.bz2 (**) (*) contains everything except cygiconv-2.dll and cygcharset-1.dll (**) the setup.hint file uses the 'external-source: iconv' incantation I wouldn't bother with splitting out the development files into -devel packages -- iconv doesn't seem to version those as strongly as, for instance, libpng does. --Chuck
Re: Repackaging of WindowMaker and openbox needed ?
Ton van Overbeek wrote: Now it seems that there is a consensus that all X specific stuff should go in /usr/X11R6/bin, /usr/X11R6/lib, Well, if you call Chuck reversing his original position, and Harold agreeing with Chuck's new position, and Earnie smugly thinking 'I was right all along' :-) -- and cgf saying basically 'I don't care' a consensus, then sure... etc. it seems to me that both WindowMaker and openbox should be repackaged to install in /usr/X11R6. Now both WindowMaker and openbox install into /usr/bin and /usr/lib etc. Maybe also libPropList is afected. That's up to the WindowMaker/openbox/libPropList maintainerHarold, I guess. --Chuck
Re: Repackaging of WindowMaker and openbox needed ?
Christopher Faylor wrote: Just to clarify, here's what I said: *I don't think I ever gave an opinion on the /usr/bin vs. */usr/X11R6/bin. My preference is that all official X stuff goes in */usr/X11R6/bin but that seems to be counter to the way most modern *distributions do things. So, if we have good justifications for putting things in /usr/X11R6/bin then I'm happy. Mostly here: http://cygwin.com/ml/cygwin-xfree/2002-05/msg00178.html http://cygwin.com/ml/cygwin-xfree/2002-05/msg00179.html --Chuck
Re: lesstif mwm bug
Christopher Faylor wrote: I don't think I ever gave an opinion on the /usr/bin vs. /usr/X11R6/bin. My preference is that all official X stuff goes in /usr/X11R6/bin but that seems to be counter to the way most modern distributions do things. So, I don't know that we have an actual policy. I was one of the main proponents of all the other dists put everything into /usr/bin, so we should too. Earnie raised the issue about binaries that can exist as either X- or MS-native-windowing, but not simultaneously as both in a single executable (e.g. rxvt). I said fuhgeddaboutit until we actually SEE the problem. And then I saw the problem. tcl/tk. The cygwin version that is currently distributed uses MS-native windowing, for lots of very good reasons. It is installed into /usr/bin, /usr/include, /usr/lib. But what if I want to build an X-based application with tk? I'd need a X-based tk -- which obviously cannot go into /usr/bin, /usr/include, and /usr/lib. So, now I think that REGARDLESS of what those other distributions do, we should segregate X- linked apps and libraries into /usr/X11R6/. Very few other platforms have multiple windowing environments to deal with. The closest similarities I can think of are: 1) X- and terminal-. Two common solutions: a) single binary, operates in either mode (FSF-Emacs) b) two different binaries with different names (vim, gvim) 2) X- and svgalib-. a) Two different binaries with the same name; only one may be installed on a system at a time (Mandrake's graphical Aurora bootup) b) two different binaries with different names () 3) regular X and gtk a) two different binaries with the same name; only one installed on the system at a given time (XEmacs. In fact, Mandrake for instance ONLY provides the gtk version; the normal X- version is no longer available officially). But, these are all VERY rare. Of the thousands of apps out there, most are JUST terminal, or JUST X-, or JUST svgalib. The conflicts just haven't happened often enough for the distributions to come up with a cohesive plan -- they just seem to special case the rare conflicts. I think Earnie's right: these problems will not be rare for us. We want native-windowing apps, and we want X-windowing apps, and sometimes, we want the same program in either/both/ forms (tk, XEmacs, rxvt, gtk(?), etc). To see a real comparison between what they do and what we do, imagine what would happen if Berlin or W or another 2nd-generation X became really popular... So, finally, in summary, IMO, X- linked apps should be compiled and installed with --prefix=/usr/X11R6/ --Chuck
Re: Legacy Installation of XFree86/Cygwin vs. Setup.exe XFree86 Packages
Randall R Schulz wrote: More problem symptoms followed. When the boot process completed the hardware scan and got to the point where the Welcome to Windows 2000 low-resolution splash screen would be taken down and the monitor resolution switched, I instead got a long period of disk activity, which I took to be an automatically invoked file system check (I have all NTFS systems, so I'm not used to this happening and it alarmed me). There was no indication of what was happening (as their ordinarily would be for a checkdsk, either manually requested or automatically invoked). However, once that was done, the system booted normally. Nonetheless, I don't like things like this happening to my system. Actaully, I think the long delay was the copy-on-reboot stage of the cygwin upgrade. I vaguely remember something about XFree needing to update a LOT of in use files, so setup puts those files in the copy-on-reboot list. Fonts? Anyway, copying hundreds of files, one at a time, can take a while... We should probably warn people about this; they could really scrog their cygwin if they interrupt the copy-on-reboot. --Chuck
Re: MIT shared memory extension
Robert Collins wrote: -Original Message- From: Ralf Habacker [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 07, 2002 7:41 AM What about using a new type respective casts for cygdaemon. This would not break key_t compatibility and allows to migrate single application to cygdaemon, while others works with cygipc (at least for a limited time) ? At the moment key_t's are generated locally without the cygserver. This means that in theory a cygipc linked app will still work with the new key_t code after recompiling (I think we do need to remove ftok from cygipc at that point though). If we have a list of key_t's, then it must be global, so cygserver will have to be running. I think that that is bad. Hmmm??? Where would clients get ftok() from, then? Do the cygserver patches to CVS cygwin1.dll add that function to the kernel? Also at the moment, we know that the same file will generate the same key_t every time. (because it's inode based). Ah, a quick 'cvs update' and I see the answer to my question is yes. So, I can't really remove ftok() from cygipc until after cygwin-1.3.11 is released... In short, I don't like the idea of making key_t 32 bits. Yep. --Chuck
Re: MIT shared memory extension
Ralf Habacker wrote: It is possible though to compile xfree86 for cygwin with that enabled, but it haven't been tested, check the mailinglist. It works, we have done so for the kde-cygwin port Yeah, but it requires CygIPC, doesn't it? BTW, has anybody tried to run kde-cygwin using the new cygwin-daemon to provide the IPC services? Currently, the cygwin daemon implements some subset of the three main IPC mechanisms (semaphores, messages. shared memory) -- but I don't remember if shm was part of that subset... Anyway, even if the cygwin-daemon DOES provide the necessary IPC features, you'd probably need to recompile kde-cygwin against it instead of CygIPC. --Chuck the cygwin-daemon code was recently merged into CVS; the snapshots have the functionality but the daemon itself is not turned on by default. Just like ipcdaemon.exe, you have to start up the cygwin-daemon yourself. For more info, see the cygwin-developers mailing list archives.
Re: pkgconfig [Was By the way... ]
Steven O'Brien wrote: There was no circular dependency for glib-1.2.10. In fact when I ported it I had never heard of pkg-config. Oh, I misunderstood you. When you said you configured pkgconfig to build against your installed version of glib, I thought your installed version was 1.3.x, not 1.2.10. (1.3.x does depend on pkgconfig) Sorry for the confusion. Anyway, I have built pkgconfig-0.12.0, with your patch, and gnome-vfs configure works fine with it. So if/when it is adopted as the official cygwin version I will remove pkg-config from my website. Look for an updated package soon, and thanks for taking the time to test this. --Chuck
Re: By the way...
Harold Hunt wrote: ... I added a link to your Cygwin Gnome page to Cygwin/XFree86's Ported Software page: http://xfree86.cygwin.com/ported-software.html I'm very impressed with your work to compile Gnome with DLLs. Keep it up! A couple of things: 1) pkgconfig. I'm the cygwin pkgconfig maintainer, and I'd like to insure that you can use the official version in your port. You are using a patched version of 0.8.0; cygwin distributes 0.10.0; but 0.12.0 is now available. Could you try 0.12.0 (unpatched and/or patched) and see if that works for you? If you must use a patched version of 0.12.0, then I'd consider incorporating that patch into the official cygwin dist; also, in that case, we could submit your patch upstream for incorporation into the real 0.13.0... 2) libiconv/gettext: If someone 'adopts' my setup-compatible package for libiconv -- see thes3 messages: http://cygwin.com/ml/cygwin/2002-04/msg01558.html http://cygwin.com/ml/cygwin/2002-02/msg00467.html and it is included in the official cygwin dist, then I would rebuild the official gettext package to use it. (Yes, I'm also the cygwin gettext maintainer). 3) cygextras: why not submit these as patches to the cygwin DLL? If it is because the code is from gnu libc, then you could in partnership with someone else, reimplement them and submit the result: your partner would actually write the code to the specifications you develop; you would verify that the result operates the same as the current version. (Chinese Firewall). Then, assign copyright on the reimplementations to Red Hat/Cygwin, and submit! 4) berkeley db: folks have been asking for this for a long time. Would you consider packaging it up and submitting it as an official package? (Don't worry about the tcl thing; you needn't be able to run the test suite on an official ports only system). side note: any idea why Gnome doesn't use the GNU database instead? gdbm? 5) libungif: just like libiconv, I have a setup-compatible package for this. If someone wants to adopt it and submit it for official inclusion, contact me offline. --Chuck
Re: mkdll.sh
=${sysconfdir} \
--libdir=${prefix}/lib --includedir=${prefix}/include \
--enable-shared --enable-static )
}
Is the general idea here that I would just be working on the config files
and makefiles, rather than having to make extensive internal changes
to the
way that libraries are loaded?
Yes.
--Chuck
Harold Hunt wrote:
Chuck,
Could you give a few more notes on relibtoolize? A pointer to some good
documentation would be helpful...
Is the general idea here that I would just be working on the config files
and makefiles, rather than having to make extensive internal changes to the
way that libraries are loaded?
Harold
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Charles Wilson
Sent: Tuesday, April 30, 2002 2:48 AM
To: [EMAIL PROTECTED]
Cc: cygx
Subject: Re: mkdll.sh
You could probably do the following:
get rid of mkdll.sh
relibtoolize/autoconf using the -devel tools (e.g. make sure that
configure.in has AC_PREREQ(2.52))
./configure; make;
It oughta work. /famous last words
--chuck
Harold Hunt wrote:
Steve,
I'm working on creating Cygwin setup.exe packages for Gnome...
I know, it's
buggy but I'd like to get a start. One problem I'm having with
your patches
is that they use mkdll.sh but they don't cause configure to
copy the file to
a build directory.
For example:
tar xzf glib-1.2.10.tar.gz
cd glib-1.2.10
patch -p1 ../glib-1.2.10-cygwin.patch
mkdir build
cd build
../configure
[yada yada yada]
make
[yada yada yada]
mkdir .libs
ar cru .libs/libglib.a garray.o gcache.o gcompletion.o
gdataset.o gdate.o
gerro
r.o ghash.o ghook.o giochannel.o giounix.o glist.o gmain.o gmem.o
gmessages.o gm
utex.o gnode.o gprimes.o grel.o gscanner.o gslist.o gstrfuncs.o
gstring.o
gtimer
.o gtree.o gutils.o
ranlib .libs/libglib.a
creating libglib.la
(cd .libs rm -f libglib.la ln -s ../libglib.la libglib.la)
cd .libs PREFIX=/usr sh ../mkdll.sh libglib.la
../mkdll.sh: Can't open ../mkdll.sh: No such file or directory
make[2]: *** [libglib.la] Error 2
make[2]: Leaving directory
`/home/Administrator/x-devel/gnome/glib/tmp/glib-1.2.
10/.build'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/Administrator/x-devel/gnome/glib/tmp/glib-1.2.
10/.build'
make: *** [all-recursive-am] Error 2
Eventually I always reach a point where mkdll.sh can't be found because
configure didn't copy it to the out-of-the-tree build directory.
Got any ideas on how to fix this?
Harold
diff -urN libiconv-1.7-orig/CYGWIN-PATCHES/libiconv.README
libiconv-1.7/CYGWIN-PATCHES/libiconv.README
--- libiconv-1.7-orig/CYGWIN-PATCHES/libiconv.READMEWed Dec 31 19:00:00 1969
+++ libiconv-1.7/CYGWIN-PATCHES/libiconv.README Mon Feb 4 18:46:11 2002
@@ -0,0 +1 @@
+placeholder
diff -urN libiconv-1.7-orig/acinclude.m4 libiconv-1.7/acinclude.m4
--- libiconv-1.7-orig/acinclude.m4 Wed Dec 31 19:00:00 1969
+++ libiconv-1.7/acinclude.m4 Mon Feb 4 18:48:03 2002
@@ -0,0 +1,363 @@
+dnl local autoconf macros
+dnl Bruno Haible 2001-02-04
+dnl Marcus Daniels 1997-04-10
+dnl
+AC_PREREQ(2.50)dnl
+dnl
+dnl without AC_MSG_...: with AC_MSG_... and caching:
+dnl AC_TRY_CPP CL_CPP_CHECK
+dnl AC_TRY_COMPILE CL_COMPILE_CHECK
+dnl AC_TRY_LINK CL_LINK_CHECK
+dnl AC_TRY_RUN CL_RUN_CHECK - would require cross-compiling support
+dnl Usage:
+dnl AC_TRY_CPP(INCLUDES,
+dnlACTION-IF-FOUND [, ACTION-IF-NOT-FOUND])
+dnl CL_CPP_CHECK(ECHO-TEXT, CACHE-ID,
+dnl INCLUDES,
+dnl ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND])
+dnl AC_TRY_xxx(INCLUDES, FUNCTION-BODY,
+dnlACTION-IF-FOUND [, ACTION-IF-NOT-FOUND])
+dnl CL_xxx_CHECK(ECHO-TEXT, CACHE-ID,
+dnl INCLUDES, FUNCTION-BODY,
+dnl ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND])
+dnl
+define(CL_CPP_CHECK,
+[AC_MSG_CHECKING(for $1)
+AC_CACHE_VAL($2,[
+AC_TRY_CPP([$3], $2=yes, $2=no)
+])
+AC_MSG_RESULT([$]$2)
+if test [$]$2 = yes; then
+ ifelse([$4], , :, [$4])
+ifelse([$5], , , [else
+ $5
+])dnl
+fi
+])dnl
+dnl
+define(CL_COMPILE_CHECK,
+[AC_MSG_CHECKING(for $1)
+AC_CACHE_VAL($2,[
+AC_TRY_COMPILE([$3],[$4], $2=yes, $2=no)
+])
+AC_MSG_RESULT([$]$2)
+if test [$]$2 = yes; then
+ ifelse([$5], , :, [$5])
+ifelse([$6], , , [else
+ $6
+])dnl
+fi
+])dnl
+dnl
+define(CL_LINK_CHECK,
+[AC_MSG_CHECKING(for $1)
+AC_CACHE_VAL($2,[
+AC_TRY_LINK([$3],[$4], $2=yes, $2=no)
+])
+AC_MSG_RESULT([$]$2)
+if test [$]$2 = yes; then
+ ifelse([$5], , :, [$5])
+ifelse([$6], , , [else
+ $6
+])dnl
+fi
+])dnl
+dnl
+dnl CL_PROTO(IDENTIFIER, ACTION-IF-NOT-FOUND, FINAL-PROTOTYPE)
+define(CL_PROTO,
+[AC_MSG_CHECKING([for $1 declaration])
+AC_CACHE_VAL(cl_cv_proto_[$1], [$2
+cl_cv_proto_$1=$3])
+cl_cv_proto_$1=`echo [$]cl_cv_proto_$1 | tr -s ' ' | sed -e 's/( /(/'`
+AC_MSG_RESULTPROTO([$]cl_cv_proto_$1)
+])dnl
+dnl
+dnl CL_PROTO_RET(INCLUDES, DECL, CACHE-ID, TYPE-IF-OK, TYPE-IF-FAILS)
+define(CL_PROTO_RET,
+[AC_TRY_COMPILE([$1]
+AC_LANG_EXTERN[$2
Re: By the way...
Steven O'Brien wrote: 1) pkgconfig. I'm the cygwin pkgconfig maintainer, and I'd like I'll add that to the list of jobs ... When I started work on gnome-vfs pkg-config was not in the official cygwin distribution and 0.8.0 was the latest version. I patched it to remove the included glib, so that it uses my glib port. When pkgconfig was added to cygwin I tried it, but gnome-vfs would not build, so I just ignored it. My focus was, and still is, on gnome so doing more work on pkgconfig was of no interest. But I'll certainly try the new one. What was the rationale for removing the included glib? It was put into pkgconfig in order to break the recursive dependence: glib requires pkgconfig which requires glib which ... Granted, the version of glib included in pkgconfig is old (but it's capable enough for what pkgconfig needs) and has a one-line bug when compiling on cygwin; I just patch that and move on... Anyway, if your version of pkgconfig (0.8.0 + local glib) compiled gnome-vfs (on a particular date), yet the official cygwin version of pkgconfig (0.10.0) failed to do so: I would think the problem is either: something broke in the real pkgconfig sources between 0.8.0 and 0.10.0 or gnome-vfs (on the particular date) was either exploiting a bug in pkgconfig-0.8.0, or was otherwise broken. I don't think the answer is to use (and recommend) that cygwinners who want gnome use a old version of pkgconfig with a circular dependency... Thanks for offering to try with real pkgconfig-0.12.0. You'll probably need to apply this patch (if you keep the included static glib): --- pkgconfig-0.10.0-orig/glib-1.2.8/gstrfuncs.cMon Apr 17 11:05:16 2000 +++ pkgconfig-0.10.0/glib-1.2.8/gstrfuncs.c Sat Feb 23 01:38:15 2002 -671,7 +671,7 char *msg; #ifdef HAVE_STRSIGNAL - extern char *strsignal (int sig); + extern const char *strsignal (int sig); return strsignal (signum); #elif NO_SYS_SIGLIST switch (signum) I look forward to seeing the results of your experiment. If you must use a patched version of 0.12.0, then I'd consider incorporating that patch into the official cygwin dist; also, in that case, we could submit your patch upstream for incorporation into the real 0.13.0... As the patch just removes the embedded glib, I think its of no use to the real pkgconfig. Yep, you're right. 3) cygextras: why not submit these as patches to the cygwin DLL? cygextras contains strptime and getdelim. I understand the strptime is coming soon to cygwin anyway, so I'll just drop mine then. getdelim came from the gnu C library. Again its just a distraction from working on gnome, and I'll leave it to others to add it to cygwin. Understood. 4) berkeley db: folks have been asking for this for a long time. No. I don't have any free time to support cygwin packages, although I do have great respect for those, such as yourself, who do. I think that gnome no longer requires version 2.7.7, but has moved on to version 3.x.x. This patched version did actually pass its test suite when I first did it, but I no longer have access to the cygwin tcl port I used, so I cannot reproduce the result. 'Kay. Looks like there's a volunteer on the case... --Chuck
Re: cygjpeg6b.dll not found
Dawson, David W wrote: Goodness!! cygjpeg6b.dll is part of the jpeg package of Cygwin. WindowMaker depends upon this package. As noted in another post, WindowMaker also depends on the tiff package. Now that it has become evident that WindowMaker also needs these (non-default) packages, it could be so-noted in Howard's setup.ini file. (IIF he wants to.) Actually, this is a packaging error in windowmaker. The setup.hint / setup.ini MUST list the required dependencies, for packages intended for distribution via the offiical mirror network. requires: tiff jpeg should appear in the setup.hint. Then, when the website maintainer runs upset, setup.ini will specify the correct dependencies -- and when a users runs setup.exe and selects windowmaker, setep will automatically select the tiff and jpeg packages to satisfy those dependencies. Cool, huh? --Chuck
Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
Robert Collins wrote: -Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 21, 2002 8:33 AM if you select the source for more than one of [bob|bobx|boby], then it is downloaded only once (good) but is unpacked three times. This isn't a terrible thing, but it is a waste of effort This won't change anytime soon. Long term we'll have the concept of a source package - as opposed to a src attribute of an existing package. This will require setup.ini changes to represent properly, so I want all the kinks out first... Like I said, NOT a showstopper. you ONLY see this behavior if you click the src checkbox for multiple packages that all share the same source. It's only downloaded once. When setup is done, you have the source. Behind the scenes, that source package gets installed multiple times. Big deal. IMO, if upset gets the ability to do the right thing with an 'external-src:' directive in setup.hint, then everything necessary for multiple-bin/single-src packages would be in place. --Chuck --Chuck
Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
Robert Collins wrote: -Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 20, 2002 12:59 PM Also, setup must do the following (even without new 'views' and whatnot) Setup should already do that, why not make a test setup.ini and see what happens :]. It's all data driven and there is no requirement for -src packages to follow the same name as the base. Whaddaya know. It works. point setup.exe here: http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/ There are 3 packages, bob, bobx, and boby. only bob has a -src package, the other two have source: lines that explicitly specify bob's source package. It seems to work perfectly -- with only a single niggle: if you select the source for more than one of [bob|bobx|boby], then it is downloaded only once (good) but is unpacked three times. This isn't a terrible thing, but it is a waste of effort If you play around with this, you can clean up by uninstalling the binary packages, and deleting the file /usr/src/bob.file.src. (Or, you can delete /bob.file, /bobx.file, /boby.file, and /usr/src/bob.file.src, and remove the bob, bobx, and boby entries from /etc/setup/installed.db) So, except for the niggle above, if upset were modified to allow the external-src: keyword, then multiple-binary-packages from one -src package would work! (and the niggle isn't a show stopper). --Chuck
Re: xfree packages
Oh okay -- then I can go home (nothin to see here; nope, NOT using the superfast net connection at work for non-work related stuff...nope, not me...) --Chuck Harold Hunt wrote: Charles, Don't bother... I'm already on it. The scripts are modified and I'm just working on packaging it up. Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Wilson Sent: Tuesday, April 16, 2002 11:41 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: xfree packages I can do this -- but what was the outcome of the package name argument? Was it xfree-foo-4.2.0-1.tar.bz2 or xfree86-... or XFree86-...? I'll need to modify the znark script accordingly. --Chuck Christopher Faylor wrote: On Wed, Apr 10, 2002 at 01:22:52PM -0700, Ian Burrell wrote: Christopher Faylor wrote: Yes, please post the setup.hint files that you used. Check out http://www.znark.com/cygwin/. It doesn't include the archive files; my web account doesn't have the bandwidth or quota for them. To generate the packages, download the *.tgz files from cygwin/xfree/binaries/4.2.0 If someone wants to repackage these files into .bz2 format, I'll upload them to a temporary area on sourceware. cgf
Re: info: single install xfree86 + minimal cygwin?
Robert Collins wrote: They were simple changes to the script I wrote to repackage the distributed archives. I'll try to write proper setup.hint files for all the packages. Cool. I'm unclear about how the -src packages (are/should be) handled, since there are a great many binary packages in XFree, but only a few original source packages. In the past, when multiple binary packages are generated from a single source package, we've done the following: ncurses-5.2-?-src.tar.bz2 contains the actual src dist for ncurses/libncurses, with cygwin patches, build scripts, etc However, building this -src generates two binary packages: ncurses-5.2-?.tar.bz2 libncurses6-5.2-?.tar.bz2 So, we create an empty libncurses6-5.2-?-src.tar.bz2 that contains only a single README that says go look over there, in ncurses-5.2-?-src.tar.bz2. Now, this works, and upset/setup are happy (every binary package has a src package) but it is hackish, ugly, and a pain to maintain. Is there a better solution? (Or can we discard the psuedo-src packages without repurcussion? Won't upset be upset by the bin without src problem?) --Chuck
Speaking of debian cygwin
There's another slashdot article: http://slashdot.org/article.pl?sid=01/12/04/13552388 Seems the debian-devel folks aren't too happy about this... --Chuck
