RE: Maintainer searched
On 04 May 2006 10:22, Dave Korn wrote: On 03 May 2006 21:43, Christopher Faylor wrote: On Wed, May 03, 2006 at 10:24:19PM +0200, Gerrit P. Haase wrote: there is not enough time to maintain all my packages. Who wants to maintain one or more of my packages, maybe Yaakov wants to take over some of the GTK+ related packages? Then there are some more major packages which really require a maintainer with more time than I have (i.e. GCC, Perl). Hi Gerrit, I completely understand. I'm wondering if Dave Korn or Brian Dessent would consider maintaining gcc? cgf I will definitely consider this quite seriously. I'm always a little stretched for time but gcc is just one thing to take care of (albeit several packages) and I do have a lot of compiler experience. I'll spend some time at the weekend reading all the gbs and packaging-related docs and rolling a set of releasable gcc packages so I can get a feel for the amount of workload it's likely to place on me and come back to the list with a definite answer Monday. Well I didn't finish rolling the lot over the weekend owing to reasons I'll explain on the talk list, but I'm saying yes anyway. First thing I'll do will be reroll a 3.4.4-2 with the fix for PR-whateveritis about the C++ strings-vs-dlls problem. Once that's done and seems ok, I'll look at making an experimental package from one of the gcc 4 series. (Anyone got any preferences?) cheers, DaveK -- Can't think of a witty .sigline today
Re: Maintainer searched
Dave Korn wrote:
Well I didn't finish rolling the lot over the weekend owing to reasons I'll
explain on the talk list, but I'm saying yes anyway. First thing I'll do will
be reroll a 3.4.4-2 with the fix for PR-whateveritis about the C++
24196
It also fixes this specific problem on 4.1.0 (mingw; haven't tried
cygwin but I assume it'll work in 4.1.0 on our platform too)
strings-vs-dlls problem. Once that's done and seems ok, I'll look at making
an experimental package from one of the gcc 4 series. (Anyone got any
preferences?)
Either 4.1.[0,1] or the 4.2.0 devel branch. The mingw guys decided to
wait out the 4.0.x series because, as of last May, there were just too
many issues on windows with that series. It's an open question whether
that is also true of 4.1.x or even 4.2.devel.
I built 4.1.0 (on mingw), c/c++/fortran, and it seemed to work okay --
of course, for fortran, I needed gmp and mpfr. However, there are a few
issues:
=
(1) libjava is hopelessly broken, according to Danny Smith. I have to
concur -- I was not able to get it to build at all, so I gave up
including the java compiler in my 4.1.0 build. According to Danny, the
java compiler requires a shared libjava (and shared libgcc) -- but see
below about DLLs. (According to Danny, it takes over 1G RAM to
successfully turn a libjava.a into a DLL+implib ; I never even got
libjava.a to build so I can't verify).
Note that the autoconfigury of gcc STILL does not support
--enable-shared for cygwin or mingw, so people are still creating DLLs
from their .a's -- a dangerous and flaky procedure at best, and it did
NOT work for me.
=
(2) bootstrapping ADA requires the gnat tool from the ADAcore project --
but that, in turn, requires the build to use Dwarf2 exceptions.
However, switching to dwarf2 has significant consequences:
(a) breaks backwards compatibility for exception handling -- this
probably only affects C++ libraries currently in the cygwin
distribution, plus any other users' private C++ stuff
(b) dwarf2 means that any exceptions throw by functions passed as
callbacks to the w32api will NOT be caught. Unfortunately, this is a
common paradigm for win32 GUI applications...
(c) You can't have C/C++/Fortran be sjlj, while ada is dwarf2 -- at
least not in the same build.
=
(3) The patch by Danny Smith to allow throwing exceptions across DLL
boundaries has NOT been ported to any 4.x series -- nor will it be.
According to Danny, I've finally convinced myself
that the patch is more trouble than its worth. Libstdc++/libgcc as
dll's is how I work it in my own trre. So you are on your own.
(a) unfortunately, when I tried to make DLLs post-build out of
libgcc.a, libsupc++.a, and libstdc++.a, I couldn't get them to work --
every app I compiled died a horrible death before main() -- while they
worked if I linked against static runtime libraries.
Supposedly, this is the correct procedure, at least until the
autotoolization of the libgcc/libsupc++/libstdc++/libgfortran/etc is
upgraded to support shared-lib-building on cygwin/mingw: AFTER
completing the static build,
dlltool --output.def libstdc++.def --export-all libstdc++.a
gcc -shared -o libstdc++.dll -Wl,--out-implib,libstdc++.dll.a \
libstdc++.def libstdc++.a
(Actually, I have a slightly more complicated recipe that uses version
numbers and also munges the .la files appropriately, I'll send that
later). Not that it actually gave me a working build, mind you, but...
(b) there was a reported issue with exporting vtables and type_info
with the shared libgcc/libstdc++/libsupc++ DLLs that, according to
Danny, has not yet been worked out.
Not being able to catch an exception thrown from a DLL is a huge
restriction. It *must* be fixed before a 4.x C++ compiler is released
-- and there are two options:
(1) forward port Danny's old patch -- against his wishes, or
(2) get @#^@@#$ shared libgcc/libsupc++/libstdc++ to work
Neither is trivial.
=
There are a number of patches to the our 3.4.x packages that are
cygwin-specific but have never made it in to the 4.x CVS. I don't
know what they are, but here's a for instance:
class declspec(dllimport) MyForwardDeclaration;
is necessary if you want to import MyForwardDeclaration from a DLL using
the MSVC++ compiler. On gcc, however, you don't need to include the
declspec on forward declarations -- only at the point of actual definition:
class declspec(dllimport) MyActualDefinition
{
}
If you put an attribute marker like declspec(dllimport) in a forward
declaration, by default gcc (3.4.x unpatched, 4.x) generates a warning
like attribute valid only at point of definition; attribute ignored.
Because MSVC++ needs it in both places, compiler-neutral code for
windows tends to includes the declspec at forward declearations, and
cygming-special-gcc-3.4.x has a patch to suppress the warning. That
patch needs to be
Re: Maintainer searched
On Mon, May 08, 2006 at 10:46:22AM +0100, Dave Korn wrote: Well I didn't finish rolling the lot over the weekend owing to reasons I'll explain on the talk list, but I'm saying yes anyway. First thing I'll do will be reroll a 3.4.4-2 with the fix for PR-whateveritis about the C++ strings-vs-dlls problem. Once that's done and seems ok, I'll look at making an experimental package from one of the gcc 4 series. (Anyone got any preferences?) You may want to drop Danny Smith a line and see what he's planning so that you can coordinate between gcc and mingw. cgf
Re: Please upload: postgresql-8.1.3-2
Reini Urban wrote:
My first cygport package, great!
See
http://xarch.tu-graz.ac.at/publ/cygwin/release/postgresql/postgresql-8.1.3-2.cygport
Wow, cygport isn't even in the distro yet, but I'm glad to see the warm
reception that it's gotten. :-)
Overall, looks pretty good, and this is a complicated package. May I
suggest a few minor changes for your next version:
1) Try to avoid overriding the *FLAGS variables, IOW:
LDFLAGS=${LDFLAGS} -Wl,--enable-auto-image-base
Eventually there will be a better way to set package-specific *FLAGS.
2) I would use dolib and insinto/newins to simplify the src_install just
a bit more, as well as using ${C}, which stands for ${S}/CYGWIN-PATCHES.
(If the init.d script is supposed to be 755, then use exeinto/doexe
instead.)
src_install() {
cd ${B}
cyginstall docdir=/usr/share/doc/${P}/
# I prefer to have that in postgresql-devel already
dolib ${B}/src/backend/libpostgres.a
mv ${D}/usr/lib/*.dll ${D}/usr/bin/
dodir /usr/sbin
for admin in createlang createuser droplang dropuser initdb \
pg_ctl pg_controldata pg_resetxlog pg_restore postgres \
postmaster vacuumdb; do
mv ${D}/usr/bin/$admin.exe ${D}/usr/sbin/;
done
mv ${D}/usr/bin/ipcclean ${D}/usr/sbin/
insinto /etc/rc.d/init.d
newins ${C}/postgresql.initd postgresql
cp -r ${S}/doc/src/FAQ ${D}/usr/share/doc/${P}/
make -C contrib install DESTDIR=${D} bindir=/usr/lib/postgresql/bin/
docdir=/usr/share/doc/${P}/
}
I hope this helps.
Yaakov
Re: ITP: checkx-0.1.0-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles Wilson wrote: checkx does not yet have a home for ongoing development, save my hard drive, so there's no upstream site, and obviously there are no Linux distributions which include it. Therefore, I need some votes in favor... +1. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEX3PapiWmPGlmQSMRAnnMAKCDDphFYJi3MMVOJRz2lJY+m75+mgCeK3zN buuNCjPtjOV1Z69M6hmSJes= =VjRz -END PGP SIGNATURE-
Re: ITP: checkx-0.1.0-1
On Fri, 05 May 2006 20:54:33 -0400, Charles Wilson said: checkX is a little utility I wrote that tests to see if (a) the X11 client DLLs are installed on the machine, and (b) the Xserver on $DISPLAY (or -d x.x.x.x:x) is running and usable. checkx does not yet have a home for ongoing development, save my hard drive, so there's no upstream site, and obviously there are no Linux distributions which include it. Therefore, I need some votes in favor... Okay, that's three. So, I've uploaded checkx to sourceware and will send out an official announcement tonight. Coming soon to a mirror near you: rxvt-unicode-X. Then, I'll publish on this list a few scripts that use checkx to select between rxvt-20050409-1 and rxvt-unicode-X, and you guys can tell me how bad they stink. g -- Chuck -- Charles Wilson cygwin at removespam cwilson dot fastmail dot fm
Re: ITP: checkx-0.1.0-1
Charles Wilson wrote: checkx does not yet have a home for ongoing development, save my hard drive, so there's no upstream site, and obviously there are no Linux distributions which include it. Therefore, I need some votes in favor... +1. John.
RE: Maintainer searched
--- Dave Korn wrote: Well I didn't finish rolling the lot over the weekend owing to reasons I'll explain on the talk list, but I'm saying yes anyway. First thing I'll do will be reroll a 3.4.4-2 with the fix for PR-whateveritis about the C++ strings-vs-dlls problem. Once that's done and seems ok, I'll look at making an experimental package from one of the gcc 4 series. (Anyone got any preferences?) Dave, The octave and octave-forge packages will greatly benefit from the first bug fix. I'll produce new releases ASAP following a gcc 3.4.4-2 bug-fix release. Thanks for signing on to this important maintenance responsibility. Do you suppose there is any chance of releasing libstdc++ as a dll for gcc 3.4.4-2 ? This would greatly reduce the size of the octave and octave-forge packages. There is also some consensus that octave performance is hampered by the sjlj exception handling scheme. I wonder if it is necessary that mingw and cygwin use the same method - perhaps mingw could carry sjlj forward as it is more important for win32 programming, while cygwin could plan a transition to dwarf2, which perhaps aligns better with the paradigm of porting linux apps. Just a thought. Jim Phillips [Dave, sorry I sent the first copy to you instead of the ML]
Re: ITP: checkx-0.1.0-1
On Mon, May 08, 2006 at 01:08:39PM -0400, Charles Wilson wrote: On Fri, 05 May 2006 20:54:33 -0400, Charles Wilson said: checkX is a little utility I wrote that tests to see if (a) the X11 client DLLs are installed on the machine, and (b) the Xserver on $DISPLAY (or -d x.x.x.x:x) is running and usable. checkx does not yet have a home for ongoing development, save my hard drive, so there's no upstream site, and obviously there are no Linux distributions which include it. Therefore, I need some votes in favor... Okay, that's three. It takes five votes for inclusion, not three. From http://cygwin.com/setup.html: If the package is not included in any major Linux distro it must receive five positive votes from other package mantainers in order to be accepted. cgf
Re: ITP: checkx-0.1.0-1
cgf said: It takes five votes for inclusion, not three. From http://cygwin.com/setup.html: If the package is not included in any major Linux distro it must receive five positive votes from other package mantainers in order to be accepted. Oops. Obviously, I thought it was three. I've removed checkx from sourceware. -- Chuck -- Charles Wilson cygwin at removespam cwilson dot fastmail dot fm
gcj --- Was: (RE: Maintainer searched)
I didn't get the whole thread of this. Is someone going to try and fix the gcj? I have 3 applications that I would like to submit (Apache Tomcat, Apache Ant, and Servsys) that I can not get to build using gcj (core dump). I am really not sure what to do. They build perfectly using Suns jdk. Anyone have any suggestions? -Chris (1) libjava is hopelessly broken, according to Danny Smith. I have to concur -- I was not able to get it to build at all, so I gave up including the java compiler in my 4.1.0 build. According to Danny, the java compiler requires a shared libjava (and shared libgcc) -- but see below about DLLs. (According to Danny, it takes over 1G RAM to successfully turn a libjava.a into a DLL+implib ; I never even got libjava.a to build so I can't verify).
Re: gcj --- Was: (RE: Maintainer searched)
[top posting. Reformatted] Christopher Molnar wrote: Charles Wilson wrote: (1) libjava is hopelessly broken, according to Danny Smith. I have to concur -- I was not able to get it to build at all, so I gave up including the java compiler in my 4.1.0 build. According to Danny, the java compiler requires a shared libjava (and shared libgcc) -- but see below about DLLs. (According to Danny, it takes over 1G RAM to successfully turn a libjava.a into a DLL+implib ; I never even got libjava.a to build so I can't verify). I didn't get the whole thread of this. The section you quoted was refering to 4.x exclusively. I have no knowledge, nor make any claim of working or non-working, for the gcj shipped as part of gcc-3.4.4 on cygwin. Is someone going to try and fix the gcj? I have 3 applications that I would like to submit (Apache Tomcat, Apache Ant, and Servsys) that I can not get to build using gcj (core dump). I am really not sure what to do. They build perfectly using Suns jdk. So, this is a bug report for gcj-3.4.4 on cygwin? If so, I'd suggest just waiting until the new maintainer releases his own version of 3.4.x. (It probably won't contain any new fixes, but that'll give the new maintainer a fighting chance). Anyway, after that version is released, try it again, and then raise a bug report. And, as always Anyone have any suggestions? PTC, I'm sure. -- Chuck
What happened to xwinclip
I just installed to a new box and am unable to find 'xwinclip' in the available packages list. Is this part of another package now or has it been replaced with something else? Sterling -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: What happened to xwinclip
Sterling Baker wrote: I just installed to a new box and am unable to find 'xwinclip' in the available packages list. Is this part of another package now or has it been replaced with something else? Part of the main XWin executable now. Make sure XWin is invoked (usually from startxwin.bat or startxwin.sh) with -clipboard. I still show an xwinclip package from the cygwin package search tool, though: http://cygwin.com/packages/ (enter xwinclip) but it's not necessary. -Richard Campbell. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: What happened to xwinclip
I'm aware of the '-clipboard' option but find that to have undesirable caveats at times. I like being able to turn the clipboard integration on and off as I need. I looked on about a dozen different mirrors from the setup program and none of them showed 'xwinclip' as an available package (if I remember correctly that was an available package some time back). I wonder why the stand alone program got dropped. Guess I'll just have to do a manual install. Sterling -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Campbell Sent: Monday, May 08, 2006 8:48 AM To: cygwin-xfree@cygwin.com Subject: RE: What happened to xwinclip snip Part of the main XWin executable now. Make sure XWin is invoked (usually from startxwin.bat or startxwin.sh) with -clipboard. I still show an xwinclip package from the cygwin package search tool, though: http://cygwin.com/packages/ (enter xwinclip) but it's not necessary. -Richard Campbell. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
winsup/cygwin ChangeLog fhandler_disk_file.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2006-05-08 15:20:04 Modified files: cygwin : ChangeLog fhandler_disk_file.cc Log message: * fhandler_disk_file.cc (fhandler_disk_file::readdir): Fix typo which caused test for .. to be skipped. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.3499r2=1.3500 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=uberbaumr1=1.183r2=1.184
[Patch] Adding .. may not work in readdir()
Both else-if conditions at the end of readdir() are identical, so ..
case will never be executed.
The attached patch for fhandler_disk_file.cc 1.183 may fix this
(untested blind patch, sorry ;-)
Christian
--- fhandler_disk_file.cc.orig 2006-05-08 16:21:46.984375000 +0200
+++ fhandler_disk_file.cc 2006-05-08 16:25:08.609375000 +0200
@@ -1778,25 +1778,25 @@ fhandler_disk_file::readdir (DIR *dir, d
if (!(res = readdir_helper (dir, de, RtlNtStatusToDosError (status),
buf ? buf-FileAttributes : 0, fname)))
dir-__d_position++;
else if (!(dir-__flags dirent_saw_dot))
{
strcpy (de-d_name , .);
de-d_ino = readdir_get_ino_by_handle (dir-__handle);
dir-__d_position++;
dir-__flags |= dirent_saw_dot;
res = 0;
}
- else if (!(dir-__flags dirent_saw_dot))
+ else if (!(dir-__flags dirent_saw_dot_dot))
{
strcpy (de-d_name , ..);
de-d_ino = readdir_get_ino (dir, pc.normalized_path, true);
dir-__d_position++;
dir-__flags |= dirent_saw_dot_dot;
res = 0;
}
syscall_printf (%d = readdir (%p, %p) (%s), res, dir, de, res ? *** :
de-d_name);
return res;
}
Re: [Patch] Adding .. may not work in readdir()
On Mon, May 08, 2006 at 04:42:27PM +0200, Christian Franke wrote: Both else-if conditions at the end of readdir() are identical, so .. case will never be executed. The attached patch for fhandler_disk_file.cc 1.183 may fix this (untested blind patch, sorry ;-) Thanks for the patch. I've checked it in along with a changelog. cgf
/usr/bin/install: accessing `//filesrv/chj//.bashrc': Permission denied
Windows XP Pro/SP2 cygwin Pentium M processor 2.13GHz system with cygwin 1.5.19-4... I don't seem to be able to login using ssh anymore, I still can login console but not remotely using ssh... any help in debuggin this or even getting this to work again is greatly appreciated. This is how a try to remotely login looks: [EMAIL PROTECTED] objdir]$ ssh -X toppen.win [EMAIL PROTECTED]'s password: Permission denied, please try again. [EMAIL PROTECTED]'s password: $ ssh -X toppen.win [EMAIL PROTECTED]'s password: Last login: Mon May 8 08:09:20 2006 from dhcp-111 Fanfare!!! You are successfully logged in to this server!!! Could not chdir to home directory //filesrv/chj: Permission denied mkdir: `//filesrv/chj': Permission denied Copying skeleton files. These files are for the user to personalise their cygwin experience. These will never be overwritten. /usr/bin/install: accessing `//filesrv/chj//.bashrc': Permission denied /usr/bin/install: accessing `//filesrv/chj//.bash_profile': Permission denied /usr/bin/install: accessing `//filersrv/chj//.inputrc': Permission denied -bash: cd: //filesrv/chj: Permission denied -bash: //filesrv/chj/.bash_profile: Permission denied [EMAIL PROTECTED] /etc/skel $ -- Cheers, /ChJ -- 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/
pthread_mutex_init + gdb issue again
Alright, I'm aware of the check for invalid memory region and throw
exception issue present when debugging pthread applications under gdb
and that the actual segfault is innocuous. However, the following solutions:
1. handle SIGSEGV nostop
handle SIGTRAP nostop
2. (hit continue on every SIGSEGV raised).
Are unacceptable to me. I have functions which initialize mutexes for
1000s of objects at load time. e.g. parse, alloc struct, init mutex within
struct. For one, it becomes fruitless to try and debug a real segfault issue
when using gdb and pthreads under cygwin. The only option when working
with mass mutexes is disable stopping on SIGSEGV within gdb - rendering
useless the debugging of an actual real segfault situation.
This is the best I could come up with to get around it, and frankly it's a
ridiculous hack, that's entirely non-portable, possibly even with future
versions of cygwin libraries - but it's necessary to keep my sanity when
debugging pthreads based apps under cygwin:
#ifdef __CYGWIN__
# define PT_m_init(x, y) \
{ \
*x = malloc(sizeof(struct __pthread_mutex_t)); \
(**x).__dummy = 56; \
}
#else
# define PT_m_init(x, y) \
pthread_mutex_init((x), (y))
#endif
Someone throw me a bone here, please.
-cl
--
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: pthread_mutex_init + gdb issue again
[EMAIL PROTECTED] wrote: Someone throw me a bone here, please. Rather than work-arounds, why not just use a recent build of gdb that doesn't suffer from this problem? The issue was fixed in CVS earlier this year. But do note that it requires functionality not present in Cygwin 1.5.19, so you'll also need to use a recent Cygwin snapshot. 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: C exe redirection blank file
Thanks again for your reply, René cygcheck program Did that. Gives me the same DLLs as the working one. Incidentally I'm run a one minute cron job (for the working process) - would that affect anything? Could be, if the process runs more than once concurrently and tries to access the same file. It certainly will try to access the same port. Nope it shouldn't access any of the same files, apart from - as you say - the port. [snip] Is there a limit to the number of files on XP I don't know what functionality you are looking for, do you expect a limit on the number of files on a directory? Windows does have a limit on the size of a path, and there is a limit on the number of files but it is pretty big (I don't remember it at the moment.) I'm not looking for any functionality here, just wondering if it could be affecting anything. I have had issues on other systems with numbers of files - but not on PCs. none of problem_program's output! This is only on one machine, right? just as if you are closing stdout. Yep - only on one machine. Incidentally I did have trouble with the serial port baud rate, and increased programmatically for this program up to 38400 (from 9600). Would this have any bearing? It's the same on both PCs (and same hardware attached to each on the same port number). However, just recompiled another program that uses the same serial-port handler and string-handler (include files), copied over to 'live' and it can redirect OK. Limits it down to main() or the one remaining include file (big one) of this program! I may experiment with it while I eagerly await your reply. There are many possibilities but none will stand if the program works one way on a computer and another way on a different computer. So the most probable cause is some difference between computers. Right, been looking into that. I have the following set up PROBLEM PC: I'm using .bash_profile to set things, rather than a user profile (not created). I'm using the variable $CC to hold the working directory (would this conflict with a c compiler variable?). On this PC I set up the variable in the following way (at the end of .bash_profile): CC=c:/dir export $CC cd $CC in ENV: HOMEPATH=\Documents and Settings\Andy PROCESSOR_IDENTIFIER=x86 Family 15 Model 1 Stepping 2, GenuineIntel OLDPWD=/home/Andy !C:=C:\cygwin\bin HOME=/home/Andy HOMEDRIVE=C: CC=c:/dir WORKING PC: I use my username's .profile. I set up the variable $CDIR to hold the working directory. On this PC I set up the variable in the following way: created Windows Environment Variable %cdir% as e:/c/workshop/dir in my user .profile I do cd $CDIR in ENV: HOMEPATH=\ PROCESSOR_IDENTIFIER=x86 Family 15 Model 3 Stepping 4, GenuineIntel OLDPWD=/cygdrive/b (connecting to remote drive on Bad PC) !C:=C:\ HOME=//computer/data HOMEDRIVE=T: (a share I mapped previously in Windows). CC=/usr/bin/gcc.exe (although I don't use $CC otherwise) The USER and MAKEMODE details are the same. I have other C compilers installed on the Good PC. The problem PC also has TEXDOCVIEW entries? Would any of this affect my processing? Would any other env entries help with clarification? * Is the chkdsk error significant.. I don't see how it could be a factor, but I may be missing something. Better try to see what's the cause (a damaged sector that cannot be remapped?). I'll probably have to backup my hard disc first, and then run a Seagate diagnostic tool, but I'm loathed to do so. I've read on the internet that this message could be a red herring. I have a hardware-expert friend, I'll contact him too. * Have you ever heard of anything similar on Linux/Unix? Anything is possible. For instance, an uninitialized pointer could cause writing in the file descriptor table same effect as closing/changing those file descriptors, An uninitialised pointer, you say? I'm only using character pointers. I suppose an uninitialised one would just be used (in say strcpy) rather than having been set beforehand. How can you detect it in GDB? if the program is not too complex I would use gdb to see the execution at least once, if it is complex then better isolate the problem first. Ok, it's not *too* complicated. How would you advise using GDB to test this issue? I've only just learnt that tool. What should I be checking for - adding a watch on stdout or something? * Does windows have a lock on a file or something? Yes. You probably have seen it, when Windows doesn't allow you to delete a file because it is in use Oh yes, I've seen it - especially on Windows 3.1! Bearing in mind I've rebooted a few time, I don't think that'd happen again - would it? (try deleting all the .tmp files in your temp directory). I've done that. No joy. * I'm
Re: pthread_mutex_init + gdb issue again
On Mon, May 08, 2006 at 02:01:00AM -0700, Brian Dessent wrote: Rather than work-arounds, why not just use a recent build of gdb that doesn't suffer from this problem? The issue was fixed in CVS earlier this year. But do note that it requires functionality not present in Cygwin 1.5.19, so you'll also need to use a recent Cygwin snapshot. Thanks. I'll look into it. My workaround isn't a proper workaround after all anyways. -cl -- 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: pthread_mutex_init + gdb issue again
On Mon, May 08, 2006 at 02:44:37AM -0700, [EMAIL PROTECTED] wrote: On Mon, May 08, 2006 at 02:01:00AM -0700, Brian Dessent wrote: Rather than work-arounds, why not just use a recent build of gdb that doesn't suffer from this problem? The issue was fixed in CVS earlier this year. But do note that it requires functionality not present in Cygwin 1.5.19, so you'll also need to use a recent Cygwin snapshot. Thanks. I'll look into it. My workaround isn't a proper workaround after all anyways. -cl Thanks Brian, much better. The issue was that I could not find any reference to the problem ever being fixed - just a lot of threads where people were ending with yea you gotta hit continue - it sucks. Everything is cool now with gdb 6.4 and the 4-27 snapshot. We'll see how stable it is. NX is working fine with it, however. -cl -- 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: pthread_mutex_init + gdb issue again
[EMAIL PROTECTED] wrote: Thanks Brian, much better. The issue was that I could not find any reference to the problem ever being fixed - just a lot of threads where people were ending with yea you gotta hit continue - it sucks. Right. It was reported often, and because of that there was a lot of noise, and if you weren't following the patches going into cygwin and gdb it would be easy to overlook as there wasn't exactly fanfare. I expect that after 1.5.20 is out the door an updated gdb binary package will happen, and hopefully at that point it will be a lot easier to say use the new version, see the release announcement compared to build it yourself from CVS. 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: pthread_mutex_init + gdb issue again
Brian Dessent wrote: I expect that after 1.5.20 is out the door an updated gdb binary package will happen, will _eventually_ happen ...as in, I'm not the gdb maintainer and don't pretend to presume any kind of implied schedule. -- 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: chmod works only for cygwin processes
On 04 May 2006 13:03, Magnus Svensson wrote: # Now I pipe dir test to windows cmd.exe and it can read it. Can't reproduce. What do you see as output if you run getfacl testdir and cacls testdir in the bash shell after the cmd.exe test shows it can be read? Also, please verify that you're running the expected versions of mkdir, chmod, ls, etc. using the 'which' command... it's just possible there's a non-cygwin version in your path. 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: pthread_mutex_init + gdb issue again
One thing about this 4-27 snap, and I noticed it with 4-03 as well (which I reverted from a while ago) is that disk i/o appears to be ridiculously slow in comparison to 1.5.19. In rough estimation, I'd have to say a 50% reduction in I/O throughput. I notice it while working with mass updating of files and builds. Is there any form of profiling, etc. enabled in the snap builds? As even if there were zero optimization, it wouldn't be this noticably slow. -cl On Mon, May 08, 2006 at 03:46:04AM -0700, Brian Dessent wrote: I expect that after 1.5.20 is out the door an updated gdb binary package will happen, and hopefully at that point it will be a lot easier to say use the new version, see the release announcement compared to build it yourself from CVS. 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: chmod works only for cygwin processes
Dave Korn wrote: On 04 May 2006 13:03, Magnus Svensson wrote: # Now I pipe dir test to windows cmd.exe and it can read it. Can't reproduce. What do you see as output if you run getfacl testdir and cacls testdir in the bash shell after the cmd.exe test shows it can be read? This is how it looks like just after cmd.exe can read the dir. Also tried chmod , can still read the dir. $ getfacl testdir # file: testdir # owner: mysqldev # group: None user::-wx group::-wx mask:rwx other:-wx default:user::rwx default:group::rwx default:other:rwx Below is the cacls testdir output. My guess is that is the sshd_server account that in some way mess up the acl's? If I look in the Security properties for the mysqldev directory(where I run the command from), there is only three users listed. CREATOR GROUP Special CREATOR OWNER Full control Not inherited Subfolders and files only mysqldev(WIN2003-x86) Full control Not inherited This folder only $ cacls testdir WIN2003-X86\sshd_server:(special access:) STANDARD_RIGHTS_ALL DELETE READ_CONTROL WRITE_DAC WRITE_OWNER SYNCHRONIZE STANDARD_RIGHTS_REQUIRED FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_WRITE_DATA FILE_APPEND_DATA FILE_WRITE_EA FILE_EXECUTE FILE_DELETE_CHILD FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES WIN2003-X86\None:(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_DELETE_CHILD FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES Everyone:(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_DELETE_CHILD FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES CREATOR OWNER:(OI)(CI)(IO)F CREATOR GROUP:(OI)(CI)(IO)(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_DELETE_CHILD FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES Everyone:(OI)(CI)(IO)(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_DELETE_CHILD FILE_READ_ATTRIBUTES Also, please verify that you're running the expected versions of mkdir, chmod, ls, etc. using the 'which' command... it's just possible there's a non-cygwin version in your path. [EMAIL PROTECTED]:~ pwd /home/mysqldev [EMAIL PROTECTED]:~ which chmod /usr/bin/chmod [EMAIL PROTECTED]:~ which mkdir /usr/bin/mkdir [EMAIL PROTECTED]:~ which ls /usr/bin/ls [EMAIL PROTECTED]:~ which getfacl /usr/bin/getfacl [EMAIL PROTECTED]:~ which cacls /cygdrive/c/WINDOWS/system32/cacls -- Magnus Svensson, Software Engineer MySQL AB, www.mysql.com -- 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: /usr/bin/install: accessing `//filesrv/chj//.bashrc': Permission denied
Christian Joensson wrote: Windows XP Pro/SP2 cygwin Pentium M processor 2.13GHz system with cygwin 1.5.19-4... I don't seem to be able to login using ssh anymore, I still can login console but not remotely using ssh... any help in debuggin this or even getting this to work again is greatly appreciated. This is how a try to remotely login looks: [EMAIL PROTECTED] objdir]$ ssh -X toppen.win [EMAIL PROTECTED]'s password: Permission denied, please try again. [EMAIL PROTECTED]'s password: $ ssh -X toppen.win [EMAIL PROTECTED]'s password: Last login: Mon May 8 08:09:20 2006 from dhcp-111 Fanfare!!! You are successfully logged in to this server!!! Could not chdir to home directory //filesrv/chj: Permission denied mkdir: `//filesrv/chj': Permission denied Copying skeleton files. These files are for the user to personalise their cygwin experience. These will never be overwritten. /usr/bin/install: accessing `//filesrv/chj//.bashrc': Permission denied /usr/bin/install: accessing `//filesrv/chj//.bash_profile': Permission denied /usr/bin/install: accessing `//filersrv/chj//.inputrc': Permission denied -bash: cd: //filesrv/chj: Permission denied -bash: //filesrv/chj/.bash_profile: Permission denied [EMAIL PROTECTED] /etc/skel $ OK, you've described your problem but given no information about your environment. Without it, we're all shooting in the dark. Please read and follow the problem reporting guidelines so that interested folks on this list can give you some targeted feedback on this issue: Problem reports: http://cygwin.com/problems.html As a WAG, you probably need to add 'smbntsec' to your CYGWIN environment variable. See the Cygwin User's Guide for more details: Documentation: http://cygwin.com/docs.html -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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: pthread_mutex_init + gdb issue again
On 05/08/2006, clayne wrote: Is there any form of profiling, etc. enabled in the snap builds? Snapshots have separately downloadable debug symbols, if that would help in this case... -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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: /usr/bin/install: accessing `//filesrv/chj//.bashrc': Permission denied
On Mon, 8 May 2006, Larry Hall (Cygwin) wrote: Christian Joensson wrote: Windows XP Pro/SP2 cygwin Pentium M processor 2.13GHz system with cygwin 1.5.19-4... I don't seem to be able to login using ssh anymore, I still can login console but not remotely using ssh... any help in debuggin this or even getting this to work again is greatly appreciated. This is how a try to remotely login looks: [EMAIL PROTECTED] objdir]$ ssh -X toppen.win [EMAIL PROTECTED]'s password: Permission denied, please try again. [EMAIL PROTECTED]'s password: $ ssh -X toppen.win [EMAIL PROTECTED]'s password: Last login: Mon May 8 08:09:20 2006 from dhcp-111 Fanfare!!! You are successfully logged in to this server!!! Could not chdir to home directory //filesrv/chj: Permission denied mkdir: `//filesrv/chj': Permission denied Copying skeleton files. These files are for the user to personalise their cygwin experience. These will never be overwritten. /usr/bin/install: accessing `//filesrv/chj//.bashrc': Permission denied /usr/bin/install: accessing `//filesrv/chj//.bash_profile': Permission denied /usr/bin/install: accessing `//filersrv/chj//.inputrc': Permission denied -bash: cd: //filesrv/chj: Permission denied -bash: //filesrv/chj/.bash_profile: Permission denied [EMAIL PROTECTED] /etc/skel $ OK, you've described your problem but given no information about your environment. Without it, we're all shooting in the dark. Please read and follow the problem reporting guidelines so that interested folks on this list can give you some targeted feedback on this issue: Problem reports: http://cygwin.com/problems.html As a WAG, you probably need to add 'smbntsec' to your CYGWIN environment variable. See the Cygwin User's Guide for more details: Documentation: http://cygwin.com/docs.html Hmm, sounds more like http://cygwin.com/faq/faq.using.html#faq.using.shares. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- 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: terminal escape codes
On Fri, 5 May 2006, Andrew DeFaria wrote: Jeff Lange wrote: While that does work, It unfortunately isn't an acceptable solution for me. I really need to be running this from a plain text console. How is running rxvt not a plain text console?!? I use rxvt all the time. I don't like the Windows window as it's cut and paste semantics are horrible as well as it's resizing (in)ability. Windows has a notion of a console window. rxvt, xterm, ssh, and pretty much any other Cygwin program that doesn't allocate an explicit console window uses ptys to emulate console output. Some Windows programs cannot understand ptys, and thus don't work properly via ssh, or in rxvt. So the OP's need may be valid. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- 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: pthread_mutex_init + gdb issue again
On Mon, May 08, 2006 at 03:55:01AM -0700, Brian Dessent wrote: Brian Dessent wrote: I expect that after 1.5.20 is out the door an updated gdb binary package will happen, will _eventually_ happen ...as in, I'm not the gdb maintainer and don't pretend to presume any kind of implied schedule. There was an outstanding issue with CVS gdb which prevented me from releasing it. I am not 100% sure that it is fixed now but things seem to be ok so I may release a new version this week. 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: chmod works only for cygwin processes
On Mon, 8 May 2006, Magnus Svensson wrote: Dave Korn wrote: [snip] Also, please verify that you're running the expected versions of mkdir, chmod, ls, etc. using the 'which' command... it's just possible there's a non-cygwin version in your path. [EMAIL PROTECTED]:~ pwd /home/mysqldev [EMAIL PROTECTED]:~ which chmod /usr/bin/chmod [EMAIL PROTECTED]:~ which mkdir /usr/bin/mkdir [EMAIL PROTECTED]:~ which ls /usr/bin/ls [EMAIL PROTECTED]:~ which getfacl /usr/bin/getfacl [EMAIL PROTECTED]:~ which cacls /cygdrive/c/WINDOWS/system32/cacls FYI, 'which' doesn't know about bash aliases/functions. You might be better off using the 'type' bash builtin instead (this is just for the future, please only report the results to the list if they are different from the above). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- 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: Win2003 server and cron/sshd as services (1.5.19)
[EMAIL PROTECTED] ~ $ cygrunsrv -I sshd --shutdown -p /usr/sbin/sshd -a -D -ddd \ -d CYGWIN sshd -u sshd_server -w a_fine_password -e CYGWIN=binmode ntsec tty 1. I assume that you meant to provide a \ after '-e' in the second line of your command above, correct? 2. In my earlier code, I had provided the following option to the cygrunsrv program: --args -D Note the double quotes around the '-D', above. I never would have suspected it, but those double quotes -- when used to install the cron service -- will cause cygrunsrv to fail when attempting to start cron. This surprised me because I use the double quotes around '-D' when starting sshd. In the case of starting 'sshd' the double quotes do not cause any problem. Going forward, for consistency, I have no quotes around '-D' for either 'cron' or 'sshd'. Can anyone else on the Cygwin mailing list test this behavior? Here are the prerequisites: Windows 2003 and an 'sshd_server' user account in your /etc/passwd (usually created by the script named 'ssh-host-config'), with a corresponding password for that special user account. The following command consistently fails: cygrunsrv --install cron --path /usr/sbin/cron --shutdown --args -D \ --disp Cygwin cron --desc Cygwin vixie-cron service \ --user sshd_server --passwd your-fine-password; The following command consistently works: cygrunsrv --install cron --path /usr/sbin/cron --shutdown --args -D \ --disp Cygwin cron --desc Cygwin vixie-cron service \ --user sshd_server --passwd your-fine-password; 3. If you are still not getting cron to start, then I would suspect that the password you are entering for the special account 'sshd_server' is incorrect. Here are some steps you could try to confirm the password: a. Log off your Windows account b. At the Windows login dialog, enter 'sshd_server' in the 'User name' field. c. Enter the password for this account (do NOT press [Enter] or click on 'OK'). d. In the 'Log on to' field, select the 'hostname' (this computer) value so that you are NOT logging on to your local network, if any). e. Click on 'OK' or press [Enter]. If the error message: The system could not log you on. Make sure your User name and domain are correct, then type your password again is displayed, then either you typed the wrong password or your knowledge of the password is incorrect. If the error message: The local policy of this system does not permit you to logon interactively is displayed, then your knowledge of the 'sshd_server' user account's password is correct. -- 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: Unable to Run Latest Cygwin in Win2k
On 05 May 2006 04:37, Loh Kok Jeng wrote: Hi Dave, Thanks for your response. Below is the output on my PC: cacls cygcheck.exe C:\Program Files\cygwin\bincacls cygcheck.exe C:\Program Files\cygwin\bin cacls strace.exe C:\Program Files\cygwin\bincacls strace.exe C:\Program Files\cygwin\bin Ok, this is really strange. You can't even seem to run an ordinary windows program at the commandline successfully. This is starting to look like administrative lock-down. USERDNSDOMAIN=XXX.yyy.com USERDOMAIN=XXX I'm beginning to run out of ideas here, but you appear to be logged on in a domain. Are you an ordinary user? Has the domain admin perhaps set policies to prevent new and unknown executables from being run by non-privileged users? What (if any) antivirus and firewall software do you use? 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/
make v3.80: *** [hello] Error 255
This is the dumbest thing. The makefile couldn't be simpler: $ cat makefile hello: hello.c gcc -o hello hello.c When I run this, I get: $ make gcc -o hello hello.c make: *** [hello] Error 255 If I do a dry run and pass the output to the shell it works just fine: $ make -n dryrun $ sh dryrun (no errors) I tried changing the line terminators in the makefile from CR/LF to LF. The SHELL environment variable points to a valid sh. which sh finds the same shell. I tried the --unix and --win32 switches. The output of make -d ends with: Must remake target `hello'. gcc -o hello hello.c Putting child 0x1002c7f0 (hello) PID 444 on the chain. Live child 0x1002c7f0 (hello) PID 444 Got a SIGCHLD; 1 unreaped children. Reaping losing child 0x1002c7f0 PID 444 make: *** [hello] Error 255 Removing child 0x1002c7f0 PID 444 from chain. WTF is going on?? -- 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: C exe redirection blank file
[EMAIL PROTECTED] wrote: [snip] Incidentally I did have trouble with the serial port baud rate, and increased programmatically for this program up to 38400 (from 9600). Would this have any bearing? It's the same on both PCs (and same hardware attached to each on the same port number). Don't think so. However, just recompiled another program that uses the same serial-port handler and string-handler (include files), copied over to 'live' and it can redirect OK. Limits it down to main() or the one remaining include file (big one) of this program! I may experiment with it while I eagerly await your reply. There are many possibilities but none will stand if the program works one way on a computer and another way on a different computer. So the most probable cause is some difference between computers. Right, been looking into that. I have the following set up PROBLEM PC: I'm using .bash_profile to set things, rather than a user profile (not created). I'm using the variable $CC to hold the working directory (would this conflict with a c compiler variable?). CC is only used by make and configure scripts. On this PC I set up the variable in the following way (at the end of .bash_profile): CC=c:/dir export $CC cd $CC in ENV: HOMEPATH=\Documents and Settings\Andy PROCESSOR_IDENTIFIER=x86 Family 15 Model 1 Stepping 2, GenuineIntel OLDPWD=/home/Andy !C:=C:\cygwin\bin HOME=/home/Andy HOMEDRIVE=C: CC=c:/dir WORKING PC: I use my username's .profile. I set up the variable $CDIR to hold the working directory. On this PC I set up the variable in the following way: created Windows Environment Variable %cdir% as e:/c/workshop/dir in my user .profile I do cd $CDIR in ENV: HOMEPATH=\ PROCESSOR_IDENTIFIER=x86 Family 15 Model 3 Stepping 4, GenuineIntel OLDPWD=/cygdrive/b (connecting to remote drive on Bad PC) !C:=C:\ HOME=//computer/data HOMEDRIVE=T: (a share I mapped previously in Windows). CC=/usr/bin/gcc.exe (although I don't use $CC otherwise) The USER and MAKEMODE details are the same. I have other C compilers installed on the Good PC. The problem PC also has TEXDOCVIEW entries? Would any of this affect my processing? Would any other env entries help with clarification? No, on all questions. [snip] An uninitialised pointer, you say? I'm only using character pointers. I suppose an uninitialised one would just be used (in say strcpy) rather than having been set beforehand. How can you detect it in GDB? Any pointer can be misused, the best way to detect problems is using something like Electric Fence (efence) or similar, but I don't think they detect random pointers (the effect of uninitialized pointers). Best way to find out if that is the problem: initialize all pointers to null. if the program is not too complex I would use gdb to see the execution at least once, if it is complex then better isolate the problem first. Ok, it's not *too* complicated. How would you advise using GDB to test this issue? I've only just learnt that tool. What should I be checking for - adding a watch on stdout or something? No, my idea is to run the program step by step following the source code. On the other hand, yes, you could use a watch on the real variable (stdout is a macro so it's not that easy to track, but it may be necessary). On the target machine you probably don't have all the necessary tools, so this could be a lot of work. You need the equivalent of an IDE (to look at the code and values of variables at the same time). It is easier just to initialize pointers to null. That is, since I suspect that the file descriptor table is being overwritten. * Does windows have a lock on a file or something? Yes. You probably have seen it, when Windows doesn't allow you to delete a file because it is in use Oh yes, I've seen it - especially on Windows 3.1! Bearing in mind I've rebooted a few time, I don't think that'd happen again - would it? What would happen again? The point here was that Windows does have some kind of locks... if you don't use them then it has no relevance to the problem. [snip] I also run in on the development machine in a different folder structure - e:\C\workshop\dir. Cygwin is installed on the E drive on the development machine, and on C on the 'live' machine. This reminds me of configuring serial printers settings had to match on both the terminal and the printer! Right now it looks more like a program error, it is strange that the problem appears to be in only the target computer, that lead me to believe there was something different but maybe not. -- René Berber -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports:
RE: make v3.80: *** [hello] Error 255
The thread that starts here might be useful to you: Make error 255 bug http://www.cygwin.com/ml/cygwin/2003-09/msg01605.html Also, providing the output of 'cygcheck -s -v -r' as an attachment might reveal something that someone on this list could use to identify the source of the problem you're having. Please see also: http://cygwin.com/problems.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harold Rabbie Sent: Monday, May 08, 2006 3:39 PM To: cygwin@cygwin.com Subject: make v3.80: *** [hello] Error 255 This is the dumbest thing. The makefile couldn't be simpler: $ cat makefile hello: hello.c gcc -o hello hello.c When I run this, I get: $ make gcc -o hello hello.c make: *** [hello] Error 255 -- 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: make v3.80: *** [hello] Error 255
Yeah, I read that thread, and it refers to a problem with very long command lines. I don't think gcc -o hello hello.c qualifies. cygcheck says: $ cygcheck -s -v -r Cygwin Win95/NT Configuration Diagnostics Current System Time: Mon May 08 14:39:55 2006 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: \usr\vast\comet5\gcc\bin \windows\system32 . `id' program not found Strange id is there $ which id /usr/vast/comet5/gcc/bin/id $ ls -l /usr/vast/comet5/gcc/bin/id -rwxr-xr-x1 h.rabbie mkpasswd26112 Jan 7 2003 /usr/vast/comet5/gcc/bin/id $ echo $PATH /usr/vast/comet5/gcc/bin:/windows/system32: Must be something to do with spawning a sub-process (applies both to make and to cygcheck) -- Original message -- From: Harig, Mark [EMAIL PROTECTED] The thread that starts here might be useful to you: Make error 255 bug http://www.cygwin.com/ml/cygwin/2003-09/msg01605.html Also, providing the output of 'cygcheck -s -v -r' as an attachment might reveal something that someone on this list could use to identify the source of the problem you're having. Please see also: http://cygwin.com/problems.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harold Rabbie Sent: Monday, May 08, 2006 3:39 PM To: cygwin@cygwin.com Subject: make v3.80: *** [hello] Error 255 This is the dumbest thing. The makefile couldn't be simpler: $ cat makefile hello: hello.c gcc -o hello hello.c When I run this, I get: $ make gcc -o hello hello.c make: *** [hello] Error 255 -- 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: make v3.80: *** [hello] Error 255
Please send all replies to the cygwin mailing list. This will increase your chances of getting a reply and the correct diagnosis of your problem. From your text below, it looks as though your Cygwin environment has several problems. 1. The PATH environment variable does not appear to have any reference to cygwin directories (c:\cygwin\bin, for example). It's surprising to me that you're able to get much to run. 2. cygcheck was not able to find 'id' (typically, this is C:\cygwin\bin\id.exe). This could be because you don't have the 'coreutils package installed, or because PATH does not reference any cygwin directories. 3. You might consider un-installing cygwin and carefully re-installing it. If you take this approach, then try installing cygwin in (at least) two stages. The first stage simply accepts the default packages that 'setup.exe' selects. Install these packages to completion and then start 'setup.exe' again. During the second stage, select the minimal set of additional packages that you want (for example, 'vim' or 'emacs', 'gcc', etc.). Then only add packages as you find that programs you need were not installed by default. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, May 08, 2006 5:48 PM To: Harig, Mark Subject: RE: make v3.80: *** [hello] Error 255 Mark, Yeah, I read that thread, and it refers to a problem with very long command lines. I don't think gcc -o hello hello.c qualifies. cygcheck says: $ cygcheck -s -v -r Cygwin Win95/NT Configuration Diagnostics Current System Time: Mon May 08 14:39:55 2006 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: \usr\vast\comet5\gcc\bin \windows\system32 . `id' program not found Does that help? Thanks! Harold -- 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 1.5.19-4 issues
Hi, This is my second call to the cygwin developers. There is a problem with cygwin 1.5.19-4 (on windows xp sp2). The qt designer (/usr/lib/qt3/bin/designer) crashes and its compilation from source fails. You might not care about matplotlib, but the gcc: fork: Resource temporarily unavailable which I get during compilation, indicates some other trouble. Please let me know if you think otherwise, or if you don't get the same behavior. What changes made between 1.5.19-4 and 1.5.18-1 could produce these problems? Thanks, Virgil -- 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 1.5.19-4 issues
I suggest doing a google search on the following terms: cygwin temporarily unavailable desktop heap Or here's a pointer to one: http://www.cygwin.com/ml/cygwin/2002-02/msg01068.html On Mon, May 08, 2006 at 06:00:52PM -0700, Virgil Adumitroaie wrote: fork: Resource temporarily unavailable which I get during compilation, indicates some other trouble. Please let me know if you think otherwise, or if you don't get the same behavior. What changes made between 1.5.19-4 and 1.5.18-1 could produce these problems? -- 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/
Environment variables in 1.5.19(0.150/4/2) 2006-01-20 13:28
Hi all,
I'm having trouble with environment variables when running commands through ssh.
I have applied this fix to my /etc/profile:
# When initiating a Cygwin bash session via SSH, Cygwin only registers
the environment variables
# for the SYSTEM account, not for the individual user's account.
if [ $SSH_TTY ]; then
pushd . /dev/null
for __dir in \
/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Session\
Manager/Environment \
/proc/registry/HKEY_CURRENT_USER/Environment
do
cd $__dir
for __var in *
do
__var=`echo $__var | tr '[a-z]' '[A-Z]'`
test -z ${!__var} export $__var=`cat $__var` /dev/null 21
done
done
unset __dir
unset __var
popd /dev/null
fi
This works for standard ssh sessions, but not for commands run through ssh.
The commands I'm running need access to the full environment variable
list, which differs from machine to machine. Here's a summary of
success and failure:
1. 'ssh [EMAIL PROTECTED]' - environment variables okay with a normal ssh
session.
2. 'ssh [EMAIL PROTECTED] bash --login -i' - only some environment variables.
3. 'ssh [EMAIL PROTECTED] mycmd - doesn't work due to missing environment
variables.
To illustrate, consider the difference between 1 and 3, here's the
environment variables section of the output to cygcheck -sv:
(removed represents stuff I've taken out of this post)
1. 'ssh [EMAIL PROTECTED] ' - then call cygcheck -sv:
USER = 'deploy'
PWD = '/home/deploy'
CYGWIN = 'ntsec'
HOME = '/home/deploy'
MAKE_MODE = 'unix'
HOMEPATH = '\cygwin\home\deploy'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
SYBASE_SYSAM = 'SYSAM-3_0'
HOSTNAME = 'removed'
TERM = 'cygwin'
SHELL = '/bin/bash'
PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 2 Stepping 9, GenuineIntel'
WINDIR = 'C:\WINNT'
SSH_CLIENT = 'removed 41558 22'
TEXDOCVIEW_txt = 'cygstart %s'
TEXDOCVIEW_dvi = 'cygstart %s'
OLDPWD = '/proc/registry/HKEY_CURRENT_USER/Environment'
USERDOMAIN = ' removed'
SSH_TTY = '/dev/tty1'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
OS2LIBPATH = '%SystemRoot%\system32\os2\dll;'
TEMP = '/cygdrive/c/WINNT/TEMP'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
EASSHARE = 'C:\Servers\Sybase\Shared'
USERNAME = 'deploy'
JAGUAR_CLIENT_ROOT = 'C:\Servers\Sybase\EAServer'
TEXDOCVIEW_pdf = 'cygstart %s'
PROCESSOR_LEVEL = '15'
MAIL = '/var/spool/mail/deploy'
EQAENV = 'nzqa-uat1'
SYSTEMDRIVE = 'C:'
JAVA_HOME = 'C:\Servers\Sybase\Shared\j2sdk1.4.2_06\'
JAGUAR = 'C:\Servers\Sybase\EAServer'
TEXDOCVIEW_html = 'cygstart %s'
USERPROFILE = 'C:\Documents and Settings\deploy'
TZ = 'NZST-12NZDT-13,M10.1.0/2,M3.3.0/2'
PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = '\\removed'
LM_LICENSE_FILE = 'C:\Program Files\Sybase\SYSAM-1_0\licenses\license.dat'
PROCESSOR_ARCHITECTURE = 'x86'
SHLVL = '1'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = 'C:'
CSAPROFILE = 'removed'
COMSPEC = 'C:\WINNT\system32\cmd.exe'
LOGNAME = 'deploy'
TMP = '/cygdrive/c/WINNT/TEMP'
SYSTEMROOT = 'C:\WINNT'
PRINTER = 'RICOH Aficio 2045 PS'
CVS_RSH = '/bin/ssh'
PROCESSOR_REVISION = '0209'
SSH_CONNECTION = 'removed 41558 removed'
TEXDOCVIEW_ps = 'cygstart %s'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Program Files'
AVENGINE = 'C:\PROGRA~1\CA\SHARED~1\SCANEN~1'
NUMBER_OF_PROCESSORS = '4'
COMPUTERNAME = 'removed'
_ = '/usr/bin/cygcheck'
POSIXLY_CORRECT = '1'
3. 'ssh [EMAIL PROTECTED] cygcheck -sv':
USER = 'deploy'
PWD = '/home/deploy'
CYGWIN = 'ntsec'
HOME = '/home/deploy'
HOMEPATH = '\cygwin\home\deploy'
SHELL = '/bin/bash'
PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 2 Stepping 9, GenuineIntel'
WINDIR = 'C:\WINNT'
SSH_CLIENT = 'removed 41573 22'
USERDOMAIN = 'removed'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
TEMP = '/cygdrive/c/WINNT/TEMP'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
USERNAME = 'deploy'
PROCESSOR_LEVEL = '15'
MAIL = '/var/spool/mail/deploy'
SYSTEMDRIVE = 'C:'
USERPROFILE = 'C:\Documents and Settings\deploy'
LOGONSERVER = '\\removed'
PROCESSOR_ARCHITECTURE = 'x86'
SHLVL = '1'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = 'C:'
COMSPEC = 'C:\WINNT\system32\cmd.exe'
LOGNAME = 'deploy'
TMP = '/cygdrive/c/WINNT/TEMP'
SYSTEMROOT = 'C:\WINNT'
PROCESSOR_REVISION = 'removed'
SSH_CONNECTION = 'removed 41573 removed'
PROGRAMFILES = 'C:\Program Files'
NUMBER_OF_PROCESSORS = '4'
COMPUTERNAME = 'VULCAN'
_ = '/usr/bin/cygcheck'
POSIXLY_CORRECT = '1'
This is a new problem since upgrading Cygwin. Is there a bug that
needs to be fixed, or is this the correct way for Cygwin to function
and I need to do something new to make it work?
I tried the fix above as a separate script (with out the SSH_TTY
requirement of course), but that didn't help either.
Any help would be greatly appreciated.
Regards,
Paul
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
Re: terminal escape codes
Igor Peshansky wrote: On Fri, 5 May 2006, Andrew DeFaria wrote: Jeff Lange wrote: While that does work, It unfortunately isn't an acceptable solution for me. I really need to be running this from a plain text console. How is running rxvt not a plain text console?!? I use rxvt all the time. I don't like the Windows window as it's cut and paste semantics are horrible as well as it's resizing (in)ability. Windows has a notion of a console window. rxvt, xterm, ssh, and pretty much any other Cygwin program that doesn't allocate an explicit console window uses ptys to emulate console output. Some Windows programs cannot understand ptys, and thus don't work properly via ssh, or in rxvt. So the OP's need may be valid. I'm well aware of this and indeed this is about the only drawback I've ever seen with using rxvt instead of the console window. But there are not that many Windows only, I need a console and I can't deal with pty's applications that I run. Indeed many Windows users shy away from anything command line oriented. My question was more to affirm whether or not the OP was running into a pty problem or just didn't understand that he could use rxvt... -- If olive oil comes from olives, where does baby oil come from? -- 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 1.5.19-4 issues
Virgil Adumitroaie wrote: Hi, This is my second call to the cygwin developers. There is a problem with cygwin 1.5.19-4 (on windows xp sp2). Why is a second call required? The first was plenty good enough. And actually, revisiting the issue so quickly can actually work against your intentions. The qt designer (/usr/lib/qt3/bin/designer) crashes and its compilation from source fails. Sorry, I can't reproduce the crash of which you speak. I didn't attempt to compile the source. You might not care about matplotlib, but the gcc: fork: Resource temporarily unavailable which I get during compilation, indicates some other trouble. I believe you have gotten a pointer on this issue already so I won't comment further. Please let me know if you think otherwise, or if you don't get the same behavior. What changes made between 1.5.19-4 and 1.5.18-1 could produce these problems? Ah, now there's the $1,000,000 question. Obviously, if there was a known cause of this, there would already be a patch. So your efforts in tracking this down would be beneficial. You may want to start with a recent snapshot to see if it would help or hurt. Any recent snapshot is going to give you good insight into the capabilities of 1.5.20, which is pending release. Perhaps it would be best to read and follow the problem reporting guidelines outlined here: Problem reports: http://cygwin.com/problems.html This could unearth some important information that might help as well. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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/
