Re: Preremove/postinstall scripts fail with snapshot installed
On Feb 13 18:07, Ken Brown wrote: > On 2/13/2011 12:20 PM, Ken Brown wrote: > >Works for me on W7 64 bit with KB 2393802 installed. > > BTW, when I said that it works, I was talking about the original bug > that I reported about preremove/postinstall scripts. But I just now > tested removing an in-use directory, and I was surprised by what > happened. Maybe I just don't understand how this is supposed to > work. I have two bash shells open, with prompts $1 and $2. > > In shell 1: > > $1 mkdir /tmp/foo > $1 cd /tmp/foo > > In shell 2: > > $2 rmdir /tmp/foo > $2 ls /tmp/foo > ls: cannot access /tmp/foo: No such file or directory > > Back to shell 1: > > $1 ls > 0 [main] bash 2220 exception::handle: Exception: > STATUS_ACCESS_VIOLATION Yes, I encountered that at one point yesterday as well, and I have already a patch in the pipe, but didn't apply it so far because I want to do some tests first. What happens is this. When Cygwin forks, it actually performs some magic centered around a call to CreateProcess. Up to Windows 2003, the CreateProcess call just duplicates the parent's CWD handle and stores it as the CWD handle in the child. Starting with Windows Vista, the CWD handle is always a fresh one, created on process startup, even if the CWD of the child is the same as the CWD of the parent. The problem with this scenario is that in the child process the CWD handle creation fails, because the requested CWD doesn't exist anymore. The result is that an important pointer in the OS is NULL. My change from yesterday neglected this possibility, so it dereferences this pointer without checking it for NULL, which in turn crashes. Unfortunately it's not just adding a simple test, because Cygwin needs the pointer to figure out which version of the FAST_CWD structure is used. Anyway, I'll apply a patch later today. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: please update winsup/cygwin/config/i386/profile.h
On Feb 14 16:32, jojelino wrote: > i think you guys already fixed it on mingw. > http://sourceforge.net/tracker/index.php?func=detail&aid=1211187&group_id=2435&atid=102435 > but not for cygwin. Boy, that's kind of long ago... > it results sigsegv in cygwin for profiling regparm(x) function. > please execute > cp -f winsup/mingw/profile/profile.h winsup/cygwin/config/i386/profile.h Done. Thanks for the headsup. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: svn
On 2/14/2011 3:11 AM, Gary wrote: David Rothenberger wrote: If the files checked out in both directories are byte-for-byte identical (including binary files), I can't see how svn could be the culprit. If I can replace svn in the sequence with something else, for example tortoise, and everything then works, then Cygwin/svn *is* the culprit. Not necessarily ... it could be the underlying ssh, if you are using svn over ssh, and it could be BLODA interfering with cygwin ... Best wishes -- Eliot Moss -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
ssh problem
Hello, i have a problem with "ssh something'" command. it gives the error: "Bad owner or permissions on /home/rdonuk/.ssh/config". the "chmod 600 *" did not the solve problem. when i type ls -la in "/.ssh" getting these total 6 drw---+ 1 rdonuk Domain Users 0 Feb 14 15:20 . drw---+ 1 rdonuk Domain Users 4096 Feb 14 15:45 .. -rw--- 1 Administrators Domain Users 69 Feb 14 15:16 config -rw--- 1 Administrators Domain Users 20 Feb 14 15:17 myauth maybe there is problem with these "Administrators". I search for it many sites but cant solve. Thanks for your help. rdonuk -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: svn
On 2/14/2011 7:25 AM, Gary wrote: Eliot Moss wrote: On 2/14/2011 3:11 AM, Gary wrote: David Rothenberger wrote: If the files checked out in both directories are byte-for-byte identical (including binary files), I can't see how svn could be the culprit. If I can replace svn in the sequence with something else, for example tortoise, and everything then works, then Cygwin/svn *is* the culprit. Not necessarily ... it could be the underlying ssh, if you are using svn over ssh, and it could be BLODA interfering with cygwin ... And yet not doing it with another client? It's not really very likely, is it? In the fall of 2009 I was having a problem with rsync over ssh. Corinna and I got to the bottom of it: BLODA interfering with proper operation of socketpair. In the process, I found that if I disabled socketpair manually in the output of /.configure for building rsync, forcing it to use pipes instead, it worked fine. We have had occasional but persistent queries here about git over ssh, and you are reporting issues with svn and ssh. I am wondering if it has something to do with the sockets/pipes used to communicate between svn or git and the ssh subprocess. Best wishes -- EM -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: svn
On 2/14/2011 9:43 AM, Gary wrote: Eliot Moss wrote: We have had occasional but persistent queries here about git over ssh, and you are reporting issues with svn and ssh. I've never mentioned ssh in this context. Ah, sorry, then. I thought perhaps it was svn+ssh that was giving you trouble. Must be something else ... Best wishes -- Eliot -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Preremove/postinstall scripts fail with snapshot installed
On Feb 14 10:20, Corinna Vinschen wrote: > On Feb 13 18:07, Ken Brown wrote: > > On 2/13/2011 12:20 PM, Ken Brown wrote: > > $1 ls > > 0 [main] bash 2220 exception::handle: Exception: > > STATUS_ACCESS_VIOLATION > > Yes, I encountered that at one point yesterday as well, and I have > already a patch in the pipe, but didn't apply it so far because I > want to do some tests first. > [...] > Anyway, I'll apply a patch later today. Nope, not today. I stumbled over some other problems which require more debugging. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ssh problem
On 2/14/2011 9:27 AM, reşit dönük wrote: Hello, i have a problem with "ssh something'" command. it gives the error: "Bad owner or permissions on /home/rdonuk/.ssh/config". the "chmod 600 *" did not the solve problem. when i type ls -la in "/.ssh" getting these total 6 drw---+ 1 rdonuk Domain Users0 Feb 14 15:20 . drw---+ 1 rdonuk Domain Users 4096 Feb 14 15:45 .. -rw--- 1 Administrators Domain Users 69 Feb 14 15:16 config -rw--- 1 Administrators Domain Users 20 Feb 14 15:17 myauth maybe there is problem with these "Administrators". I search for it many sites but cant solve. I think you're looking in the wrong place for these files. It's complaining about '/home/rdonuk/.ssh/config', not '/.ssh/config'. Actually, you shouldn't need '/.ssh'. I'd recommend deleting this directory unless you're sure it's crucial to your environment. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: svn
On 2/14/2011 12:11 AM, Gary wrote: > David Rothenberger wrote: >> If the files checked out in both directories are byte-for-byte identical >> (including binary files), I can't see how svn could be the culprit. > > If I can replace svn in the sequence with something else, for example > tortoise, and everything then works, then Cygwin/svn *is* the culprit. If the bits are identical, then what else could be breaking your build? Perhaps the permissions on files, as I suggested in the same email you partially quoted above? I'm sorry, but I don't have anything else to offer here. You'll have to do some more investigation on your own about why the build is failing with the code checked out from Cygwin's svn. -- David Rothenberger daver...@acm.org Volunteer Cygwin Subversion maintainer. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ssh problem
Hello Thanks for your interest. i mean "/home/rdonuk/.ssh/config" when saying "/.ssh". And my problem was solved with Elliot's suggest. i did chown config file to rdonuk and chmod .ssh dir to 700. Now it s working Resit 2011/2/14 Larry Hall (Cygwin) : > On 2/14/2011 9:27 AM, reşit dönük wrote: >> >> Hello, >> >> i have a problem with "ssh something'" command. it gives the error: >> "Bad owner or permissions on /home/rdonuk/.ssh/config". the "chmod 600 >> *" did not the solve problem. >> when i type ls -la in "/.ssh" getting these >> >> total 6 >> drw---+ 1 rdonuk Domain Users 0 Feb 14 15:20 . >> drw---+ 1 rdonuk Domain Users 4096 Feb 14 15:45 .. >> -rw--- 1 Administrators Domain Users 69 Feb 14 15:16 config >> -rw--- 1 Administrators Domain Users 20 Feb 14 15:17 myauth >> >> maybe there is problem with these "Administrators". I search for it >> many sites but cant solve. > > I think you're looking in the wrong place for these files. It's > complaining about '/home/rdonuk/.ssh/config', not '/.ssh/config'. Actually, > you shouldn't need '/.ssh'. I'd recommend deleting this directory unless > you're sure it's crucial to your environment. > > -- > Larry > > _ > > A: Yes. >> >> Q: Are you sure? >>> >>> A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Please upload: mined-2000.16-0
Am 13.02.2011 23:25, schrieb Karl M: Date: Sun, 13 Feb 2011 23:18:18 +0100 From: Thomas Subject: Re: Please upload: mined-2000.16-0 The reason is that, at least on Windows 7, there is no key called HKEY_CURRENT_USER\Software\Classes\SystemFileAssociations. The result is that a user of Windows 7 gets a postinstall warning from setup.exe because the mined postinstall script returns a non-zero exit code. Corinna Hi, thanks for the notice. Actually I'm aware that there is this postinstall return problem also in Windows XP and I've fixed it but the code base isn't quite ready yet for the next release - can it still wait for a short while? On the other hand, if the key doesn't exist because the mechanism has changed in Windows 7, I'm not sure what to do because I don't have W7 myself for testing - any advice by someone? Just some other key name perhaps? Why is mined by default messing with this? Isn't this something that the user should run if he/she wants to alter file associations/context menu stuff? I once discussed this with Andy and felt encouraged to do so - after all, non-expert users will not normally make such an entry because there is no tool to do it easily (I think). But I'll reconsider and maybe confine it to the stand-alone package. Whatever update, please allow for a few days... Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Please upload: mined-2000.16-0
> Date: Mon, 14 Feb 2011 21:20:08 +0100 > From: Thomas > Subject: Re: Please upload: mined-2000.16-0 > > Am 13.02.2011 23:25, schrieb Karl M: > > > > > > > >> Date: Sun, 13 Feb 2011 23:18:18 +0100 > >> From: Thomas > >> Subject: Re: Please upload: mined-2000.16-0 > >>> The reason is that, at least on Windows 7, there is no key called > >>> HKEY_CURRENT_USER\Software\Classes\SystemFileAssociations. > >>> > >>> The result is that a user of Windows 7 gets a postinstall warning from > >>> setup.exe because the mined postinstall script returns a non-zero exit > >>> code. > >>> > >>> > >>> Corinna > >> Hi, thanks for the notice. > >> Actually I'm aware that there is this postinstall return problem also in > >> Windows XP and I've fixed it but the code base isn't quite ready yet for > >> the next release - can it still wait for a short while? > >> On the other hand, if the key doesn't exist because the mechanism has > >> changed in Windows 7, I'm not sure what to do because I don't have W7 > >> myself for testing - any advice by someone? Just some other key name > >> perhaps? > > Why is mined by default messing with this? Isn't this something that the > > user should run if he/she wants to alter file associations/context menu > > stuff? > I once discussed this with Andy and felt encouraged to do so - after > all, non-expert users will not normally make such an entry because there > is no tool to do it easily (I think). > But I'll reconsider and maybe confine it to the stand-alone package. > Thanks for considering it. I think that a script that the used could run after installation would be fine. I don't use it, so it does not impact me directly. But I would not have expected that installing an editor in Cygwin would change windows file associations. I use vi in Cygwin, but would not want that to change my file associations. Thanks, ...Karl -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: building a cross-compiler for Linux/OSX
Sorry for replying so late. Thus spoke Yaakov (Cygwin/X): > On Mon, 2011-02-07 at 10:50 +0100, Fabiano Sidler wrote: > > I'm trying to build a cross-compiler under Linux and MacOSX using this > > script: http://sourceware.org/ml/cygwin/2010-08/txt00010.txt > > I get the same error on Linux and MacOSX after the make of line 340: > > Cygwin normally builds with -Werror but there are a few warnings > generated by GCC 4.5 which haven't been fixed yet in the code. Remove > -Werror from $top_builddir/i686-pc-cygwin/winsup/cygwin/Makefile and the > rest of the build should precede without any further difficulties. Not without any further difficulties, but at least with a different error: === snip === [...] /opt/devel/cygwin/src/cygwin-1.7.6-1/winsup/utils/mingw i686-pc-cygwin-gcc -c -D __CRTDLL__ -U__MSVCRT__ -g -O2 -Wno-error -I/opt/devel/cygwin/src/cygwin-1.7.6-1 /winsup/mingw/include -I/opt/devel/cygwin/src/cygwin-1.7.6-1/winsup/mingw/../inc lude -nostdinc -iwithprefixbefore include -I /opt/devel/cygwin/src/cygwin-1.7.6- 1/winsup/mingw/../w32api/include /opt/devel/cygwin/src/cygwin-1.7.6-1/winsup/min gw/crt1.c -o crt1.o /opt/devel/cygwin/src/cygwin-1.7.6-1/winsup/utils/mingw: couldn't find i686-pc-m ingw32 directory make[3]: *** [crt1.o] Error 1 make[3]: Leaving directory `/opt/devel/cygwin/build/cygwin/i686-pc-cygwin/winsup /mingw' make[2]: *** [mingw] Error 1 make[2]: Leaving directory `/opt/devel/cygwin/build/cygwin/i686-pc-cygwin/winsup ' make[1]: *** [all-target-winsup] Error 2 make[1]: Leaving directory `/opt/devel/cygwin/build/cygwin' make: *** [all] Error 2 === snap === Again, the same error on Linux and OSX. Thank you for helping, btw! ;) Greetings, Fabiano pgp6wZlSICunZ.pgp Description: PGP signature
RE: Please upload: mined-2000.16-0
Thanks for the response. I have also tried it on windows server 2003 with service pack2. If you run the setup.exe directly without saving it first, then it gives the error. Later I saved the file on the server first and running setup.exe from there did not issue the same warning. May be it is fixed for 2003, I have not tried on windows XP and windows 7 ye. However, running directly issues warning on all platforms. Regards, -Original Message- Sent: Monday, February 14, 2011 2:20 PM Subject: Re: Please upload: mined-2000.16-0 Am 13.02.2011 23:25, schrieb Karl M: > > > >> Date: Sun, 13 Feb 2011 23:18:18 +0100 >> From: Thomas >> Subject: Re: Please upload: mined-2000.16-0 >>> The reason is that, at least on Windows 7, there is no key called >>> HKEY_CURRENT_USER\Software\Classes\SystemFileAssociations. >>> >>> The result is that a user of Windows 7 gets a postinstall warning from >>> setup.exe because the mined postinstall script returns a non-zero exit >>> code. >>> >>> >>> Corinna >> Hi, thanks for the notice. >> Actually I'm aware that there is this postinstall return problem also in >> Windows XP and I've fixed it but the code base isn't quite ready yet for >> the next release - can it still wait for a short while? >> On the other hand, if the key doesn't exist because the mechanism has >> changed in Windows 7, I'm not sure what to do because I don't have W7 >> myself for testing - any advice by someone? Just some other key name >> perhaps? > Why is mined by default messing with this? Isn't this something that the user should run if he/she wants to alter file associations/context menu stuff? I once discussed this with Andy and felt encouraged to do so - after all, non-expert users will not normally make such an entry because there is no tool to do it easily (I think). But I'll reconsider and maybe confine it to the stand-alone package. Whatever update, please allow for a few days... Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
The tree command
It would be really useful to have a tree command available from the cygwin shell. has anyone managed to find a working tree command yet? We could really do with this in the cygwin archive. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
problem finding 'i686-pc-mingw32' directory when building cygwin from source
I was interested in building the cygwin system from source because I wanted to make some customizations. I followed the instructions in the FAQ for building cygwin: http://cygwin.com/faq/faq.programming.html#faq.programming.building-cygwin Well into the build, I see the following error which stops the build: "couldn't find i686-pc-mingw32 directory" I searched all over the mailing lists and found brief discussion of this with no solution. The same error occurs if I build from a cvs checked out current, a tarred snapshot, or the cygwin-1.7.7-1 source package. I am obviously missing something very basic and probably very simple. below attached is: 1) tail end of build log 2) a listing of the brief prior discussuion (without an solution that I could see) 3) cygcheck -sr output Any help is appreciated! Thanks, John Refling == 1) tail end of build log (there are some other errors about "cannot remove path..." before it failed make[4]: Leaving directory `/usr/build/i686-pc-cygwin/winsup/cygserver' Making version.o and winver.o 2011-02-14 10:55 Version 1.7.7 g++ -L/usr/build/i686-pc-cygwin/winsup -L/usr/build/i686-pc-cygwin/winsup/cygwin -L/usr/build/i686-pc-cygwin/winsup/w32api/lib -isystem /usr/src/cygwin-1.7.7-1/winsup/include -isystem /usr/src/cygwin-1.7.7-1/winsup/cygwin/include -isystem /usr/src/cygwin-1.7.7-1/winsup/w32api/include -B/usr/build/i686-pc-cygwin/newlib/ -isystem /usr/build/i686-pc-cygwin/newlib/targ-include -isystem /usr/src/cygwin-1.7.7-1/newlib/libc/include-g -O2 -MMD -Werror -fmerge-constants -ftracer -mno-use-libstdc-wrappers -Wl,--gc-sections -nostdlib -Wl,-T/usr/src/cygwin-1.7.7-1/winsup/cygwin/cygwin.sc \ -Wl,--heap=0 -Wl,--out-implib,cygdll.a -shared -o cygwin0.dll \ -e _dll_entry@12 cygwin.def assert.o autoload.o bsdlib.o ctype.o cxx.o cygheap.o cygthread.o cygtls.o cygxdr.o dcrt0.o debug.o devices.o dir.o dlfcn.o dll_init.o dtable.o environ.o errno.o exceptions.o exec.o external.o fcntl.o fhandler.o fhandler_clipboard.o fhandler_console.o fhandler_disk_file.o fhandler_dsp.o fhandler_fifo.o fhandler_floppy.o fhandler_mailslot.o fhandler_mem.o fhandler_netdrive.o fhandler_nodevice.o fhandler_proc.o fhandler_process.o fhandler_procnet.o fhandler_random.o fhandler_raw.o fhandler_registry.o fhandler_serial.o fhandler_socket.o fhandler_tape.o fhandler_termios.o fhandler_tty.o fhandler_virtual.o fhandler_windows.o fhandler_zero.o flock.o fnmatch.o fork.o fts.o ftw.o getopt.o glob.o glob_pattern_p.o globals.o grp.o heap.o hookapi.o inet_addr.o inet_network.o init.o ioctl.o ipc.o kernel32.o libstdcxx_wrapper.o localtime.o lsearch.o malloc_wrapper.o minires-os-if.o minires.o miscfuncs.o mktemp.o mmap.o msg.o mount.o net.o netdb.o nfs.o nftw.o nlsfuncs.o ntea.o passwd.o path.o pinfo.o pipe.o poll.o posix_ipc.o pseudo-reloc.o pthread.o random.o regcomp.o regerror.o regexec.o regfree.o registry.o resource.o rexec.o rcmd.o scandir.o sched.o sec_acl.o sec_auth.o sec_helper.o security.o select.o sem.o setlsapwd.o shared.o shm.o sigfe.o signal.o sigproc.o smallprint.o spawn.o strace.o strfmon.o strfuncs.o strptime.o strsep.o strsig.o sync.o syscalls.o sysconf.o syslog.o termios.o thread.o timer.o times.o tls_pbuf.o tty.o uinfo.o uname.o wait.o wincap.o window.o winf.o xsique.o malloc.o version.o winver.o \ /usr/build/i686-pc-cygwin/winsup/cygserver/libcygserver.a /usr/build/i686-pc-cygwin/newlib/libm/libm.a /usr/build/i686-pc-cygwin/newlib/libc/libc.a \ -lgcc /usr/build/i686-pc-cygwin/winsup/w32api/lib/libadvapi32.a /usr/build/i686-pc-cygwin/winsup/w32api/lib/libkernel32.a /usr/build/i686-pc-cygwin/winsup/w32api/lib/libntdll.a -Wl,-Map,cygwin.map Creating library file: cygdll.a + objcopy -R .gnu_debuglink_overlay --only-keep-debug cygwin0.dll cygwin1.dbg + objcopy -g --add-gnu-debuglink=cygwin1.dbg cygwin0.dll + objcopy -R .gnu_debuglink_overlay --set-section-flag .gnu_debuglink=contents,readonly,debug,noload --change-section-address .gnu_debuglink=0x61236000 cygwin0.dll /usr/src/cygwin-1.7.7-1/winsup/cygwin/mkimport --ar=ar --as=as --nm=nm --objcopy=objcopy --replace=acl=_acl32 --replace=aclcheck=_aclcheck32 --replace=aclfrommode=_aclfrommode32 --replace=aclfrompbits=_aclfrompbits32 --replace=aclfromtext=_aclfromtext32 --replace=aclsort=_aclsort32 --replace=acltomode=_acltomode32 --replace=acltopbits=_acltopbits32 --replace=acltotext=_acltotext32 --replace=chown=_chown32 --replace=facl=_facl32 --replace=fchown=_fchown32 --replace=fcntl=_fcntl64 --replace=fdopen=_fdopen64 --replace=fgetpos=_fgetpos64 --replace=fopen=_fopen64 --replace=freopen=_freopen64 --replace=fseeko=_fseeko64 --replace=fsetpos=_fsetpos64 --replace=fstat=_fstat64 --replace=ftello=_ftello64 --replace=ftruncate=_ftruncate64 --replace=getegid=_getegid32 --replace=geteuid=_geteuid32 --replace=getgid=_getgid32 --replace=getgrent=_getgrent32 --replace=getgrgid=_getgrgid32 --replace=getgrnam=_getgrnam32 -
Re: The tree command
On Mon, Feb 14, 2011 at 10:23 PM, Mark Hobley wrote: > It would be really useful to have a tree command available from the > cygwin shell. has anyone managed to find a working tree command yet? We could > really do with this in the cygwin archive. > > > -- http://www.centerkey.com/tree/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
m4: cannot open `gcc': No such file or directory
I'm trying to compile the GNU multiple precision arithmetic library from source in cygwin and after the command m4 gcc -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_add_n add_n.asm >tmp-add_n.s I get an error saying m4: cannot open `gcc': No such file or directory However typing the command gcc into bash reveals the output "gcc: no input files" How do I get the m4 macro processor to see gcc? -- View this message in context: http://old.nabble.com/m4%3A-cannot-open-%60gcc%27%3A-No-such-file-or-directory-tp30927631p30927631.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Please add 'AVG Internet Security 2011' to the BLODA list (and cygport also :-) ).
Eric Blake wrote: On 02/06/2011 09:40 PM, L Anderson wrote: In regards to the aforementioned while loop in 'conftest.c'--the logic of it being run for every invocation of a 'coreutils' build escapes me. I can see running it once per OS, outside of the build process, to determine if the given OS does the right thing; after that, shouldn't it just be a case of checking if the OS being used has been tested and deemed to behave properly? Yes, this particular configure test takes a long time, even without virus scanning, on WinXP (where Microsoft has an O(n^2) implementation); it's faster on newer Windows (where Microsoft fixed things to be O(n)). You can pre-seed a config.site cache to skip the test by using a known outcome result (in fact, I do just that when building coreutils): $ cat>> /usr/config.site<<\EOF # configure gets the right answer, but only after hammering the system gl_cv_func_getcwd_path_max=yes EOF Thanks for the hint--it allowed me to by-pass the test. However, for the record, based on 'coreutils-8.10-1--configure[3295,3296]', I think you meant: > $ cat>> /usr/share/config.site<<\EOF > # configure gets the right answer, but only after hammering the system > gl_cv_func_getcwd_path_max=yes > EOF xor > $ cat>> /usr/etc/config.site<<\EOF > # configure gets the right answer, but only after hammering the system > gl_cv_func_getcwd_path_max=yes > EOF Correct? I used the latter and it did the trick. Regards, LA -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Coreutils' Build Fails After Linking rm.exe
I'm trying to build coreutils and I've run into a problem that has me puzzled. I'd greatly appreciate any ideas or pointers on what might be causing the problem and steps I could take to figure it out. The problem is repeatable, stopping at the exact same place. I'm running 'XpProSp3', 'cygcheck -c' shows all OK. 1st--I used setup to install 'coreutils-8.10-1' source and placed the files in '/usr/src/coreutils-8.10-1' 2nd--From that directory, I did 'cygport coreutils-8.10-1 prep', which completed successfully. 3rd--I ran 'cygport coreutils-8.10-1 compile', which appeared to work ok until it exited with a "make error" as shown by the following last few lines of the output: ... CCLD pwd.exe CCLD readlink.exe CCLD rm.exe CCLD rmdir.exe <<<---up to and including rmdir.exe have been linked ./rm: ./rm: cannot execute binary file make[3]: *** [runcon.exe] Error 126 <<<--runcon.exe and on, not linked make[3]: *** Waiting for unfinished jobs ./rm: ./rm: cannot execute binary file make[3]: *** [seq.exe] Error 126 make[3]: Leaving directory `/usr/src/coreutils-8.10-1/coreutils-8.10-1/build/src ' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/coreutils-8.10-1/coreutils-8.10-1/build/src ' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/coreutils-8.10-1/coreutils-8.10-1/build' make: *** [all] Error 2 *** ERROR: make failed The above is output from 'make', chewing on the following 'makefile' lines: ... pwd$(EXEEXT): $(pwd_OBJECTS) $(pwd_DEPENDENCIES) @rm -f pwd$(EXEEXT) $(AM_V_CCLD)$(LINK) $(pwd_OBJECTS) $(pwd_LDADD) $(LIBS) readlink$(EXEEXT): $(readlink_OBJECTS) $(readlink_DEPENDENCIES) @rm -f readlink$(EXEEXT) $(AM_V_CCLD)$(LINK) $(readlink_OBJECTS) $(readlink_LDADD) $(LIBS) rm$(EXEEXT): $(rm_OBJECTS) $(rm_DEPENDENCIES) @rm -f rm$(EXEEXT) $(AM_V_CCLD)$(LINK) $(rm_OBJECTS) $(rm_LDADD) $(LIBS) rmdir$(EXEEXT): $(rmdir_OBJECTS) $(rmdir_DEPENDENCIES) @rm -f rmdir$(EXEEXT) $(AM_V_CCLD)$(LINK) $(rmdir_OBJECTS) $(rmdir_LDADD) $(LIBS) runcon$(EXEEXT): $(runcon_OBJECTS) $(runcon_DEPENDENCIES) @rm -f runcon$(EXEEXT) <<<-error occurs at this point<<-- $(AM_V_CCLD)$(LINK) $(runcon_OBJECTS) $(runcon_LDADD) $(LIBS) seq$(EXEEXT): $(seq_OBJECTS) $(seq_DEPENDENCIES) @rm -f seq$(EXEEXT) $(AM_V_CCLD)$(LINK) $(seq_OBJECTS) $(seq_LDADD) $(LIBS) ... The problem is related to 'rm.exe' being created in '/build/src'. Up until that point, the 'rm.exe' in the recipe lines is executed out of '/bin'. So what causes 'make' to hiccup, when another 'rm.exe' is created in the build directory? Is this a problem related to timing, path, permissions, configuration, or? Any insight in to what might be causing this would be greatly appreciated. Thanks, Lowell Anderson -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
