Please upload: docbook-xsl-1.67.1-1
Hi. Please upload new docbook-xsl-1.67.1-1 files: http://telka.sk/cygwin/docbook-xsl/docbook-xsl-1.67.1-1-src.tar.bz2 http://telka.sk/cygwin/docbook-xsl/docbook-xsl-1.67.1-1.tar.bz2 and remove old 1.66.1-2 files. Thanks. -- +---+ | Marcel Telka e-mail: [EMAIL PROTECTED] | |homepage: http://telka.sk/ | |jabber: [EMAIL PROTECTED] | +---+
Re: Internal-wm/rootless observations
After many days of debugging the internalwm code i finally found the actual problem. The rootless code wants the pixmap buffer aligned to 32bit boundaries. If the window width is odd and the xserver is run in 16bpp mode then this is no guaranteed and this leads the strange errors. Internalwm is only usable in 32bit mode. I can reproduce the problem when I change 16bit mode. Usually I use 32bit mode, so I couldn't. This is not an actual problem. The goal should be anyway to work with 32 bit visuals only and have real transparancy. I'm still searching for a clean method to blit 32 bit bitmaps to 16 bit ones. The simple aproach of allocating the bitmap with Could you give me diff? I want to try that. I think we have no reason to use winshadgdi.c in mwextwm mode and some code in winshadgdi.c don't match mwextwm. I have to write winshadrootless? Thanks in advance. -- Kensuke Matsuzaki mailto:[EMAIL PROTECTED] http://peppermint.jp
Cygwin X live on CD
I've built a CD-ROM that runs Cygwin X live from CD in a modest Cygwin environment. It's available at http://xlivecd.indiana.edu/. Briefly, I was messing around to build Cygwin on a USB flash drive and posted to the Cygwin mailing list. Fergus pointed out his instructions for building a Cygwin CD. I realized that we have users who could really use Cygwin X on CD so I applied Fergus' instructions, made some modifications, and added a wizard to give the CD the feel of an application that has the sole purpose of running X. The scripts that I wrote to make the wizard work are under the GPL. Enjoy, Dick - Dick Repasky Bioinformatics Support UITS Cubicle 101.08 Indiana University USA [EMAIL PROTECTED]
Re: Internal-wm/rootless observations
On Wed, 1 Dec 2004, Kensuke Matsuzaki wrote: Could you give me diff? I want to try that. Actually not. Most changes where done in gdb with set var ;) let's do it from memory: in winMWExtWMStartDrawing: hdcNew = CreateCompatibleDC (pRLWinPriv-hdcScreen); /* Describe shadow bitmap to be created */ pRLWinPriv-pbmihShadow-biWidth = pRLWinPriv-pFrame-width;//pRLWinPriv-dwWidth; pRLWinPriv-pbmihShadow-biHeight = -pRLWinPriv-pFrame-height;//pRLWinPriv-dwHeight; + pRLWinPriv-pbmihShadow-biBitCount = 32; /* Create a DI shadow bitmap with a bit pointer */ in winAdjust - /* Query GDI for current display depth */ - dwBPP = GetDeviceCaps (hdc, BITSPIXEL); + /* Set the colordepth to 32 to please rootless code */ + dwBPP = 32; /* GDI cannot change the screen depth */ This is in no way safe and should be wrapped with a check for -internalwm but safe for testing I think we have no reason to use winshadgdi.c in mwextwm mode and some code in winshadgdi.c don't match mwextwm. I have to write winshadrootless? I don't think so. We have way too much code anyway i think. 5 different engines, to code for handling windowed, pseudorootless and rootless code. If we find a safe way to blit from 32bit planes to 16bit planes then this will be quite useful in shadow GDI mode too. Sebastian Haby told me the 8bit pseudocolor patch he made has similar code (blitting from a 8bit plane to 32/24/16 bit). I'll have to check the mail archives at home for this code bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Cygwin X live on CD
On Wed, 1 Dec 2004, Dick Repasky wrote: I've built a CD-ROM that runs Cygwin X live from CD in a modest Cygwin environment. It's available at http://xlivecd.indiana.edu/. Briefly, I was messing around to build Cygwin on a USB flash drive and posted to the Cygwin mailing list. Fergus pointed out his instructions for building a Cygwin CD. I realized that we have users who could really use Cygwin X on CD so I applied Fergus' instructions, made some modifications, and added a wizard to give the CD the feel of an application that has the sole purpose of running X. The scripts that I wrote to make the wizard work are under the GPL. Nice to hear. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re[2]: Problems building X/Cygwin (no XpConfig)
Alex, I actually went to X.org and got latest release of X. IMHO, cygwin documentation sucks. Same goes for the setup tool and packaging. At least DLL still works. If maintainers (are there such individuals?) want to know how these things can be done, I suggest looking at FreeBSD ports. Building an entire environment from scratch is way easier. UWIN that I used several years ago, is nice but not free for commercial use. If you do not need to bother with commercial use I suggest trying UWIN ASAP. Igor. -Original Message- From: Alexander Gottwald [EMAIL PROTECTED] To: [EMAIL PROTECTED], Igor Shmukler [EMAIL PROTECTED] Date: Wed, 1 Dec 2004 01:43:22 +0100 (MET) Subject: Re: Problems building X/Cygwin (no XpConfig) Igor Shmukler wrote: Hello, I am trying to build X/Cygwin. I installed the tools and used setup program to checkout the sources. For some reason programs/Xserver/ directory does not have XpConfig branch. I tried checking out from several alternative locations. Build compains that the directory is missing and stops. X.org repository indeed does have the directory. Any ideas? have you tried cvs update -d? This creates missing directories. Which command did you use? bye ago NP: Iris - Whatever -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re[2]: Problems building X/Cygwin (no XpConfig)
On Wed, 1 Dec 2004, Igor Shmukler wrote: Alex, I actually went to X.org and got latest release of X. IMHO, cygwin documentation sucks. Same goes for the setup tool and packaging. At least DLL still works. If maintainers (are there such individuals?) want to know how these things can be done, I suggest looking at FreeBSD ports. Building an entire environment from scratch is way easier. UWIN that I used several years ago, is nice but not free for commercial use. If you do not need to bother with commercial use I suggest trying UWIN ASAP. yet another blurb. How much have you paid for cygwin? Nothing? You get what you've paid for? No. Actually you get far more than that. But it does not seem to bother you. Hm. Maybe I should put a sign on the website: +--+ | Mailinglist support fees | | | | regular users: free | | dumb-asses:$1| | assholes: $10 | +--+ http://x.cygwin.com/donations.html @Øyvind: Just what I've ranted about in yesterdays mail. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Problems building X/Cygwin (no XpConfig)
On Wed, Dec 01, 2004 at 06:13:46PM +0300, Igor Shmukler wrote: I actually went to X.org and got latest release of X. IMHO, cygwin documentation sucks. Comments like documentation sucks are completely useless and obviously intended to make the sender feel self-righteous and irritate the people who are working on the project. This is not an IMHO. It is a fact. Anyone with any background in software, and particularly in free software, would know that the documentation is improved either by offering specific comments or, even better, by offering actual words to improve it. Inflammatory words like sucks do absolutely nothing towards improving anything and just illustrate the senders unhelpful mindset. I say this, knowing full well that this email will probably be followed by point-missers saying But, the documentation *is* bad! *sob* I can't figure it out, so it *must* be bad. or You should listen to the users! The users! *sob* The rest of this message just continued in kind so, rather than repeatedly make the same points, I will stop here. cgf
Re[3]: Problems building X/Cygwin (no XpConfig)
Is your mother proud of your manners? Alex, I actually went to X.org and got latest release of X. IMHO, cygwin documentation sucks. Same goes for the setup tool and packaging. At least DLL still works. If maintainers (are there such individuals?) want to know how these things can be done, I suggest looking at FreeBSD ports. Building an entire environment from scratch is way easier. UWIN that I used several years ago, is nice but not free for commercial use. If you do not need to bother with commercial use I suggest trying UWIN ASAP. yet another blurb. How much have you paid for cygwin? Nothing? You get what you've paid for? No. Actually you get far more than that. But it does not seem to bother you. Hm. Maybe I should put a sign on the website: +--+ | Mailinglist support fees | | | | regular users: free | | dumb-asses:$1| | assholes: $10 | +--+ http://x.cygwin.com/donations.html @yvind: Just what I've ranted about in yesterdays mail. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Problems building X/Cygwin (no XpConfig)
On Wed, Dec 01, 2004 at 04:36:08PM +0100, Alexander Gottwald wrote: Hm. Maybe I should put a sign on the website: +--+ | Mailinglist support fees | +--+ | | | regular users: free | | dumb-asses:$1| | assholes: $10 | +--+ LOL! You can take comfort in the fact that you've actually accomplished something constructive with your life that has benefitted many people. Contrast that with the documentation sucks people and the people who think that they help by sending cliche-ridden manifestos about the way things ought-to-be done. Even if the documentation did suck and even if the project was horribly managed (both false premises) you can claim satisfaction in the fact that you are actively doing something which is demonstrably helping many people. The critics, no matter how articulate they are (I'm sure there must be at least one articulate critic out there although we haven't seen one here in a while) usually do very little to help. In a free software project, there really is little excuse for someone taking twenty minutes to write a message when they could have spent twenty minutes improving documentation or fixing code instead. cgf
Re: Problems building X/Cygwin (no XpConfig)
On Wed, Dec 01, 2004 at 07:04:16PM +0300, Igor Shmukler wrote: Is your mother proud of your manners? You have got to be kidding me! You wonder into this mailing list firing off content-free criticisms and tell everyone to go to a competing commercial product. And, *you* are talking about *manners*? Alexander, I think you need another support category: totally clueless : $1000 cgf
Re: Problems building X/Cygwin (no XpConfig)
--- Christopher Faylor [EMAIL PROTECTED] wrote: Alexander, I think you need another support category: totally clueless : $1000 nope it should be totally clueless : priceless
Re: Internal-wm/rootless observations
I have been away on a long Thanksgiving vacation so I've been slow to respond. In any case, the 16 bpp modes are problematic but I believe we solved issues with them in the rootless code awhile back. The fundamental problem is that fb assumes screens are always 32-bit aligned. Thus you if a window's pixmap is not 32-bit aligned, fb assumes it can still access the word before the start of a drawable's data. In rootless mode, where windows are located higgledy-piggledy in memory, this is not true. Rootless solves (or attempts to solve) this problem with the SetPixmapBaseToScreen() macro in rootlessCommon.h. The idea is that the unaligned window's pixmap is moved backwards in memory to align it and then a positive offset it given to fb to indicate where the window resides in the pixmap. If there is an edge case where rootless does not work in 16-bits it would be good to track down. This mode is sometimes used on Mac OS X. Hopefully that is helpful. I've got a review today but I can look at this in more detail tomorrow. --Torrey At 4:45 PM +0100 11/30/04, Alexander Gottwald wrote: Hi all, After many days of debugging the internalwm code i finally found the actual problem. The rootless code wants the pixmap buffer aligned to 32bit boundaries. If the window width is odd and the xserver is run in 16bpp mode then this is no guaranteed and this leads the strange errors. Internalwm is only usable in 32bit mode. This is not an actual problem. The goal should be anyway to work with 32 bit visuals only and have real transparancy. I'm still searching for a clean method to blit 32 bit bitmaps to 16 bit ones. The simple aproach of allocating the bitmap with CreateCompatibleBitmap() bitmap-width = width bitmap-height = height bitmap-bpp = dbBPP CreateDIBSection() BitBlt(windowdc, ..., shadowdc, ...) was not working properly. Is CreateCompatibleBitmap reusing the DC from the screen? How can I create a 32bit bitmap if the desktop is running in 16bit? Anyway. Setting the bitmap depth to 32bit fixed the crashes I had the last weeks with rootless but garbled the output. So the goal is to have everything inside the server running at 32bit and let GDI do the colorspace translation from 32 to 16 or 24 bit. @zakki: I've found this in the code if (winIsInternalWMRunning(pScreenInfo)) winAdjustXWindow (pWin, hwnd); winMWExtWMMoveResizeXWindow (pWin, shouldn't that be if (winIsInternalWMRunning(pScreenInfo)) winAdjustXWindow (pWin, hwnd); else winMWExtWMMoveResizeXWindow (pWin, bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Starting X on a second monitor - kludge that works
Hi. I've been trawling the archives looking for a solution to the problem of starting Xwin on a second monitor. The only way I've been able to get this to work is to use a program that allows you to send the app to a 2nd monitor. The program in question is UltraMon. If your second monitor is a different size to your primary, then no fear, just specify the size of the screen when starting x. I've just ported xfce4.2 to cygwin, and start it like this: bash --login -c /opt/xfce4/bin/startxfce4 -- -nodecoration -screen 0 1280 1024 (this I run as a batch file using either the /usr/X11R6/bin/run to hide the window, or a free program I found called runhide) which opens then screen at my 2nd monitor's resolution (but on the primary monitor), then on the task bar, RMB on the app, choose Move to other monitor. For those of you fortunate enough to have a radeon gfx card (my last job used dell's with radeon cards), then the native gfx drivers allow this kind of functionality too. anyone found another method for doing this? I quite like XFCE on my 2nd monitor. Now to port firefox using gtk under cygwin... Mark Fisher
Re: Internal-wm/rootless observations
On Wed, 1 Dec 2004, Torrey Lyons wrote: I have been away on a long Thanksgiving vacation so I've been slow to respond. No problem. I'm hunting this for some weeks already In any case, the 16 bpp modes are problematic but I believe we solved issues with them in the rootless code awhile back. The fundamental problem is that fb assumes screens are always 32-bit aligned. Thus you if a window's pixmap is not 32-bit aligned, fb assumes it can still access the word before the start of a drawable's data. In rootless mode, where windows are located higgledy-piggledy in memory, this is not true. Rootless solves (or attempts to solve) this problem with the SetPixmapBaseToScreen() macro in rootlessCommon.h. The idea is that the unaligned window's pixmap is moved backwards in memory to align it and then a positive offset it given to fb to indicate where the window resides in the pixmap. If there is an edge case where rootless does not work in 16-bits it would be good to track down. This mode is sometimes used on Mac OS X. Maybe the odd window width is the problem. Testcase: xterm width 501 pixel http://www-user.tu-chemnitz.de/~goal/Xming/internalwm.png setting the with to 502 pixel in the debugger solved the distorted drawing. assuming the base was 0x2b0. After the window was translated by (0,5) the pixmap base was moved by 5 * 1002 bytes. In the fb drawing functions the offset was never correct to 0x2b0. It was still below that value and the access an access violation. I had problems with fbCopyNtoN and fbBlt. SetPixmapBaseToScreen does: ptr = 0x2b0 - 5 * 1002 = 0x2afec6e This is unaligned - fixing this ptr = 0x2afec6e - 2 = 0x2afec6c fbCopyNtoN does dst + (pbox-y1 + dstYoff) * dstStride so this is 0x2afec6c + (0 + 5) * 1002 = 0x2ae - unaligned and _off pixmap_ bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Xfce for cygwin
Mark Fisher wrote: I've just ported xfce4.2 to cygwin, and start it like this: Fantastic! Are the patches included in the CVS, are their any particular build instructions? I'm on the xfce dev list but I didn't see anything about this ... David
Re: Xfce for cygwin
David Fraser wrote:
Mark Fisher wrote:
I've just ported xfce4.2 to cygwin, and start it like this:
Fantastic! Are the patches included in the CVS, are their any particular
build instructions?
I'm on the xfce dev list but I didn't see anything about this ...
The patches are in CVS (I was the one who committed them), and there are
specific built instructions.
You need to get libdbh and libstartup-notification yourself, and I'm
using the attached script to build XFCE. Haven't tried this in some time
though due to work load, so I can't guarantee everything still works
out-of-the-box. And oh yeah, you need a very recent version of libtool.
As I just wrote to Mark:
Anyways, you do know that there is a couple of things that do not work
in XFCE for cygwin, right? For one, panel plugins are not fully
functional (just try to change the icon size in the panel and see what
happens). Also, xffm doesn't work, neither is xfprint (I've never really
tried this though), and xfce4-mixer.
The problem with the panel plugins and xffm is that XFCE is coded such
that the plugins must access variables in the loading program, and
MS-Windows (and therefore cygwin) doesn't allow this. I've had some
discussion with Jasper from the XFCE team about this, and we were
thinking of a complete rewrite of the XFCE plugin system. However, this
will have to wait until the 4.2 release, and I'm completely swamped in
work at the moment...
Maarten
#!/bin/bash
cvs_dir=/e/Maarten/src/xfce
log_dir=/e/Maarten/src/xfce/complogs
install_dir=/opt/xfce
# SET REQUIRED PKG_CONFIG DIRECTORIES
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH
PKG_CONFIG_PATH=${cvs_dir}/xfce4/xfce4-panel/panel:$PKG_CONFIG_PATH
PKG_CONFIG_PATH=${cvs_dir}/xfce4/libxfcegui4/libxfcegui4:$PKG_CONFIG_PATH
PKG_CONFIG_PATH=${cvs_dir}/xfce4/libxfce4util/libxfce4util:$PKG_CONFIG_PATH
PKG_CONFIG_PATH=${cvs_dir}/xfce4/libxfce4mcs/libxfce4mcs:$PKG_CONFIG_PATH
PKG_CONFIG_PATH=${cvs_dir}/xfce4/xfce-mcs-manager/xfce-mcs-manager:$PKG_CONFIG_PATH
PKG_CONFIG_PATH=${cvs_dir}/xfce4/xffm/src:$PKG_CONFIG_PATH
PKG_CONFIG_PATH=${cvs_dir}/xfce4/xfce4-session/xfce4-session:$PKG_CONFIG_PATH
export PKG_CONFIG_PATH
export ACLOCAL_FLAGS=--force
usage() {
echo Usage: $0
echo --help or -hdisplay this message
echo --clean remove the old installation
echo --make-cleando a 'make clean'
echo --install do a 'make install'
}
apkg() {
if [ -z $PKGS ]
then
PKGS=$1
else
PKGS=${PKGS} $1
fi
}
apkg xfce4/libxfce4util:--prefix=${install_dir}
apkg xfce4/libxfcegui4:--prefix=${install_dir}
apkg xfce4/libxfce4mcs:--prefix=${install_dir}
apkg xfce4/xfce-mcs-manager:--prefix=${install_dir}
apkg xfce4/xfcalendar:--prefix=${install_dir}
apkg xfce4/xfce4-panel:--prefix=${install_dir}
apkg xfce4/gtk-xfce-engine-2:--prefix=${install_dir}
apkg xfce4/xfce-utils:--prefix=${install_dir}
apkg xfce4/xfwm4:--prefix=${install_dir}
apkg xfce4/xfwm4-themes:--prefix=${install_dir}
apkg xfce4/xfdesktop:--prefix=${install_dir}
apkg xfce4/xfce-mcs-plugins:--prefix=${install_dir}
apkg xfce4/xfce4-appfinder:--prefix=${install_dir}
apkg xfce4/xfce4-session:--prefix=${install_dir}
apkg xfce4/xfce4-icon-theme:--prefix=${install_dir}
apkg xfce4/xfce4-iconbox:--prefix=${install_dir}
apkg xfce4/xfce4-systray:--prefix=${install_dir}
apkg xfce4/xfce4-toys:--prefix=${install_dir}
apkg xfce4/xfce4-trigger-launcher:--prefix=${install_dir}
#apkg xfce4/xffm:--prefix=${install_dir}
#apkg xfce4/xfce4-mixer:--prefix=${install_dir}
#apkg xfce4/xfprint:--prefix=${install_dir}
#apkg xfce4/xfce4-terminal:--prefix=${install_dir}
error=0
clean=0
make_cmd=make
help=0
while [ $# != 0 ]
do
case $1 in
'--help')
help=1
shift
;;
'-h')
help=1
shift
;;
'--clean')
clean=1
shift
;;
'--make-clean')
make_cmd=make clean ${make_cmd}
shift
;;
'--install')
make_cmd=${make_cmd} make install
shift
;;
*)
echo Unknown option: $1
error=1
shift
;;
esac
done
if [ $help -eq 1 ]; then
usage
exit 1
fi
if [ $error -eq 1 ]; then
usage
exit 1
fi
if [ $clean -eq 1 ]; then
echo -n Removing old installation from ${install_dir}...
rm -rf ${install_dir} /dev/null 21
echo Done
fi
rm -rf ${log_dir}/* /dev/null 21
if [ ! -d ${log_dir} ]
then
mkdir ${log_dir}
fi
for i in ${PKGS}
do
pkg=`echo $i | cut -d: -f1`
options=`echo $i | cut -s -d: -f2- | sed -e 's/:/ /'`
log=${log_dir}/`basename ${pkg}`.log
echo Installing \${pkg}\ with \${options}\
cd ${cvs_dir}/$pkg
./autogen.sh ${options} | tee ${log} 21
$SHELL -c ${make_cmd} | tee -a ${log} 21
#$(${make_cmd}) | tee -a ${log} 21
done
src/winsup/cygwin ChangeLog
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2004-12-01 15:07:21 Modified files: winsup/cygwin : ChangeLog Log message: Add missing changelog entry. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.2598r2=1.2599
src/winsup/cygwin ChangeLog include/features.h
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2004-12-01 17:07:03 Modified files: winsup/cygwin : ChangeLog winsup/cygwin/include: features.h Log message: * include/features.h: Include sys/cdefs.h, like linux. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.2599r2=1.2600 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/features.h.diff?cvsroot=srcr1=1.3r2=1.4
src/winsup/w32api ChangeLog lib/directx/strmiids.c
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2004-12-02 05:36:22 Modified files: winsup/w32api : ChangeLog winsup/w32api/lib/directx: strmiids.c Log message: * lib/directx/strmiids.c (MEDIASUBTYPE_YV12): Correct GUID. Thanks to Pete [EMAIL PROTECTED] Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.630r2=1.631 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/lib/directx/strmiids.c.diff?cvsroot=srcr1=1.1r2=1.2
src/winsup/w32api ChangeLog lib/comctl32.def
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2004-12-02 05:55:46 Modified files: winsup/w32api : ChangeLog winsup/w32api/lib: comctl32.def Log message: * lib/comctl32.def (ImageList_Copy, ImageList_DrawIndirect, ImageList_Duplicate): Add stubs. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.631r2=1.632 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/lib/comctl32.def.diff?cvsroot=srcr1=1.4r2=1.5
change log fix: [Patch] bug # 514 (cygwin console handling)
Sorry, I missed to insert the function name in the change log
entry, so here it is again as an update; the patch is the same.
This is a small patch that fixes
http://sourceware.org/bugzilla/show_bug.cgi?id=514
Please integrate it into the cygwin DLL.
2004-11-26 Thomas Wolff [EMAIL PROTECTED]
* fhandler_console.cc (get_win32_attr): Avoid inappropriate intensity
interchanging that used to render reverse output unreadable
when (non-reversed) text is bright.
See http://sourceware.org/bugzilla/show_bug.cgi?id=514
There are two useful alternatives to handle this; both are in
the patch (#ifdef reverse_bright) and one is selected by #define:
a) (selected) bright foreground will reverse to a bright background,
b) bright foreground will reverse to a dim background but
the background will no longer reverse to a bright foreground
(which used to render reverse output unreadable).
--- cygwin-1.5.12-1/winsup/cygwin/fhandler_console.cc 2004-10-28
17:33:04.0 +0200
+++ cygwin-1.5.12-1/winsup/cygwin/fhandler_console.cc.fix5142004-11-30
12:44:03.499523500 +0100
@@ -921,14 +921,32 @@ fhandler_console::get_win32_attr ()
if (dev_state-reverse)
{
WORD save_fg = win_fg;
+#define reverse_bright
+#ifdef reverse_bright
+ /* This way, a bright foreground will reverse to a bright background.
+ */
win_fg = (win_bg BACKGROUND_RED ? FOREGROUND_RED : 0) |
(win_bg BACKGROUND_GREEN ? FOREGROUND_GREEN : 0) |
(win_bg BACKGROUND_BLUE ? FOREGROUND_BLUE : 0) |
- (win_fg FOREGROUND_INTENSITY);
+ (win_bg BACKGROUND_INTENSITY ? FOREGROUND_INTENSITY : 0);
win_bg = (save_fg FOREGROUND_RED ? BACKGROUND_RED : 0) |
(save_fg FOREGROUND_GREEN ? BACKGROUND_GREEN : 0) |
(save_fg FOREGROUND_BLUE ? BACKGROUND_BLUE : 0) |
- (win_bg BACKGROUND_INTENSITY);
+ (save_fg FOREGROUND_INTENSITY ? BACKGROUND_INTENSITY : 0);
+#else
+ /* This way, a bright foreground will reverse to a dim background.
+ But the background will no longer reverse to a bright foreground
+ (which used to render reverse output unreadable).
+ */
+ win_fg = (win_bg BACKGROUND_RED ? FOREGROUND_RED : 0) |
+ (win_bg BACKGROUND_GREEN ? FOREGROUND_GREEN : 0) |
+ (win_bg BACKGROUND_BLUE ? FOREGROUND_BLUE : 0) |
+ (win_bg FOREGROUND_INTENSITY);
+ win_bg = (save_fg FOREGROUND_RED ? BACKGROUND_RED : 0) |
+ (save_fg FOREGROUND_GREEN ? BACKGROUND_GREEN : 0) |
+ (save_fg FOREGROUND_BLUE ? BACKGROUND_BLUE : 0) |
+ (save_fg BACKGROUND_INTENSITY);
+#endif
}
if (dev_state-underline)
win_fg = dev_state-underline_color;
truncate() improperly returns EBADF
When using truncate(), EBADF is sometimes improperly returned. susv3
doesn't list this as a possible errno value for this function. In
particular, ENOENT should be returned when when path doesn't exist and
EACCES when write permission is denied.
truncate.c:
#include unistd.h
#include stdio.h
#include stdlib.h
#include errno.h
int main(int argc, char **argv) {
off_t size;
char *endptr = argv[2];
if (argc != 3) {
fprintf(stderr, usage: truncate path size\n);
exit(1);
}
errno = 0;
size = strtoull(argv[2], endptr, 10);
if (!endptr || endptr == argv[2] || *endptr || size 0 ||
(size == 0 errno)) {
fprintf(stderr, truncate: invalid size\n);
exit(1);
}
printf(truncating %s to %lld bytes\n, argv[1], size);
if (truncate(argv[1], size)) {
int saveerr = errno;
perror(truncate);
fprintf(stderr, errno was %d\n, saveerr);
exit(1);
}
exit(0);
}
==
$ rm foo
$ ./truncate foo 0
truncating foo to 0 bytes
truncate: Bad file descriptor
errno was 9
$ touch foo
$ chmod u-w foo
$ ls -l foo
-r--r--r--1 sthoenna None0 Dec 1 00:06 foo
$ ./truncate foo 0
truncating foo to 0 bytes
truncate: Bad file descriptor
errno was 9
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Patch to /etc/profile to deal with $HOME with a space
On Tue, Nov 30, 2004 at 07:33:02PM -, John Morrison wrote: I have just set up Cygwin, and noticed that my default home was under my Documents and Settings directory (not yet having run mkpasswd). However, the /etc/profile setup which tries to only create the warning message about running mkpasswd and mkgroup once can't deal with a HOME environment variable with a space in it. Here is a patch to allow that to work: Thanks, I'm away on a course at the moment and don't have access to the machine with the files I use to generate the package. I'll be back home on Friday, I'll try and get something out over the weekend or by mid-week at the latest. Since this has been a persistent problem, pretty much since the inception of base-files, can I request that you do an audit of everything in base files and quote all unquoted access to environment variables in the package? It seems like we just keep running across these problems in bits and pieces and maybe it's time for a concerted effort to wipe these types of problems out. OK. I did consider changing /etc/postinstall/passwd-grp.sh so that instead of running /bin/mkpasswd -l -c /etc/passwd it does mkpasswd.exe -l -c | sed 's/cygdrive\/.*Documents and Settings/home/' /etc/passwd The reason the 'Doc and Settings' directory is appearing is because these people are networked based and the flags to mkpasswd tell it to only check the local machine. It was talked about passing in the domain flag, but ruled out because of the amount of time it would take if there were lots of users or it was unable to contact a default domain (there may have been other issues too, but they were the only ones I can remember). Think it's worth it? Anyway, I'll fix the profile quotes soonest. J. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Patch to /etc/profile to deal with $HOME with a space
Hi John, John Morrison wrote on Wednesday, December 01, 2004 10:08 AM: [snip] I did consider changing /etc/postinstall/passwd-grp.sh so that instead of running /bin/mkpasswd -l -c /etc/passwd it does mkpasswd.exe -l -c | sed 's/cygdrive\/.*Documents and Settings/home/' /etc/passwd This is nonsense. Documents and Settings is localized. [snip] - Jörg -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
strange problems with cvs
Hi, I use CVS with cygwin a long time ago, but after a recent updte it stoped working. I'm using pserver auth and the cygwin is installed with *DOS* line-endings. When I try to do something with cvs -1.11.17- (cvs up, cvs diff, etc..) it simply returns: : no such repository Normally if I close cygwin, run the setup again (without installing anything) and opening cygwin again fixes the problem. If I do a fresh checkout, it will checkout the files with *unix* file-endings, which isn't what I asked for.. Does anyone knows whats the problem here? I think it might be cause of the release of the lastest dll version. (I update cygwin often..) Thanks, Nuno Lopes -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Patch to /etc/profile to deal with $HOME with a space
Hi John, Hi :) John Morrison wrote on Wednesday, December 01, 2004 10:08 AM: I did consider changing /etc/postinstall/passwd-grp.sh so that instead of running /bin/mkpasswd -l -c /etc/passwd it does mkpasswd.exe -l -c | sed 's/cygdrive\/.*Documents and Settings/home/' /etc/passwd This is nonsense. Documents and Settings is localized. Humm, not nonsense (it works for English), maybe not correct... (is this retrievable for replacement?) Anyway, the idea (if not the impl) stands, when a network user installs cygwin HOME is set to doc settings. When a local user installs HOME is set to /home/user. So, should network user functionality be changed? (assuming it's possible to get the localisation) J. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Patch to /etc/profile to deal with $HOME with a space
Hi John, John Morrison wrote on Wednesday, December 01, 2004 12:32 PM: mkpasswd.exe -l -c | sed 's/cygdrive\/.*Documents and Settings/home/' /etc/passwd This is nonsense. Documents and Settings is localized. Humm, not nonsense (it works for English), maybe not correct... (is this retrievable for replacement?) May also not work for English, cygdrive is just a default value and is settable. In case of my system: $ mount -p Prefix Type Flags /mntsystem binmode You may *assume* it is called cygdrive for a new installation, but if there are registry entries left from an old one ... Anyway, the idea (if not the impl) stands, when a network user installs cygwin HOME is set to doc settings. When a local user installs HOME is set to /home/user. So, should network user functionality be changed? (assuming it's possible to get the localisation) $ cygpath -H Personally I use a mount for home: $ mount ... C:\Dokumente und Einstellungen on /home type system (binmode) ... But this is *my* preference only (and applies not for Win95, Win 98, Win NT etc. anyway). Additionally in the pattern /home/user may not apply for newer Win OSses also, since the user's profile directory may not have the name of the user and unfortunately this information cannot be retrieved from cygpath, you may read directly from the registry. - Jörg -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Patch to /etc/profile to deal with $HOME with a space
Hi John, John Morrison wrote on Wednesday, December 01, 2004 12:32 PM: mkpasswd.exe -l -c | sed 's/cygdrive\/.*Documents and Settings/home/' /etc/passwd This is nonsense. Documents and Settings is localized. Humm, not nonsense (it works for English), maybe not correct... (is this retrievable for replacement?) May also not work for English, cygdrive is just a default value and is settable. In case of my system: $ mount -p Prefix Type Flags /mntsystem binmode You may *assume* it is called cygdrive for a new installation, but if there are registry entries left from an old one ... Anyway, the idea (if not the impl) stands, when a network user installs cygwin HOME is set to doc settings. When a local user installs HOME is set to /home/user. So, should network user functionality be changed? (assuming it's possible to get the localisation) $ cygpath -H Personally I use a mount for home: $ mount ... C:\Dokumente und Einstellungen on /home type system (binmode) ... But this is *my* preference only (and applies not for Win95, Win 98, Win NT etc. anyway). Additionally in the pattern /home/user may not apply for newer Win OSses also, since the user's profile directory may not have the name of the user and unfortunately this information cannot be retrieved from cygpath, you may read directly from the registry. Humm, OK - scratch that idea :) J. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: strange problems with cvs
Nuno Lopes kirjoitti: Hi, I use CVS with cygwin a long time ago, but after a recent updte it stoped working. I'm using pserver auth and the cygwin is installed with *DOS* line-endings. When I try to do something with cvs -1.11.17- (cvs up, cvs diff, etc..) it simply returns: : no such repository Normally if I close cygwin, run the setup again (without installing anything) and opening cygwin again fixes the problem. If I do a fresh checkout, it will checkout the files with *unix* file-endings, which isn't what I asked for.. Does anyone knows whats the problem here? I think it might be cause of the release of the lastest dll version. (I update cygwin often..) Seems like you have encountered fancy EOL problem. To be safe use unix line-endings since CVS is pretty picky about those. And of course if you want to use DOS type line endings, use real win32 version of CVS. I've encountered numerous problems with CVS due the line-endings... Any decent text editor should be handle both CR+LF or LF/CR only line-endings and preserving existing ones... If yours doesn't it's time to upgrade... (Of course there might be problem in bin/textmode mounts) cygcheck output would do good here... -- Jani Tiainen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: httpd-2.0.52 (Apache2) testers wanted / maintainer searched
Sorry for comiing in late, I'm currently out of office. Jon A. Lambert wrote: Gerrit P. Haase wrote: Hi, I just wanted to know if it is possible and if it is running and the answer is: *yes*. I have Apache2 compiled with a shared core and shared modules, I offer a full patch and script so you can do the same with just running the buildscript against the patched sources. I figured out how to run the patch file. Whee! $ cd httpd* /oem-install/httpd-2.0.52 $ patch -p1 -i ../httpd-2.0.52-1.patch patching file CYGWIN-PATCHES/README ellided patching file srclib/apr/configure.in Looks good. --- But now how do I run this build-script and from where? Or should I be running ./configure at this point. In the source package are three files, the original source, the paptchfile and the script, after extracting the source run: $ ./httpd-2.0.52-1.sh prep This extracts the source and aplies the patch $ ./httpd-2.0.52-1.sh conf $ ./httpd-2.0.52-1.sh build $ ./httpd-2.0.52-1.sh install ... See the bottom of the script, there is an option 'all' which runs all needed script targets, there are some more eg. 'strip'. It should work to run $ ./httpd-2.0.52-1.sh all which will create a new binary tarball and a new source tarball. The README indicates you can't build loadable shared objects? My intention is to use Subversion via mod_svn_dav and Eruby via mod_ruby Does that mean I will have compile the above first into the modules and then make ./configure link them in the executable? Does anyone have additional notes, advice or information on Apache2? There is also a script included in my patch which creates the loadable shared modules. What I have not fixed is the Apache script which is used to build third party extension modules. It should be sufficient to build the modules as static archives, then take a look at the script in the modules directory of the apache source how to create a shared library/module from the static archives. After the module DLL is created, copy it to the modules path and add it in httpd.conf. However, I saw problems with loading websites greater than 8k. Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc-g77 4.4.1-1 stack memory error
Ata Bilgili wrote: G'day; I have a Fortran 77 code involving the finite element solution of rather large matrices using a conjugate gradient method. The code trustfully runs with g77 on Linux and Unix with no problems. When I tried running it this morning using the Cygwin gcc-g77 3.3.3-3, it complied nicely but I got a runtime error of MapViewOfFileEx failed, Win32. I then installed gcc-g77 3.4.1-1 and the same thing happened but with rather different error messages: First I got a *.exe.stackdump file (attached) and then received a Segmentation Error. An internet search yields -Wl --stack= options for gcc. Is there any workaround for g77? This is rather frustrating, knowing that I have to find a way to get this to work under Cygwin. I believe this is a Windows problem rather than Cygwin but!!! Cygcheck output is also attached. -Wl,--stack= This is needed on Cygwin if your stack will grow beyond 2MB because the stack size cannot be modified dynamically. Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: httpd-2.0.52 (Apache2) testers wanted / maintainer searched
-Original Message- From: cygwin-owner On Behalf Of Gerrit P. Haase Sent: 01 December 2004 13:59 /oem-install/httpd-2.0.52 $ patch -p1 -i ../httpd-2.0.52-1.patch patching file CYGWIN-PATCHES/README ellided patching file srclib/apr/configure.in Looks good. --- But now how do I run this build-script and from where? Or should I be running ./configure at this point. In the source package are three files, the original source, the paptchfile and the script, after extracting the source run: $ ./httpd-2.0.52-1.sh prep This extracts the source and aplies the patch $ ./httpd-2.0.52-1.sh conf $ ./httpd-2.0.52-1.sh build $ ./httpd-2.0.52-1.sh install ... See the bottom of the script, there is an option 'all' which runs all needed script targets, there are some more eg. 'strip'. It should work to run $ ./httpd-2.0.52-1.sh all which will create a new binary tarball and a new source tarball. If this script has patched configure.in, won't the whole thing need regenerating with the auto-* toolset? Or does the script take care of that too? cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: truncate() improperly returns EBADF
On Wed, Dec 01, 2004 at 12:48:41AM -0800, Yitzchak Scott-Thoennes wrote: When using truncate(), EBADF is sometimes improperly returned. susv3 doesn't list this as a possible errno value for this function. In particular, ENOENT should be returned when when path doesn't exist and EACCES when write permission is denied. Thanks for the test case. I've checked in a fix which should rectify this behavior. It will be in the next snapshot. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin build of perl5.8.5 (cygwin-thread-multi-64int)
My environment shows USERNAME different from USER, possibly the reason of
the failing installation.
I start cygwin with HOME and USERNAME containing white space, changing it to
HOME without, thus complying with script requirements? I have in vain under
this condition reinstalled perl using the Cygwin Net Release Setup Program
version 2.427.
On my deposit of postings to the group '[EMAIL PROTECTED]'
I havent seen any clue to my problem with cygwin-thread-multi-64int.
Can anyone explain the outcome of running what follows on an XP, SP2?
Quote
10:05:05 ~ cygcheck -s -v -r cygcheck.txt
10:06:24 ~ perldoc -v perldoc
Ending switch processing. Args are [perldoc] with 0 errors.
/usr/bin/perldoc = Pod::Perldoc v3.13
Formatter class Pod::Perldoc::ToMan successfully loaded!
Will format with the class Pod::Perldoc::ToMan
Searching for perldoc
Looking for perldoc in /usr/bin
/usr/lib/perl5/5.8.5/cygwin-thread-multi-64int /usr/lib/perl5/5.8.5
/usr/lib/perl5/site_perl/5.8.5/cygwin-thread-multi-64int
/usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.5/cygwin-thread-multi-64int
/usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl . /usr/local/bin
/usr/bin /bin /usr/X11R6/bin /cygdrive/c/Program/Borland/Delphi7/Bin
/cygdrive/c/Program/Borland/Delphi7/Projects/Bpl/
/cygdrive/c/WINDOWS/system32 /cygdrive/c/WINDOWS
/cygdrive/c/WINDOWS/system32/wbem /cygdrive/c/ATI-CPanel
/cygdrive/c/Perl/bin/ /cygdrive/c/Program/Microsoft SDK/Bin/
/cygdrive/c/Program/Microsoft SDK/Bin/WinNT/ /usr/bin .
/cygdrive/c/j2sdk1.4.2_04/bin/ /cygdrive/c/ant/bin/ /usr/sbin
Found as /usr/lib/perl5/5.8.5/pods/perldoc.pod
C:\cygwin\bin\perl.exe (4076): *** couldn't release memory 0xA04000(1032192)
for 'C:\cygwin\lib\perl5\5.8.5\cygwin-thread-multi-6
4int\auto\Fcntl\Fcntl.dll' alignment, Win32 error 487
4 [main] perl 3944 sync_with_child: child 4076(0x6A4) died before
initialization with status code 0x1
242 [main] perl 3944 sync_with_child: *** child state child loading dlls
12:17:13 ~
Unquote
An interesting observation is the correct result in
09:34:26 ~ perl -e 'sub intRand { return 3; } my @a=qw( a b c d e f );
print qq($a[intRand(45)]\n);'
d
Tom Axehult, Stockholm
A comment on error 487: Attempt to access invalid address.
Cygwin Configuration Diagnostics
Current System Time: Wed Dec 01 10:06:20 2004
Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 2
Path: C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\Program\Borland\Delphi7\Bin
c:\Program\Borland\Delphi7\Projects\Bpl\
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\system32\wbem
c:\ATI-CPanel
c:\Perl\bin\
c:\Program\Microsoft SDK\Bin\
c:\Program\Microsoft SDK\Bin\WinNT\
C:\cygwin\bin
.\
c:\j2sdk1.4.2_04\bin\
c:\ant\bin\
C:\cygwin\usr\sbin
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1005(Tom Axehult) GID: 513(Ingen)
513(Ingen)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1005(Tom Axehult) GID: 513(Ingen)
0(root)513(Ingen) 544(Administratörer)
545(Användare)
SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS
HOME = `C:\cygwin\home\Tom'
MAKE_MODE = `unix'
PWD = `/home/Tom'
USER = `Tom'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
ANT_HOME = `c:\ant'
APPDATA = `C:\Documents and Settings\Tom Axehult\Application Data'
BASEMAKE = `C:\Program\Microsoft SDK\include\BKOffice.Mak'
BKOFFICE = `C:\Program\Microsoft SDK\.'
CLIENTNAME = `Console'
COMMONPROGRAMFILES = `C:\Program\Delade filer'
COMPUTERNAME = `AXEHULT-FUJITSU'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
CVS_RSH = `/bin/ssh'
FP_NO_HOST_CHECK = `NO'
HISTCONTROL = `ignoredups'
HISTSIZE = `64'
HOMEDRIVE = `C:'
HOMEPATH = `\Documents and Settings\Tom Axehult'
HOSTNAME = `Axehult-Fujitsu'
INCLUDE = `c:\cygwin\usr\include\.;C:\Program\Microsoft
SDK\include\.;C:\Program\Microsoft SDK\include\Win64\.;C:\Program\Microsoft
SDK\include\Win64\crt\.;C:\Program\Microsoft
SDK\include\Win64\atl\.;C:\Program\Microsoft SDK\include\Win64\mfc\.'
INETSDK = `C:\Program\Microsoft SDK\.'
INFOPATH =
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
INPUTRC = `/home/Tom/.inputrc'
JAVA_HOME = `c:\j2sdk1.4.2_04'
JAVA_VERSION = `1.4.2'
LIB = `C:\Program\Microsoft SDK\Lib\.;'
LOGONSERVER = `\\AXEHULT-FUJITSU'
MANPATH =
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man'
MSDEV = `C:\Program\DevStudio'
MSDEVDIR = `C:\Program\DevStudio\SharedIDE'
MSSDK = `C:\Program\Microsoft SDK'
MSTOOLS = `C:\Program\Microsoft SDK\.'
NUMBER_OF_PROCESSORS = `2'
OLDPWD = `/home/Tom Axehult'
OS = `Windows_NT'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.pl'
PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 3 Stepping 3, GenuineIntel'
Compile within cygwin with -mnocygwin
Hello I am trying to compile a perl swig1.3 wrapper for a C++ lib using cygwin but with the compiler define -mno-cygwin. In perl.h there are lots of includes that cannot be found. Should I put some special define in the Makefile to use another Path for includes? Thanks, Mattias Output: c++ -DHAVE_CONFIG_H -I. -I. -I../config -I../include -I/c/Python22/include -I/us r/lib/perl5/5.8.5/cygwin-thread-multi-64int/CORE -g -O2 -DWINSOCK_2 -mno-cygwin -DSWIG_GLOBAL_MAPPING -D_HOST_LITTLE_ENDIAN -D_BK_LIBRARY=\/usr/local/lib/vh/li bvhcore.so\ -L//c/SWIG-1.3.19/Lib -lswigpl -Wp,-MD,.deps/vhcore_wrap.pp -c vhco re_wrap.cpp -DDLL_EXPORT -DPIC In file included from vhcore_wrap.cpp:251: /usr/lib/perl5/5.8.5/cygwin-thread-multi-64int/CORE/perl.h:637:27: netinet/in.h: No such file or directory /usr/lib/perl5/5.8.5/cygwin-thread-multi-64int/CORE/perl.h:641:26: arpa/inet.h: No such file or directory /usr/lib/perl5/5.8.5/cygwin-thread-multi-64int/CORE/perl.h:687:27: sys/times.h: No such file or directory /usr/lib/perl5/5.8.5/cygwin-thread-multi-64int/CORE/perl.h:838:30: sys/ioctl.h: No such file or directory /usr/lib/perl5/5.8.5/cygwin-thread-multi-64int/CORE/perl.h:1274:23: ieeefp.h: No such file or directory /usr/lib/perl5/5.8.5/cygwin-thread-multi-64int/CORE/perl.h:2056:31: win32thread. h: No such file or directory /usr/lib/perl5/5.8.5/cygwin-thread-multi-64int/CORE/perl.h:2086:21: win32.h: No such file or directory In file included from /usr/lib/perl5/5.8.5/cygwin-thread-multi-64int/CORE/perl.h :2350, from vhcore_wrap.cpp:251: -- Mattias Barthel, Software Engineer CapGemini at Hewlett Packard Spain Tel. 34 93 582 26 02 E-mail: [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: FDISK support
According to this post: http://sources.redhat.com/ml/cygwin/2002-11/msg01300.html , you can now use fdisk. Can someone please tell me how to get fdisk onto cygwin? I couldn't find the package with the cygwin setup file. Thanks everyone. There is no package available under setup because I didn't want to deal with people misusing fdisk and wiping their hard disk. You can compile fdisk yourself from sources (a few minor changes required). Chris -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compile within cygwin with -mnocygwin
On Wed, Dec 01, 2004 at 04:23:55PM +0100, BARTHEL, MATTIAS wrote: Hello I am trying to compile a perl swig1.3 wrapper for a C++ lib using cygwin but with the compiler define -mno-cygwin. In perl.h there are lots of includes that cannot be found. Right. You have just discovered the difference between no cygwin and cygwin. Cygwin provides a unix-like environment for windows. No cygwin provides a windows-like environment for windows with a few minor, cheap unixisms thrown in. netinet/in.h, sys/ioctl.h, etc., are not minor or cheap so they are not part of no cygwin. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: httpd-2.0.52 (Apache2) testers wanted / maintainer searched
Dave Korn wrote: -Original Message- From: cygwin-owner On Behalf Of Gerrit P. Haase Sent: 01 December 2004 13:59 See the bottom of the script, there is an option 'all' which runs all needed script targets, there are some more eg. 'strip'. It should work to run $ ./httpd-2.0.52-1.sh all which will create a new binary tarball and a new source tarball. If this script has patched configure.in, won't the whole thing need regenerating with the auto-* toolset? Or does the script take care of that too? The included patch is created after building the whole package manually, so there are two possibilities: - it includes all changes - it includes all changes They use no automake, so actually there are updates to libtool related files and updates in Makefile.in. If there are changes to configure.in then the resulting changes to configure should also be included in the patch. The changes in Makefile.in and the other Makefile templates are handcrafted, this is also the reason why I am not interested to maintain this as a package. Besides this there seems to be a problem with the binary, one can download only 8k at once which is annoying when you want to get something greater than this. I couldn't figure out what the problem is, it works great when connecting Apache2 local, it fails when it is connected via network. Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compile within cygwin with -mnocygwin
BARTHEL, MATTIAS wrote: Hello I am trying to compile a perl swig1.3 wrapper for a C++ lib using cygwin but with the compiler define -mno-cygwin. In perl.h there are lots of includes that cannot be found. Yes, Cygwin Perl is compiled without this flag and so WIN32 is not defined for Cygwin Perl. Should I put some special define in the Makefile to use another Path for includes? You will need to use a MinGW compiled Perl. I saw some links to mingw-perl at the MinGW website recently where you should look to get it. Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Compiling a DLL
Hello. What are the procedures for compiling a DLL without using the Cygwin DLL? /Mattias -- Mattias Barthel, Software Engineer CapGemini at Hewlett Packard Tel. 34 93 582 26 02 E-mail: [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Problem with cygwin xerces-2.6
Hi: I'm developing a c++ application which uses xerces-c2.6 It works just fine on the Linux Platform, but when I try to make the binary file under cygwin I get some errors regarding the linking of the xerces library. I've compiled the sources for the xerces lib following the instructions on the website and all of the examples compile run fine. Here's the Makefile I'm using: CC=g++ LIB_PATH=/home/mchojrin/xerces-c-src_2_6_0/Lib LIB_NAME=xerces-c BIN_NAME=main all: soapC.o soapClient.o stdsoap2.o xmlconfig.o extraconfig.o actionexecutor.o agentconfig.o action.o agent.o module.o serversock.o dbfile.o parameter.o command.o actionresult.o serverinterface.o main.o $(CC) -D__CYGWIN__ -o$(BIN_NAME) -L$(LIB_PATH) -L/usr/lib -l$(LIB_NAME) xmlconfig.o extraconfig.o actionexecutor.o agentconfig.o action.o agent.o module.o serversock.o dbfile.o parameter.o command.o serverinterface.o actionresult.o soapC.o soapClient.o stdsoap2.o main.o .cpp.o: $(CC) -w -O -DAPP_NO_THREADS -DXML_USE_NO_THREADS -c -D__CYGWIN__ -I. -I/include $ clean: rm *.o Can anybody tell me what I'm doing wrong? Thanks! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compiling a DLL
BARTHEL, MATTIAS wrote: What are the procedures for compiling a DLL without using the Cygwin DLL? http://cygwin.com/faq/faq.html#SEC94 In short: if you want to use Cygwin's posix emulation layer then you will be linking to cygwin1.dll and your program will be GPL[1]. There's no way to statically compile an app that still uses the emulation layer but doesn't depend on the DLL. You can compile a mingw app of course with the -mno-cygwin switch, but the amount of unix-like functionalty that's supported is very much a subset of what you get with Cygwin. If this is what you want then you need to ask your question on the mingw list. Brian [1] Unless you pay Redhat for their commercial license. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compiling a DLL
Brian Dessent wrote: will be linking to cygwin1.dll and your program will be GPL[1]. There's Sorry, I keep forgetting that Redhat offers the ..or any OSI-approved license addendum to the GPL, so your code doesn't necessarily have to be GPL, but it still must be Open Source. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin build of perl5.8.5 (cygwin-thread-multi-64int)
Tom Axehult wrote: Can anyone explain the outcome of running what follows on an XP, SP2? [...] 10:06:24 ~ perldoc -v perldoc [...] C:\cygwin\bin\perl.exe (4076): *** couldn't release memory 0xA04000(1032192) for 'C:\cygwin\lib\perl5\5.8.5\cygwin-thread-multi-6 4int\auto\Fcntl\Fcntl.dll' alignment, Win32 error 487 4 [main] perl 3944 sync_with_child: child 4076(0x6A4) died before initialization with status code 0x1 242 [main] perl 3944 sync_with_child: *** child state child loading dlls No sorry, I cannot explain this. It works here with my XP/SP2 so it is not a generic problem. I'm seeing that perl writes a file to /tmp instead this error. Maybe perl doesn't like your TMP drive: TEMP = `C:\DOCUME~1\TOMAXE~1\LOKALA~1\Temp' TMP = `C:\DOCUME~1\TOMAXE~1\LOKALA~1\Temp' Create /tmp and set TMP TEMP to /tmp. HTH, Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: dead links
On Tue, Nov 30, 2004 at 09:06:04PM -0800, Louise Elsea wrote: All the links in the directory below except the Parent come up as not found. Or am I just clueless? http://www.cygwin.com/packages/gcc-g++/ All of the links work fine. The files in that directory haven't changed since August at the latest. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Problem with cygwin xerces-2.6
-Original Message- From: cygwin-owner On Behalf Of mchojrin Sent: 01 December 2004 17:31 I'm developing a c++ application which uses xerces-c2.6 It works just fine on the Linux Platform, but when I try to make the binary file under cygwin I get some errors regarding the linking of the xerces library. I've compiled the sources for the xerces lib following the instructions on the website and all of the examples compile run fine. Here's the Makefile I'm using: CC=g++ LIB_PATH=/home/mchojrin/xerces-c-src_2_6_0/Lib LIB_NAME=xerces-c BIN_NAME=main all: soapC.o soapClient.o stdsoap2.o xmlconfig.o extraconfig.o actionexecutor.o agentconfig.o action.o agent.o module.o serversock.o dbfile.o parameter.o command.o actionresult.o serverinterface.o main.o $(CC) -D__CYGWIN__ -o$(BIN_NAME) -L$(LIB_PATH) -L/usr/lib -l$(LIB_NAME) xmlconfig.o extraconfig.o actionexecutor.o agentconfig.o action.o agent.o module.o serversock.o dbfile.o parameter.o command.o serverinterface.o actionresult.o soapC.o soapClient.o stdsoap2.o main.o .cpp.o: $(CC) -w -O -DAPP_NO_THREADS -DXML_USE_NO_THREADS -c -D__CYGWIN__ -I. -I/include $ clean: rm *.o Can anybody tell me what I'm doing wrong? Thanks! Not telling us anything about what the actual error that occurs is, for starters. However my guess is that you really want to have the -l$(LIB_NAME) option at the very end of the link command line. Libraries need to be specified _after_ all the .o files that reference them; that's a limitation of ld. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: A vexing installation problem
Drat... Windows Update decided to install a critical security fix last night, and today, Cygwin appears to be 100% dead in the water as opposed to yesterday's 90%. The security fix is supposed to be in Internet Explorer so it might just be a coincidence. I've attached strace output from running ls. The output is slightly different from previous attempts, because I'd been able to run the postinstall scripts to populate /etc/passwd and /etc/group; but the failure mode appears unchanged, with death following shortly after signals are enabled. The trace is still slightly variable from one run to the next; sometimes I get one or two messages about locks, sometimes not. By the way, this is a dual Xeon workstation, without hyperthreading. -- Dave ** Program name: C:\local\cygwin\bin\ls.exe (1336) App version: 1005.0, api: 0.88 DLL version: 1005.12, api: 0.116 DLL build:2004-11-10 08:34 OS version: Windows NT-5.1 Heap size:402653184 Date/Time:2004-12-01 10:27:38 ** 2001735 [main] ls 1336 set_myself: myself-dwProcessId 0 11542889 [main] ls 1336 environ_init: 0x10010250: !C:=C:\local\cygwin\bin 3253214 [main] ls 1336 environ_init: 0x10010008: !EXITCODE= 3293543 [main] ls 1336 environ_init: 0x10010270: !H:=H:\ 3343877 [main] ls 1336 parse_options: tty 1001 3444221 [main] ls 1336 parse_options: returning 1904411 [main] ls 1336 environ_init: 0x10010280: CYGWIN=tty 3674778 [main] ls 1336 pinfo_init: pid 1336, pgid 1336 2535031 [main] ls 1336 dtable::extend: size 32, fds 0x61790C24 1905221 [main] ls 1336 normalize_posix_path: src /etc/passwd 1395360 [main] ls 1336 normalize_posix_path: /etc/passwd = normalize_posix_path (/etc/passwd) 1485508 [main] ls 1336 mount_info::conv_to_win32_path: conv_to_win32_path (/etc/passwd) 1585666 [main] ls 1336 set_flags: flags: binary (0x2) 1525818 [main] ls 1336 mount_info::conv_to_win32_path: src_path /etc/passwd, dst C:\local\cygwin\etc\passwd, flags 0xA, rc 0 3256143 [main] ls 1336 symlink_info::check: not a symlink 1646307 [main] ls 1336 symlink_info::check: 0 = symlink.check (C:\local\cygwin\etc\passwd, 0x22E8D8) (0xA) 3726679 [main] ls 1336 path_conv::check: this-path(C:\local\cygwin\etc\passwd), has_acls(1) 4317110 [main] ls 1336 etc::test_file_change: FindFirstFile succeeded 1607270 [main] ls 1336 etc::test_file_change: fn[1] C:\local\cygwin\etc\passwd res 1 1457415 [main] ls 1336 etc::init: fn[1] C:\local\cygwin\etc\passwd, curr_ix 1 1377552 [main] ls 1336 pwdgrp::load: /etc/passwd 4502 12054 [main] ls 1336 pwdgrp::load: /etc/passwd curr_lines 214 160 12214 [main] ls 1336 pwdgrp::load: /etc/passwd load succeeded 179 12393 [main] ls 1336 normalize_posix_path: src /etc/group 141 12534 [main] ls 1336 normalize_posix_path: /etc/group = normalize_posix_path (/etc/group) 142 12676 [main] ls 1336 mount_info::conv_to_win32_path: conv_to_win32_path (/etc/group) 159 12835 [main] ls 1336 set_flags: flags: binary (0x2) 141 12976 [main] ls 1336 mount_info::conv_to_win32_path: src_path /etc/group, dst C:\local\cygwin\etc\group, flags 0xA, rc 0 345 13321 [main] ls 1336 symlink_info::check: not a symlink 148 13469 [main] ls 1336 symlink_info::check: 0 = symlink.check (C:\local\cygwin\etc\group, 0x22E898) (0xA) 146 13615 [main] ls 1336 path_conv::check: this-path(C:\local\cygwin\etc\group), has_acls(1) 415 14030 [main] ls 1336 etc::test_file_change: FindFirstFile succeeded 155 14185 [main] ls 1336 etc::test_file_change: fn[2] C:\local\cygwin\etc\group res 1 141 14326 [main] ls 1336 etc::init: fn[2] C:\local\cygwin\etc\group, curr_ix 2 140 14466 [main] ls 1336 pwdgrp::load: /etc/group 1867 16333 [main] ls 1336 pwdgrp::load: /etc/group curr_lines 66 141 16474 [main] ls 1336 pwdgrp::load: /etc/group load succeeded 173 16647 [main] ls 1336 cygheap_user::ontherange: what 2, pw 0x10018380 155 16802 [main] ls 1336 cygheap_user::ontherange: Set HOME (from /etc/passwd) to //duckling/dhinds 662 17464 [main] ls 1336 normalize_posix_path: src //duckling/dhinds 139 17603 [main] ls 1336 normalize_posix_path: //duckling/dhinds = normalize_posix_path (//duckling/dhinds) 148 17751 [main] ls 1336 mount_info::conv_to_win32_path: conv_to_win32_path (//duckling/dhinds) 151 17902 [main] ls 1336 mount_info::conv_to_win32_path: src_path //duckling/dhinds, dst \\duckling\dhinds, flags 0x0, rc 0 866 18768 [main] ls 1336 symlink_info::check: not a symlink 209 18977 [main] ls 1336 symlink_info::check: 0 = symlink.check (\\duckling\dhinds, 0x22E0E8) (0x0) 1579 20556 [main] ls 1336 path_conv::check: this-path(\\duckling\dhinds), has_acls(0) 354 20910 [main] ls 1336 win_env::add_cache: posix //duckling/dhinds 165 21075 [main] ls 1336 win_env::add_cache: native
Re: A vexing installation problem
On Wed, Dec 01, 2004 at 10:44:34AM -0800, David Hinds wrote: Drat... Windows Update decided to install a critical security fix last night, and today, Cygwin appears to be 100% dead in the water as opposed to yesterday's 90%. The security fix is supposed to be in Internet Explorer so it might just be a coincidence. I think it was just a coincidence. The rate of success does seem lower now, but I can't do an objective comparison. -- Dave -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: A vexing installation problem
David Hinds schrieb: Drat... Windows Update decided to install a critical security fix last night, and today, Cygwin appears to be 100% dead in the water as opposed to yesterday's 90%. The security fix is supposed to be in Internet Explorer so it might just be a coincidence. I've attached strace output from running ls. The output is slightly different from previous attempts, because I'd been able to run the postinstall scripts to populate /etc/passwd and /etc/group; but the failure mode appears unchanged, with death following shortly after signals are enabled. The trace is still slightly variable from one run to the next; sometimes I get one or two messages about locks, sometimes not. By the way, this is a dual Xeon workstation, without hyperthreading. ... 218 22778 [main] ls 1336 path_conv::check: this-path(\\duckling\dhinds), has_acls(0) 158 22936 [main] ls 1336 win_env::add_cache: posix //duckling/dhinds 149 23085 [main] ls 1336 win_env::add_cache: native HOME=\\duckling\dhinds 641 23726 [main] ls 1336 sigproc_init: process/signal handling enabled(1001) 203 23929 [main] ls 1336 __cygwin_lock_lock: threadcount 1. not locking And you really think using a UNC path $HOME is a good idea? And you really think you must send us this strace just for telling us that cygwin didn't like your UNC path $HOME? How about mounting this to a local volume (net use * \\duckling\dhinds or cygwin's mount) Or better use a local drive for home instead? -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: strange problems with cvs
I use CVS with cygwin a long time ago, but after a recent updte it stoped working. I'm using pserver auth and the cygwin is installed with *DOS* line-endings. When I try to do something with cvs -1.11.17- (cvs up, cvs diff, etc..) it simply returns: : no such repository Normally if I close cygwin, run the setup again (without installing anything) and opening cygwin again fixes the problem. If I do a fresh checkout, it will checkout the files with *unix* file-endings, which isn't what I asked for.. Does anyone knows whats the problem here? I think it might be cause of the release of the lastest dll version. (I update cygwin often..) Seems like you have encountered fancy EOL problem. To be safe use unix line-endings since CVS is pretty picky about those. And of course if you want to use DOS type line endings, use real win32 version of CVS. It had always worked, so there might be some change in the code that caused this... Anyway, the files in the cvs server use the unix EOL, but on my pc they use the win EOL. But cvs used to handle this for me.. I've encountered numerous problems with CVS due the line-endings... Any decent text editor should be handle both CR+LF or LF/CR only line-endings and preserving existing ones... If yours doesn't it's time to upgrade... I have vim, but I still like to use notepad, which only works with \r\n... Is there anything I can do to help solving this problem ASAP? Thanks, Nuno -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem with cygwin xerces-2.6
[EMAIL PROTECTED] wrote: Hi: I'm developing a c++ application which uses xerces-c2.6 It works just fine on the Linux Platform, but when I try to make the binary file under cygwin I get some errors regarding the linking of the xerces library. I've compiled the sources for the xerces lib following the instructions on the website and all of the examples compile run fine. Xerces is ported and included in the Cygwin net distribution, if you really have the time to build it yourself, then you should get the source package from the Cygwin mirrors where any Cygwin related modifications are already included, but I suggest that you just install the binary package using setup.exe pointing to your favorite mirror, the package is splitted into runtime, docs and devel, see http://cygwin.com/packages for details about the package naming. Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: A vexing installation problem
On Wed, Dec 01, 2004 at 07:58:25PM +0100, Reini Urban wrote: And you really think using a UNC path $HOME is a good idea? And you really think you must send us this strace just for telling us that cygwin didn't like your UNC path $HOME? Reini, I asked for the strace. I don't think that the UNC path is the problem. I have a UNC path for my home directory, in fact. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: strange problems with cvs
Nuno Lopes kirjoitti: I use CVS with cygwin a long time ago, but after a recent updte it stoped working. I'm using pserver auth and the cygwin is installed with *DOS* line-endings. When I try to do something with cvs -1.11.17- (cvs up, cvs diff, etc..) it simply returns: : no such repository Normally if I close cygwin, run the setup again (without installing anything) and opening cygwin again fixes the problem. If I do a fresh checkout, it will checkout the files with *unix* file-endings, which isn't what I asked for.. Does anyone knows whats the problem here? I think it might be cause of the release of the lastest dll version. (I update cygwin often..) Seems like you have encountered fancy EOL problem. To be safe use unix line-endings since CVS is pretty picky about those. And of course if you want to use DOS type line endings, use real win32 version of CVS. It had always worked, so there might be some change in the code that caused this... Anyway, the files in the cvs server use the unix EOL, but on my pc they use the win EOL. But cvs used to handle this for me.. This might be due difference between binary/textmode mounts in cygwin... Maybe they change for a reason or another in some of your updates... I've encountered numerous problems with CVS due the line-endings... Any decent text editor should be handle both CR+LF or LF/CR only line-endings and preserving existing ones... If yours doesn't it's time to upgrade... I have vim, but I still like to use notepad, which only works with \r\n... Is there anything I can do to help solving this problem ASAP? Getting a bit offtopic, but I personally use scite, or to be precise wscite, scintilla based editor. Small, extremely lightweight and fast, has decent code colouring, block wrapping and such. And best of all, works well with different line-endings. Of course there is some good alternatives in Cygwin distribution also... -- Jani Tiainen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Socket Programming - accept() blocking
I am trying to learn about socket programming, so I am creating a simple web
server that receives connections and sends the requested file. I have a start
to the code, and this code works fine when built and ran on a true linux
machine. However, I have been having trouble getting it to work in Cygwin.
The error occurs in the following lines of code:
if ((s_curr = accept(s, (struct sockaddr *) pin, addrlen)) == -1)
{
printf(ERROR: accept\n);
}
printf(Connection Received\n);
The accept() command is not blocking, so as soon as I attempt to start the web
server, it immediately returns the ERROR message.
Like I said, this code works fine on a true linux machine, so I was wondering
if anybody had any suggestions as to why Cygwin is not blocking for this accept
call.
Thanks,
Ryan
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Cygwin and Dragon NaturallySpeaking
I have been using Cygwin and Dragon NaturallySpeaking 7 (independantly, but on the same system) for a long time. I recently upgraded Dragon to version 8, and now any Cygwin app (or maybe it's any app that uses the cygwin DLL) that hangs around for a while (such as the X server or ssh) uses 30-40% of the CPU when it appears to be idle. This only happens after Dragon has been started. I have updated Cygwin as of 11/30. Anyone have any idea what could be going on? -- David Rudolph (781) 449-4511 (h) (617) 621-7567 (w) [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: /bin/make package and vi command
On Thu, 30 Nov 2006, Smagul wrote: Hi Igor, I found your address through internet at Cygwin's forum. Smagul, Please address all Cygwin questions and problem reports to the main Cygwin mailing list (at cygwin at cygwin dot com). This way, not only will you get access to more expertise than any one person can provide, but your questions and answers to them will also get archived on the web for others to see. For your convenience, I've redirected this reply to the list, and set Reply-To accordingly -- please make sure your mailer respects it. Recently I have installed Cygwin at my PC with Windows ME. The commands make and vi do not work. At Cygwin's forum you answered that the make command is not found because the /bin/make package was not there. Not quite. The make command (or the /bin/make executable) isn't there because the make package (that contains the /bin/make executable) isn't installed by default. If you have it, can you, please, e-mail it to me? I may accept e-mails of up to 2 Mb size. Or can you show the web address, where can I download it? How can I build it into Cygwin? Cygwin packages should be installed using the Cygwin setup tool (go to http://cygwin.com/ and follow the Install or update now! (using setup.exe) link -- the one with the black-and-green Cygwin icon). Once you're running setup, open the Devel category and select the make package. All the packages that are required for make to run will be selected automatically, but you may want to select some other development packages that you'll probably need, such as gcc. As to the vi editor, I downloaded the vim package. I do not know whether it is helpful or not. To instal vim, I need the command make to work. If you know other ways how to activate the vi , I would be happy, if you let me know. Many many thanks Smagul Again, you'll need to select it using the setup tool. Predictably, it's in the Editors category. You can select both make and vim during the same setup run. HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: A vexing installation problem
Hi, have you already tried to run the crashing application with dependency walker? http://www.dependencywalker.com/ Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: A vexing installation problem
Christopher Faylor schrieb: On Wed, Dec 01, 2004 at 07:58:25PM +0100, Reini Urban wrote: And you really think using a UNC path $HOME is a good idea? And you really think you must send us this strace just for telling us that cygwin didn't like your UNC path $HOME? Reini, I asked for the strace. I don't think that the UNC path is the problem. I have a UNC path for my home directory, in fact. Oops! sorry. -- Reini Urban -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Socket Programming - accept() blocking
Ryan wrote:
if ((s_curr = accept(s, (struct sockaddr *) pin, addrlen)) == -1)
{
printf(ERROR: accept\n);
}
printf(Connection Received\n);
You'll have to quote a *little bit* more of the program (e.g. what you
have initialized pin and addrlen with, and what calls you have made
before that (socket(), bind(), etc.)
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: PATH and SystemRoot oddity
On 1 Dec, Igor Pechtchanski wrote: The interpolation of the %...% variables into REG_MULTI_SZ values happens on the Windows level, before Cygwin ever sees them. Windows treats these variables case-insensitively. HTH, It does - thanks again, Igor. luke -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: A vexing installation problem
On Wed, Dec 01, 2004, Gerrit P. Haase wrote: have you already tried to run the crashing application with dependency walker? http://www.dependencywalker.com/ No, I was not familiar with this tool. I've attached the profile output for an invocation of readlink.exe. -- Dave Starting profile on 12/1/2004 at 2:26:43 PM Operating System: Microsoft Windows XP Professional (32-bit), version 5.01.2600 Service Pack 2 Program Executable: c:\local\cygwin\bin\READLINK.EXE Program Arguments: Starting Directory: C:\local\cygwin\bin\ Search Path: c:\program files\graphicsmagick-1.1.3-q8;C:\oracle\ora9i\bin;C:\Program Files\Oracle\jre\1.3.1\bin;C:\Program Files\Oracle\jre\1.1.8\bin;C:\WINDOWS\SYSTEM32;C:\WINDOWS;C:\WINDOWS\SYSTEM32\WBEM;C:\PROGRAM FILES\COMMON FILES\ADAPTEC SHARED\SYSTEM;C:\DMI\WIN32\BIN;C:\Tcl\bin Options Selected: Simulate ShellExecute by inserting any App Paths directories into the PATH environment variable. Log DllMain calls for process attach and process detach messages. Log DllMain calls for all other messages, including thread attach and thread detach. Hook the process to gather more detailed dependency information. Log LoadLibrary function calls. Log GetProcAddress function calls. Log thread information. Use simple thread numbers instead of actual thread IDs. Log first chance exceptions. Log debug output messages. Automatically open and profile child processes. Started READLINK.EXE (process 0x5C0) at address 0x0040 by thread 1. Successfully hooked module. Loaded NTDLL.DLL at address 0x7C90 by thread 1. Successfully hooked module. Loaded KERNEL32.DLL at address 0x7C80 by thread 1. Successfully hooked module. DllMain(0x7C90, DLL_PROCESS_ATTACH, 0x) in NTDLL.DLL called by thread 1. DllMain(0x7C90, DLL_PROCESS_ATTACH, 0x) in NTDLL.DLL returned 1 (0x1) by thread 1. DllMain(0x7C80, DLL_PROCESS_ATTACH, 0x) in KERNEL32.DLL called by thread 1. DllMain(0x7C80, DLL_PROCESS_ATTACH, 0x) in KERNEL32.DLL returned 1 (0x1) by thread 1. Injected DEPENDS.DLL at address 0x0837 by thread 1. DllMain(0x0837, DLL_PROCESS_ATTACH, 0x) in DEPENDS.DLL called by thread 1. DllMain(0x0837, DLL_PROCESS_ATTACH, 0x) in DEPENDS.DLL returned 1 (0x1) by thread 1. Loaded CYGWIN1.DLL at address 0x6100 by thread 1. Successfully hooked module. Loaded ADVAPI32.DLL at address 0x77DD by thread 1. Successfully hooked module. Loaded RPCRT4.DLL at address 0x77E7 by thread 1. Successfully hooked module. DllMain(0x77E7, DLL_PROCESS_ATTACH, 0x0022FD1C) in RPCRT4.DLL called by thread 1. DllMain(0x77E7, DLL_PROCESS_ATTACH, 0x0022FD1C) in RPCRT4.DLL returned 1 (0x1) by thread 1. DllMain(0x77DD, DLL_PROCESS_ATTACH, 0x0022FD1C) in ADVAPI32.DLL called by thread 1. DllMain(0x77DD, DLL_PROCESS_ATTACH, 0x0022FD1C) in ADVAPI32.DLL returned 1 (0x1) by thread 1. DllMain(0x6100, DLL_PROCESS_ATTACH, 0x0022FD1C) in CYGWIN1.DLL called by thread 1. Thread 2 started in KERNEL32.DLL at address 0x7C810856. LoadLibraryA(advapi32) called from CYGWIN1.DLL at address 0x610012B9 by thread 1. LoadLibraryA(advapi32) returned 0x77DD by thread 1. GetProcAddress(0x77DD [ADVAPI32.DLL], InitializeSecurityDescriptor) called from CYGWIN1.DLL at address 0x6100122E and returned 0x77DD778E by thread 1. GetProcAddress(0x77DD [ADVAPI32.DLL], SetSecurityDescriptorDacl) called from CYGWIN1.DLL at address 0x6100122E and returned 0x77DD77B3 by thread 1. GetProcAddress(0x77DD [ADVAPI32.DLL], LookupPrivilegeValueA) called from CYGWIN1.DLL at address 0x6100122E and returned 0x77DFD11B by thread 1. LoadLibraryW(rpcrt4.dll) called from RPCRT4.DLL at address 0x77E9FAF5 by thread 1. LoadLibraryW(rpcrt4.dll) returned 0x77E7 by thread 1. GetProcAddress(0x77DD [ADVAPI32.DLL], OpenProcessToken) called from CYGWIN1.DLL at address 0x6100122E and returned 0x77DD7753 by thread 1. GetProcAddress(0x77DD [ADVAPI32.DLL], AdjustTokenPrivileges) called from CYGWIN1.DLL at address 0x6100122E and returned 0x77DFC534 by thread 1. GetProcAddress(0x77DD [ADVAPI32.DLL], GetUserNameA) called from CYGWIN1.DLL at address 0x6100122E and returned 0x77DFD4C9 by thread 1. LoadLibraryA(Secur32.dll) called from ADVAPI32.DLL at address 0x77DF97AE by thread 1. Loaded SECUR32.DLL at address 0x77FE by thread 1. Successfully hooked module. DllMain(0x77FE, DLL_PROCESS_ATTACH, 0x) in SECUR32.DLL called by thread 1. DllMain(0x77FE, DLL_PROCESS_ATTACH, 0x) in SECUR32.DLL returned 1 (0x1) by thread 1. LoadLibraryA(Secur32.dll) returned 0x77FE by thread 1. GetProcAddress(0x77FE [SECUR32.DLL], GetUserNameExA) called from ADVAPI32.DLL at address 0x77DF9803 and returned 0x77FE1DD4 by
.
. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Win32::GUI cygwin patch
Laurent ROCHER schrieb:
Win32::GUI version 1.0 is availlable at Sourceforge.
Sorry that I touched cygwin too late, but I did it at last.
After 0.503 the last time, back in 2000.
All samples work, but I didn't check the latest enhancements, esp.
ImageList.
Attached are the needed fixes for cygwin:
ToolTip.xs should be renamed to Tooltip.xs. (It matters!)
Makefile_m.PL can be safely removed. I've put the mingw stuff back in.
I've added a small cygwin.c for a missing function, and add a small stub
lib (currently called libcomctl-cyg.a) dynamically.
I don't check if future versions of -lcomctl32 already define this.
itoa
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--- ./GUI.h.orig2004-05-08 19:31:22.0 +0100
+++ ./GUI.h 2004-12-01 23:44:10.469054500 +0100
@@ -37,6 +37,11 @@
extern C {
#endif
+#ifdef __CYGWIN__
+/* This is no strict ANSI definition, and not in newlib */
+char* itoa (int, char*, int);
+#endif
+
/* we want manage context if possible, See perlguts */
#if defined(PERL_IMPLICIT_CONTEXT)
#define PERL_NO_GET_CONTEXT
@@ -656,7 +661,7 @@
int MonthCal_onEvent (NOTXSPROC LPPERLWIN32GUI_USERDATA perlud, UINT uMsg,
WPARAM wParam, LPARAM lParam);
// MinGW patch
-#ifdef __MINGW__
+#if defined(__MINGW__) || defined(__CYGWIN__)
#define WNDPROC_CAST WNDPROC
#ifndef HDHITTESTINFO
#define HDHITTESTINFO HD_HITTESTINFO
@@ -728,3 +733,5 @@
#else
#define WNDPROC_CAST FARPROC
#endif
+
+}
--- ./GUI_MessageLoops.cpp.orig 2004-09-29 23:17:56.0 +0100
+++ ./GUI_MessageLoops.cpp 2004-12-01 21:49:14.750304500 +0100
@@ -176,7 +176,7 @@
SwitchBit(perlud-dwPlStyle, PERLWIN32GUI_CUSTOMCLASS, 1); // Set
Custom class flag
// Search for an extend MsgLoop procedure (-extends option in
RegisterClassEx)
-perlud-WndProc = (WNDPROC) GetDefClassProc (NOTXSCALL
((CREATESTRUCT *) lParam)-lpszClass);
+perlud-WndProc = (WNDPROC_CAST) GetDefClassProc (NOTXSCALL
((CREATESTRUCT *) lParam)-lpszClass);
if (perlud-WndProc) {
return CallWindowProc((WNDPROC_CAST) perlud-WndProc, hwnd,
uMsg, wParam, lParam);
}
@@ -658,7 +658,7 @@
SetWindowLong(hwnd, GWL_USERDATA, (long) perlud);
SwitchBit(perlud-dwPlStyle, PERLWIN32GUI_CUSTOMCLASS, 1); // Set
Custom class flag
SwitchBit(perlud-dwPlStyle, PERLWIN32GUI_MDIFRAME , 1); // Set
MDI Frame flag
-perlud-WndProc = (WNDPROC) DefMDIFrameLoop;// Set
DefFrameProc
+perlud-WndProc = (WNDPROC_CAST) DefMDIFrameLoop;
// Set DefFrameProc
if (perlud-WndProc) {
return CallWindowProc((WNDPROC_CAST) perlud-WndProc, hwnd,
uMsg, wParam, lParam);
@@ -739,7 +739,7 @@
SetWindowLong(hwnd, GWL_USERDATA, (long) perlud);
SwitchBit(perlud-dwPlStyle, PERLWIN32GUI_CUSTOMCLASS, 1); // Set
Custom class flag
SwitchBit(perlud-dwPlStyle, PERLWIN32GUI_MDICHILD , 1); // Set
MDI Frame flag
-perlud-WndProc = (WNDPROC) DefMDIChildLoop;// Set
DefMDIChildProc
+perlud-WndProc = (WNDPROC_CAST) DefMDIChildLoop;
// Set DefMDIChildProc
perlud-dwData = (DWORD) hwnd; // For
fast hwnd acces (Activate/Deactivate)
if (perlud-WndProc) {
return CallWindowProc((WNDPROC_CAST) perlud-WndProc, hwnd,
uMsg, wParam, lParam);
@@ -776,7 +776,7 @@
SwitchBit(perlud-dwPlStyle, PERLWIN32GUI_CUSTOMCLASS, 1); // Set
Custom class flag
// Search for an extend MsgLoop procedure (-extends option in
RegisterClassEx)
-perlud-WndProc = (WNDPROC) GetDefClassProc (NOTXSCALL
((CREATESTRUCT *) lParam)-lpszClass);
+perlud-WndProc = (WNDPROC_CAST) GetDefClassProc (NOTXSCALL
((CREATESTRUCT *) lParam)-lpszClass);
if (perlud-WndProc) {
return CallWindowProc((WNDPROC_CAST) perlud-WndProc, hwnd,
uMsg, wParam, lParam);
}
@@ -966,7 +966,7 @@
SwitchBit(perlud-dwPlStyle, PERLWIN32GUI_CONTAINER , 1); // Set
Container flag
// Search for an extend MsgLoop procedure (-extends option in
RegisterClassEx)
-perlud-WndProc = (WNDPROC) GetDefClassProc (NOTXSCALL
((CREATESTRUCT *) lParam)-lpszClass);
+perlud-WndProc = (WNDPROC_CAST) GetDefClassProc (NOTXSCALL
((CREATESTRUCT *) lParam)-lpszClass);
if (perlud-WndProc) {
return CallWindowProc((WNDPROC_CAST) perlud-WndProc, hwnd,
uMsg, wParam, lParam);
}
@@ -1003,7 +1003,7 @@
SwitchBit(perlud-dwPlStyle, PERLWIN32GUI_CUSTOMCLASS, 1); // Set
Custom class flag
// Search for an extend MsgLoop procedure (-extends option in
RegisterClassEx)
-perlud-WndProc = (WNDPROC)
perl 5.8.6
No need to hurry, Gerrit :) http://search.cpan.org/~nwclark/perl-5.8.6/pod/perl586delta.pod This arrived yesterday. Just wanted to know a rough timeframe and what you plan to do with the DLL name, so that I can coordinate libwin32 and the Win32::GUI upgrades. I want to seperate Win32::GUI from libwin32, and I want to contact Rafael. We have to bite the bullet with the 5.8.5 dll dependency once. Maybe I'll come up up a simplier upgrade solution, changing the dll's binmode: s/cygperl5_8_2.dll/cygperl5_8.dll/g and moving it over. Put this into the postinstall script to move all old CPAN libs to the new site_perl? Maybe I'll come to the pending Win32::API problem with the callbacks on gcc also. A simple hack30-like solution should always be possible. Or a fallback to C::Dynalib. Win32::OLE didn't compile OOTB, but this is easy. Just forgot where I put the patch. And your /usr/include/iodbcunix.h was wrong. Had to patch it to compile Win32::ODBC. Will send it later. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: strange problems with cvs
[snip] I have vim, but I still like to use notepad, which only works with \r\n... Dude, nobody *likes* to use notepad ;-). Google for a little gem called Textpad, and don't look back. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin build of perl5.8.5 (cygwin-thread-multi-64int )
My problem: the outcome of running what follows on an XP, Swedish SP2. Quote 09:33:33 ~ perldoc perldoc C:\cygwin\bin\perl.exe (1792): *** couldn't release memory 0xA04000(1032192) for 'C:\cygwin\lib\perl5\5.8.5\cygwin-thread-multi-64int\auto\Fcntl\Fcntl.dll' alignment, Win32 error 487 4 [main] perl 176 sync_with_child: child 1792(0x6A8) died before initialization with status code 0x1 148 [main] perl 176 sync_with_child: *** child state child loading dlls Unquote My environment shows USERNAME different from USER, possibly the reason of the failing installation. How shall I start cygwin assuming var. USER and USERNAME contain white space. I try in my .bash_profile in '/cygdrive/c/cygwin/home/Tom Axehult ' to export USER=Tom export HOME=/home/$USER to source .bashrc in '/cygdrive/c/cygwin/home/Tom' Tom Axehult, Stockholm A comment on error 487: Attempt to access invalid address. Cygwin Configuration Diagnostics Current System Time: Wed Dec 01 10:06:20 2004 Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\Program\Borland\Delphi7\Bin c:\Program\Borland\Delphi7\Projects\Bpl\ c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\system32\wbem c:\ATI-CPanel c:\Perl\bin\ c:\Program\Microsoft SDK\Bin\ c:\Program\Microsoft SDK\Bin\WinNT\ C:\cygwin\bin .\ c:\j2sdk1.4.2_04\bin\ c:\ant\bin\ C:\cygwin\usr\sbin Output from C:\cygwin\bin\id.exe (nontsec) UID: 1005(Tom Axehult) GID: 513(Ingen) 513(Ingen) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1005(Tom Axehult) GID: 513(Ingen) 0(root)513(Ingen) 544(Administratörer) 545(Användare) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS HOME = `C:\cygwin\home\Tom' MAKE_MODE = `unix' PWD = `/home/Tom' USER = `Tom' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' ANT_HOME = `c:\ant' APPDATA = `C:\Documents and Settings\Tom Axehult\Application Data' BASEMAKE = `C:\Program\Microsoft SDK\include\BKOffice.Mak' BKOFFICE = `C:\Program\Microsoft SDK\.' CLIENTNAME = `Console' COMMONPROGRAMFILES = `C:\Program\Delade filer' COMPUTERNAME = `AXEHULT-FUJITSU' COMSPEC = `C:\WINDOWS\system32\cmd.exe' CVS_RSH = `/bin/ssh' FP_NO_HOST_CHECK = `NO' HISTCONTROL = `ignoredups' HISTSIZE = `64' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\Tom Axehult' HOSTNAME = `Axehult-Fujitsu' INCLUDE = `c:\cygwin\usr\include\.;C:\Program\Microsoft SDK\include\.;C:\Program\Microsoft SDK\include\Win64\.;C:\Program\Microsoft SDK\include\Win64\crt\.;C:\Program\Microsoft SDK\include\Win64\atl\.;C:\Program\Microsoft SDK\include\Win64\mfc\.' INETSDK = `C:\Program\Microsoft SDK\.' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' INPUTRC = `/home/Tom/.inputrc' JAVA_HOME = `c:\j2sdk1.4.2_04' JAVA_VERSION = `1.4.2' LIB = `C:\Program\Microsoft SDK\Lib\.;' LOGONSERVER = `\\AXEHULT-FUJITSU' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man' MSDEV = `C:\Program\DevStudio' MSDEVDIR = `C:\Program\DevStudio\SharedIDE' MSSDK = `C:\Program\Microsoft SDK' MSTOOLS = `C:\Program\Microsoft SDK\.' NUMBER_OF_PROCESSORS = `2' OLDPWD = `/home/Tom Axehult' OS = `Windows_NT' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.pl' PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 3 Stepping 3, GenuineIntel' PROCESSOR_LEVEL = `15' PROCESSOR_REVISION = `0303' PROGRAMFILES = `C:\Program' PROMPT = `$P$G' PS1 = `\t \w ' SESSIONNAME = `Console' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `C:\DOCUME~1\TOMAXE~1\LOKALA~1\Temp' TERM = `cygwin' TMP = `C:\DOCUME~1\TOMAXE~1\LOKALA~1\Temp' USERDOMAIN = `AXEHULT-FUJITSU' USERNAME = `Tom Axehult' USERPROFILE = `C:\Documents and Settings\Tom Axehult' WINDIR = `C:\WINDOWS' _ = `/usr/bin/cygcheck' POSIXLY_CORRECT = `1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x0002 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/home/Tom/.cpan (default) = `c:\cygwin\home\Tom\.cpan' flags = 0x0002 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x0002 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x0002 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Re: Cygwin build of perl5.8.5 (cygwin-thread-multi-64int )
Tom Axehult wrote: My problem: the outcome of running what follows on an XP, Swedish SP2. C:\cygwin\bin\perl.exe (1792): *** couldn't release memory 0xA04000(1032192) for 'C:\cygwin\lib\perl5\5.8.5\cygwin-thread-multi-64int\auto\Fcntl\Fcntl.dll' alignment, Win32 error 487 I'm not sure if it's applicable here but have you tried rebaseall? Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: strange problems with cvs
Nuno Lopes wrote: I use CVS with cygwin a long time ago, but after a recent updte it stoped working. ... I find it is better to have a separate computer as the CVS server; I use GNU/Linux. I'm using pserver auth Don't -- use ssh. If you set up your router/firewall correctly, you and whomever you grant an account to can access your CVS server from anywhere on the Internet. It's *really* useful. I wrote a Perl convenience script 'cvsenv' that I can launch from Bash that sets up the client end of things. I also figured out how to use Unix groups to isolate multiple CVS repositories on one server; the Perl script is called 'dvs'. You can download both of them here: http://www.holgerdanske.com/dpchrist/source.html and the cygwin is installed with *DOS* line-endings. I use Cygwin with DOS line endings and the Cygwin CVS client. Everything works fine. When I try to do something with cvs -1.11.17- (cvs up, cvs diff, etc..) it simply returns: : no such repository Normally if I close cygwin, run the setup again (without installing anything) and opening cygwin again fixes the problem. If I do a fresh checkout, it will checkout the files with *unix* file-endings, which isn't what I asked for.. Does anyone knows whats the problem here? Get this book: http://cvsbook.red-bean.com/ I think it might be cause of the release of the lastest dll version. (I update cygwin often..) I very much doubt it. I've used/ been using DOS, Windows NT, GNU/Linux, BSD, DJGPP, Cygwin, and CVS for several years new, and any CVS problems I've had were always my fault. HTH, David -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
