cygrunsrv: Error starting a service: QueryServiceStatus: Win32 error 1062:
Hi, I am getting the following on running query on cron service: - $ cygrunsrv.exe -Q cron Service cron exists Type: Own Process Current State : Stopped Controls Accepted : [EMAIL PROTECTED] ~ $ cygrunsrv.exe -S cron cygrunsrv: Error starting a service: QueryServiceStatus: Win32 error 1062: The service has not been started. - The file /var/cron/cron.log is empty. Following is the complete process I tried to install and run cron. - $ cygrunsrv.exe -E cron [EMAIL PROTECTED] ~ $ cygrunsrv.exe -R cron [EMAIL PROTECTED] ~ $ cygrunsrv.exe -I cron -p /usr/sbin/cron.exe [EMAIL PROTECTED] ~ $ cygrunsrv.exe -S cron cygrunsrv: Error starting a service: QueryServiceStatus: Win32 error 1062: The service has not been started. [EMAIL PROTECTED] ~ $ cygrunsrv.exe -Q cron Service cron exists Type: Own Process Current State : Stopped Controls Accepted : - Please help if you have an idea as to why the cron service is not starting. Here is what I get in the application log on trying to start cron service: Event Type: Error Event Source: cron Event Category: None Event ID: 0 Date: 12/22/2003 Time: 12:40:07 PM User: NT AUTHORITY\SYSTEM Computer: CHANDRESH Description: The description for Event ID ( 0 ) in Source ( cron ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: cron : PID 1580 : starting service `cron' failed: execv: 0, No error. --- Thanks, Chandresh -- 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/
I got a message "Bad, you are not root." from Cygwin
Hi, Just now I tried to install the arm-elf-tools-cygwin. The system just gave an information "Bad, You are not root". Is it a bug or anything else? Regards Hu Ying -- 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/
Why 2 DLL names?
Greetings, Using Cygwin 1.5.5-1, I am porting a Unix shared library to Windows. After making and linking the library with libtool, two DLLs were created: libxx.dll.a cygxx-1.dll I guess I was only expecting: libxx.dll. Why were the 2 names generated and why the "cyg" prefix on one of them? Also, which one should I use? Thank you for you patience with me as I learn the cygwin environment. Roy -- 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/
Can't build gcc [tree-ssa] 20031222 on cygwin: libmudflap/mf-hooks2.c:1618 syntax error for ipc...
Windows XP/Pro SP1 cygwin P4 system with these packages: binutils 20030901-1 2.14.90 20030901 bison20030307-1 1.875b cygwin 1.5.5-1 dejagnu 20021217-2 1.4.2.x gawk 3.1.3-4 gcc 3.3.1-3 w32api 2.4-1 LAST_UPDATED: Mon Dec 22 11:05:16 GMT 2003 configure pentium4-cygwin --prefix=/usr/local/gcc-binutils --enable-shared --enable-threads=posix --with-system-zlib --enable-libgcj /usr/local/src/gcc-binutils/branch/objdir/gcc/xgcc -B/usr/local/src/gcc-binutils/branch/objdir/gcc/ -B/usr/local/gcc-binutils/pentium4-cygwin/bin/ -B/usr/local/gcc-binutils/pentium4-cygwin/lib/ -isystem /usr/local/gcc-binutils/pentium4-cygwin/include -isystem /usr/local/gcc-binutils/pentium4-cygwin/sys-include -DHAVE_CONFIG_H -I. -I/usr/local/src/branch/gcc/libmudflap -I. -O2 -g -O2 -Wall -O2 -g -O2 -DWRAP_semop -c /usr/local/src/branch/gcc/libmudflap/mf-hooks2.c -o semop-hook.o In file included from /usr/local/src/branch/gcc/libmudflap/mf-hooks2.c:1618: /usr/include/sys/ipc.h:59: error: syntax error before "ushort" /usr/include/sys/ipc.h:61: error: syntax error before "cuid" /usr/include/sys/ipc.h:62: error: syntax error before "cgid" /usr/include/sys/ipc.h:63: error: syntax error before "mode" /usr/include/sys/ipc.h:64: error: syntax error before "seq" In file included from /usr/local/src/branch/gcc/libmudflap/mf-hooks2.c:1619: /usr/include/sys/sem.h:59: error: field `sem_perm' has incomplete type /usr/include/sys/sem.h:64: error: syntax error before "ushort" /usr/include/sys/sem.h:69: error: syntax error before "ushort" /usr/include/sys/sem.h:72: error: syntax error before '}' token /usr/local/src/branch/gcc/libmudflap/mf-hooks2.c: In function `__mfwrap_semop': /usr/local/src/branch/gcc/libmudflap/mf-hooks2.c:1623: error: dereferencing pointer to incomplete type /usr/local/src/branch/gcc/libmudflap/mf-hooks2.c:1623: error: dereferencing pointer to incomplete type /usr/local/src/branch/gcc/libmudflap/mf-hooks2.c:1623: error: dereferencing pointer to incomplete type /usr/local/src/branch/gcc/libmudflap/mf-hooks2.c:1623: error: dereferencing pointer to incomplete type /usr/local/src/branch/gcc/libmudflap/mf-hooks2.c:1623: error: dereferencing pointer to incomplete type /usr/local/src/branch/gcc/libmudflap/mf-hooks2.c:1623: error: dereferencing pointer to incomplete type make[4]: *** [semop-hook.lo] Error 1 make[4]: Leaving directory `/usr/local/src/gcc-binutils/branch/objdir/pentium4-cygwin/libmudflap' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/local/src/gcc-binutils/branch/objdir/pentium4-cygwin/libmudflap' make[2]: *** [all-recursive-am] Error 2 make[2]: Leaving directory `/usr/local/src/gcc-binutils/branch/objdir/pentium4-cygwin/libmudflap' make[1]: *** [all-target-libmudflap] Error 2 make[1]: Leaving directory `/usr/local/src/gcc-binutils/branch/objdir' make: *** [bootstrap-lean] Error 2 Any ideas? 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/
RE: Why 2 DLL names?
> > Greetings, > > Using Cygwin 1.5.5-1, I am porting a Unix shared library to Windows. > After making and linking the library with libtool, two DLLs were > created: > > libxx.dll.a > cygxx-1.dll > > I guess I was only expecting: libxx.dll. > > Why were the 2 names generated and why the "cyg" prefix on one of > them? Also, which one should I use? The first is not a dll - its an import library(I think?) Cyg prefix is chosen to clearly delimit mingw dll's from cygwin dll's - since, for example, zlib comes in both cygwin and mingw versions, and naming them the same would cause conflicts. -- 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: Why 2 DLL names?
Roy Clemmons wrote: Greetings, Using Cygwin 1.5.5-1, I am porting a Unix shared library to Windows. After making and linking the library with libtool, two DLLs were created: libxx.dll.a cygxx-1.dll libxx.dll.a is the import library cygxx-1.dll is the dll Read http://cygwin.com/cygwin-ug-net/dll.html for a more complete explanation. I guess I was only expecting: libxx.dll. Why were the 2 names generated and why the "cyg" prefix on one of them? Also, which one should I use? Thank you for you patience with me as I learn the cygwin environment. Roy -- 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/ -- 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: I got a message "Bad, you are not root." from cygwin
On Mon, Dec 22, 2003 at 06:30:44PM +0800, Hu Ying wrote: >Just now I tried to install the arm-elf-tools-cygwin. The system just >gave an information "Bad, You are not root". Is it a bug or anything >else? Why are you asking us? Why not ask the people who provided you with arm-elf-tools-cygwin? -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.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: Here's a revised SSMTP
Hi Jeff, while I appreciate the work you've put into this project, I don't think it's the way to go to stick with the current version of ssmtp and only change it that much for Cygwin. The mainline version of ssmtp is currently 2.60.4 (see ftp://ftp.freebsd.org/pub/FreeBSD/distfiles) and I think it would be a good idea trying to keep in sync with mainline and to submit patches back to mainline (something I myself haven't done, admittedly). Since you seem to be way more interested in using and maintaining ssmtp, I'm offering to step back as maintainer so that you can step forward and take over. I guess that would be in everyone's interest. Thanks, Corinna On Dec 20 20:19, Jeff wrote: > Looks like SSMTP has been getting some attention lately. It's > definitely the thing to use, when you don't want a full-blown MTA. I've > done some significant rewriting, so I'm attaching a tar.bz2 because > it's actually smaller than a patch would be. Here're some of the > changes I've made: > > If your mail server requires authenticatiion (like mine), you can now > put your userid and password in the config file. Of course, I'm sure > that no one wants such info in the clear in a text file, so I wrote a > little utility to encode it, and incorporated that utility into the > config file generator script. You can still put your userid and > password on the command line, if you wish. > > Added a bit of code to explicitly handle line terminators in the > input stream, as per an earlier thread. Shouldn't matter now what mount > strategy you're using, how your MUA hands off an outgoing message to > SSMTP, etc. > > Implemented dynamic memory allocation for the headers and recipient > list buffers. These can now be any size up to available memory. > > Swatted a few bugs (eg. a malloc() without a free()), merged and > simplified a few functions, reorganized the code so you can read it and > actually figure out what's going on, and pretty much brought everything > up to ANSI C. > > I think there were some other things but it's been a while since I last > worked on it. > > TO DO: > > I caught the comma at the end of a string of recipients thing that > Robert Schneck mentioned (because my old MUA does that), but not where > it clips short the list. I'll get around to looking at his fix and > sticking it in, if he doesn't do it first. > > I wasn't sure and I've been putting it off, but tonight I checked: > SSMTP doesn't strip out the Bcc: header before sending the message. > Chances are that your mail server doesn't do it either, which means > that it's not Blind. > > Anyway, it seems pretty stable to me, but I'm not sure I've checked out > everything. I'm interested to hear what people think of it. And I'll > leave it to the maintainer to decide if it gets a new version number. > :) > > Jeff > -- > 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/ -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- 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: bash.exe: *** Couldn't reserve space for cygwin's heap
Kimberlie, On Thu, Dec 18, 2003 at 07:23:36PM -0500, Kimberlie S wrote: > I tried using rebase (suggested by Jason Tishler in his email dated > Tue, 02 Dec 2003) but just get an error message saying that bash is > not rebaseable. Assuming this is a rebase problem, then you need to rebase your system (i.e., "all" of your Cygwin DLLs) not bash. > Any other suggestions? Use rebaseall instead of rebase *and* read the rebase README: http://www.tishler.net/jason/software/rebase/rebase-2.2.README Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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: tcltk8.4.1 Bug Report: Incomplete usr/lib/tclConfig.sh
Patrick, On Fri, Dec 19, 2003 at 04:05:20AM -0800, Patrick Samson wrote: > Postgresql's configure --with-tcl uses > /lib/tclConfig.sh to know how to link with TCL. But in > package tcltk version 20030901-1, usr/lib/tclConfig.sh > contains: > TCL_LIB_SPEC='' > so something required by Postgres isn't found. > > Please change to: > TCL_LIB_SPEC='-L/usr/lib -ltcl84' Unfortunately, there are more issues than just the above: http://archives.postgresql.org/pgsql-cygwin/2003-11/msg00074.php Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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/
Unable to compile Cygwin
Hi everybody! I've been using Cygwin for a while and am really happy with it. But recently my paranoid boss has asked me to prove him that there was no security problem with using Cygwin on our secure network. The first step towards this goal is to recompile Cygwin so that we can be sure the code we execute corresponds to the sources. I know, I know, it's silly, but hey, I'm not the boss, so... I've downloaded the sources via CVS on my Win2k machine and tried to compile it with Cygwin, following the steps described in the FAQ "How do I rebuild the tools on my NT box?" Configure works well. Make works like a, charm until I get this (extract for Make.log): = Making version.o and winver.o Version 1.5.6 c++ -L/cygdrive/c/Cyg/obj/i686-pc-cygwin/winsup -L/cygdrive/c/Cyg/obj/i686-p c-cygwin/winsup/cygwin -L/cygdrive/c/Cyg/obj/i686-pc-cygwin/winsup/w32api/li b -isystem /cygdrive/c/Cyg/src/winsup/include -isystem /cygdrive/c/Cyg/src/winsup/cygwin/include -isystem /cygdrive/c/Cyg/src/winsup/w32api/include -B/cygdrive/c/Cyg/obj/i686-pc-cygw in/newlib/ -isystem /cygdrive/c/Cyg/obj/i686-pc-cygwin/newlib/targ-include -isystem /cygdrive/c/Cyg/src/newlib/libc/include -g -O2 -nostdlib -Wl,-T../../../../s rc/winsup/cygwin/cygwin.sc -Wl,--out-implib,cygdll.a -shared -o cygwin0.dll \ -e [EMAIL PROTECTED] cygwin.def assert.o autoload.o bsdlib.o cxx.o cygheap.o cygthread.o dcrt0.o debug.o delqueue.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_mem.o fhandler_nodevice.o fhandler_proc.o fhandler_process.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 getopt.o glob.o grp.o heap.o init.o ioctl.o ipc.o iruserok.o localtime.o malloc_wrapper.o miscfuncs.o mmap.o msg.o net.o netdb.o ntea.o passwd.o path.o pinfo.o pipe.o poll.o pthread.o regcomp.o regerror.o regexec.o regfree.o registry.o resource.o scandir.o sched.o sec_acl.o sec_helper.o security.o select.o sem.o shared.o shm.o sigfe.o signal.o sigproc.o smallprint.o spawn.o strace.o strsep.o sync.o syscalls.o sysconf.o syslog.o termios.o thread.o times.o tty.o uinfo.o uname.o v8_regexp.o v8_regerror.o v8_regsub.o wait.o wincap.o window.o setjmp.o /cygdrive/c/Cyg/obj/i686-pc-cygwin/libiberty/random.o /cygdrive/c/Cyg/obj/i686-pc-cygwin/libiberty/strsignal.o malloc.o version.o winver.o \ /cygdrive/c/Cyg/obj/i686-pc-cygwin/winsup/cygserver/libcygserver.a /cygdrive/c/Cyg/obj/i686-pc-cygwin/newlib/libm/libm.a /cygdrive/c/Cyg/obj/i686-pc-cygwin/newlib/libc/libc.a \ -lgcc /cygdrive/c/Cyg/obj/i686-pc-cygwin/winsup/w32api/lib/libkernel32.a collect2: ld terminated with signal 11 [Segmentation fault], core dumped /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld: cygwin.def:4: parse error make[2]: *** [cygwin0.dll] Error 1 make[2]: Leaving directory `/cygdrive/c/Cyg/obj/i686-pc-cygwin/winsup/cygwin' make[1]: *** [cygwin] Error 1 make[1]: Leaving directory `/cygdrive/c/Cyg/obj/i686-pc-cygwin/winsup' make: *** [all-target-winsup] Error 2 = Anybody can help me go further? Thanks -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Why 2 DLL names?
libxx.dll.a is the import library cygxx-1.dll is the dll Read http://cygwin.com/cygwin-ug-net/dll.html for a more complete explanation.Thanks for the reply. Unless I missed it, I still don't understand why the shared lib was created a "cyg" prefix and a -1 suffix. But, be that as it may, can I rename the dll to be the correct name?Roy -- 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: How to set breakpoints before mainCRTStartup?
Dalibor Topic wrote: Dalibor Topic wrote: Hi all, in my attempts to fix an ugly bug in kaffe on Cygwin, the bug I'm trying to squish turned out to be triggered by something that happens *before* main is called. Since I'd like to know what modifes that opcode, I hope to be able to set a breakpoint in gdb on the code that is executed before main in Cygwin. Try running gdb with the "-command=" option and put a line in it like "br myfunc". I have not tried this with cygwin gdb but it works for me on several other OS's i use. Any idea how to do that, i.e. where to put the breakpoint? Are there some docs on what happends before main() on cygwin that I could look up for reference while trying to hunt down this bug? It turns out that the bug happens even before mainCRTStartup. Has anyone seen something like that before? I have seen something like this before. If it is a C++ app then it may be a constructor in a statically or golbally declared object instance. The compiler should generate code to call all the global object constructors for initializing these objects *before* calling main(). Hope this helps. Steve. -- 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: rebaseall breaks zsh?
Rafael, Sorry for the delay... On Wed, Dec 10, 2003 at 01:26:07AM -0800, Rafael Kitover wrote: > I noticed that the rebaseall scripts rebases /usr/bin/libzsh-4.0.4.dll > and the modules in /usr/lib/zsh/4.1.1/zsh/*.dll, and that this breaks > zsh. Rebasing libzsh stops zsh from starting, and rebasing the modules > stops them from loading. > > If this is the case, and not just something messed up on my system, > adding: > > -e '/\/libzsh-.*\.dll$/d' -e '/\/lib\/zsh/d' > > To the sed filter on the script should fix it. Or perhaps making an > /etc/rebase.conf with exclusion filters. Want me to make a patch? Let's wait to see what the zsh maintainer comes up with. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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: Question about default base address and offset for rebasing DLLs
Rafael,
Sorry for the delay...
On Wed, Dec 10, 2003 at 01:38:03AM -0800, Rafael Kitover wrote:
> I noticed that the /bin/rebaseall script assumes the following:
>
> DefaultBaseAddress=0x7000
> DefaultOffset=0x1
>
> Is this going to be the standard base and offset for DLLs in Cygwin?
I guess so. I based my decision on the following:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/rebaseimage.asp
Note I eliminated MIPS support in favor of a larger rebase address
space.
> Is this then a reasonable thing to include in the Cygwin hints file
> for my Perl project:
>
> package MY;
> sub MY::dynamic_lib {
>my $target = shift->SUPER::dynamic_lib(@_);
>if (defined $target && $target && -e '/bin/rebase') {
> $target .= <<'EOF';
> rebase -v -d -b 0x7000 -o 0x1 $@
I guess so.
> Will binutils eventually rebase things to some sort of standard as
> well?
Not unless you supply a patch... :,) However, since the build and
target machines are unlikely to match (from a rebase POV), I don't think
this is a viable approach. IMO, integration with Cygwin's setup.exe is
a better way to go.
Jason
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
--
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: Question about default base address and offset for rebasing DLLs
Ivan, On Mon, Dec 22, 2003 at 10:47:19AM -0500, Petric, Ivan wrote: > please unsubscribe me...thanks! Sorry, I don't have the authority, but you do! Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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 compile cygwin
On Mon, Dec 22, 2003 at 03:29:25PM +0100, Gabriel SOUBIES wrote: >I've been using Cygwin for a while and am really happy with it. >But recently my paranoid boss has asked me to prove him that there was no >security problem with using Cygwin on our secure network. Cygwin is not secure. It's a given. There are surely easy local exploits that could be used to break it. We (i.e., Pierre Humblet) are slowly working on this but it is not likely to change anytime soon. -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.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: rebaseall breaks zsh?
On Mon, 22 Dec 2003, Jason Tishler wrote: > Rafael, > > Sorry for the delay... > > On Wed, Dec 10, 2003 at 01:26:07AM -0800, Rafael Kitover wrote: > > I noticed that the rebaseall scripts rebases /usr/bin/libzsh-4.0.4.dll > > and the modules in /usr/lib/zsh/4.1.1/zsh/*.dll, and that this breaks > > zsh. Rebasing libzsh stops zsh from starting, and rebasing the modules > > stops them from loading. > > > > If this is the case, and not just something messed up on my system, > > adding: > > > > -e '/\/libzsh-.*\.dll$/d' -e '/\/lib\/zsh/d' > > > > To the sed filter on the script should fix it. Or perhaps making an > > /etc/rebase.conf with exclusion filters. Want me to make a patch? > > Let's wait to see what the zsh maintainer comes up with. I've reproduced the problem under a debugger and it's very interesting. The segfault occurs before main even gets control. From the looks of it, the cygwin runtime faults trying to resolve some entry point that still points to the old image base address, which is below the rebased image base address (so no wonder it's faulting). I'm trying to come up with a simple test case, but I'm about to leave for the holidays, so I'll get right back on it after the new year. BTW, Merry Christmas and Happy New Year everyone! > Thanks, > Jason -- Peter A. Castro <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> "Cats are just autistic Dogs" -- Dr. Tony Attwood -- 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 compile cygwin
Christopher Faylor wrote: On Mon, Dec 22, 2003 at 03:29:25PM +0100, Gabriel SOUBIES wrote: I've been using Cygwin for a while and am really happy with it. But recently my paranoid boss has asked me to prove him that there was no security problem with using Cygwin on our secure network. Cygwin is not secure. It's a given. There are surely easy local exploits that could be used to break it. Ha! Ask that boss to prove to you that there is no security problem running Windows on a 'secure' network. I'd like to see him try to get the source code and recompile THAT! -- Jim Ramsay -- 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: Java hello world link error
mauro zallocco wrote: I noticed that the resulting Test.exe attempts to access the internet. Is this expected ? Its trying to access 24.25.4.107 which my getHost tool tells me is rlghnc-dns-cac-02-dmfe1.nc.rr.com. It's not unexpected or incorrect, but may be suboptimal. This host is obviously your DNS host, and the GCJ runtime is apparently attempting to resolve your true host name from the DNS server using your IP address. The Java runtime insists that InetAddress.getLocalHost() return your true IP address, not "127.0.0.1". Unfortunately, in a dialup setup with automatic connection, such a lookup will trigger your dialer. The "real" Java runtime has put in some workarounds to prevent such a lookup unless it's really needed (i.e. you use a networking class of some sort, or some other class that needs the "real" hostname and IP address). Perhaps the Gnu java runtime doesn't have such tweaks in it.. -- 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 compile cygwin
Jim Ramsay wrote: Ha! Ask that boss to prove to you that there is no security problem running Windows on a 'secure' network. To a person with that mentality, Bill Gates is implicitly trustworthy (i.e. if he says it's true, it must be true by definition, because it's a "big company that stands by its products"), while anything Open Source is written by h4x0rs and thus must "prove its trustworthiness". How, you ask them? They don't know, but you'd better "know". No point arguing with them.. -- 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 compile cygwin
On Mon, Dec 22, 2003 at 11:15:34AM -0800, Shankar Unni wrote: >Jim Ramsay wrote: >>Ha! Ask that boss to prove to you that there is no security problem >>running Windows on a 'secure' network. > >To a person with that mentality, Bill Gates is implicitly trustworthy >(i.e. if he says it's true, it must be true by definition, because >it's a "big company that stands by its products"), while anything Open >Source is written by h4x0rs and thus must "prove its trustworthiness". > >How, you ask them? They don't know, but you'd better "know". No point >arguing with them.. Proving the trustworthiness of any important system is never a waste of time. Let me state again, for the record: cygwin is not secure. 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: Here's a revised SSMTP
Hi Corinna, On Mon, 22 Dec 2003 15:01:06 +0100 you wrote: >while I appreciate the work you've put into this project, I don't think >it's the way to go to stick with the current version of ssmtp and only >change it that much for Cygwin. > >The mainline version of ssmtp is currently 2.60.4 (see >ftp://ftp.freebsd.org/pub/FreeBSD/distfiles) and I think it would be a >good idea trying to keep in sync with mainline and to submit patches >back to mainline (something I myself haven't done, admittedly). I had no idea that ssmtp was under development somewhere else-- had I known, I might've saved myself the time of rewriting this one. I can't get a response from their ftp server at the moment, but I'll have to drift over there eventually and take a look. That may be a while, though-- what I have now works well enough, and I'm busy with other things. >Since you seem to be way more interested in using and maintaining >ssmtp, I'm offering to step back as maintainer so that you can step >forward and take over. I guess that would be in everyone's interest. Sorry, I can't commit to investigating bug reports, keeping up with development, and the other things I'd feel responsible for as the maintainer of a software package. I didn't want to rewrite ssmtp, but I couldn't find anything else that small and simple, which does pretty much what I need. Having rewritten it though, I thought I'd share it with other Cygwin users. Jeff -- 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 compile cygwin
proving a negative is much harder than proving a positive... Arash Partow On Mon, Dec 22, 2003 at 11:15:34AM -0800, Shankar Unni wrote: Jim Ramsay wrote: Ha! Ask that boss to prove to you that there is no security problem running Windows on a 'secure' network. To a person with that mentality, Bill Gates is implicitly trustworthy (i.e. if he says it's true, it must be true by definition, because it's a "big company that stands by its products"), while anything Open Source is written by h4x0rs and thus must "prove its trustworthiness". How, you ask them? They don't know, but you'd better "know". No point arguing with them.. Proving the trustworthiness of any important system is never a waste of time. cgf _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp -- 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 compile cygwin
On Mon, Dec 22, 2003 at 09:54:43PM +, Arash Partow wrote: >proving a negative is much harder than proving a positive... Yeah. You're right. It's better to just assume it's gloriously trustworthy if it's free software and maliciously bad if it comes from Microsoft. 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: Unable to compile cygwin
Christopher Faylor wrote: Yeah. You're right. It's better to just assume it's gloriously trustworthy if it's free software and maliciously bad if it comes from Microsoft. I like your sarcasm, but I prefer to assume that the only truly secure network is one without computers attached, and the only truly secure computer is one with no OS, or no users :) Sadly both of these are hard to do anything useful with, so in reality I believe (in general) it is easier to check the security of an open-source product since I can look at the source code and see if there are unchecked buffers, backdoors, etc. I am by no means a security expert, so I'm sure I'd miss lots of things, but theoretically there are lots of other people also checking the same code as me and helping make things more secure. -- Jim Ramsay -- 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/
Is perl-5.8.2 canonized for use on cygwin yet?
I wanted to add threading to perl, so I snarfed the 5.8.2 distro and tried to build it. I got through Configure (not without a little Space Ace flashback, mind you), but when I did make(1) it went down into the B-module build and croaked. The error message is shown below. I hacked around in there for a while, but nothing obvious appeared, nor inobvious things among those I tried to avert. In particular, I didn't see an unterminated string anywhere near the rule I think it's processing (make -d was barely more illuminary). It's likely importing the problem from somewhere up the rather ugly tree. So I figured someone else has seen this before. The people who were crazy enough to leave their email addresses in perl's cygwin installation docs aren't being helpful (unless you call reflexive BOFH-grade whining helpful). You'd think they'd understand not to make themselves available as POC if they're not POC. Go figure. In the meantime I realized that 5.8.2 is newer than I thought it was. Maybe I *am* the first to try to build it on cygwin. Nah. Someone out there has seen this before. Is it anyone who's also still on the mailing list? How did you handle it? --Blair % make [...] Making B (dynamic) Writing Makefile for B::C Writing Makefile for B make[1]: Entering directory `/usr/src/perl-5.8.2/ext/B' make[1]: Leaving directory `/usr/src/perl-5.8.2/ext/B' make[1]: Entering directory `/usr/src/perl-5.8.2/ext/B' cp B/Stash.pm ../../lib/B/Stash.pm cp B/Asmdata.pm ../../lib/B/Asmdata.pm cp B/C.pm ../../lib/B/C.pm cp B/Deparse.pm ../../lib/B/Deparse.pm cp B/Debug.pm ../../lib/B/Debug.pm cp B/cc_harness ../../lib/B/cc_harness cp B.pm ../../lib/B.pm cp B/Bblock.pm ../../lib/B/Bblock.pm cp B/Assembler.pm ../../lib/B/Assembler.pm cp B/Terse.pm ../../lib/B/Terse.pm cp B/CC.pm ../../lib/B/CC.pm cp O.pm ../../lib/O.pm cp B/Concise.pm ../../lib/B/Concise.pm cp B/Lint.pm ../../lib/B/Lint.pm cp B/Showlex.pm ../../lib/B/Showlex.pm cp B/Bytecode.pm ../../lib/B/Bytecode.pm cp B/Disassembler.pm ../../lib/B/Disassembler.pm cp B/assemble ../../lib/B/assemble cp B/Xref.pm ../../lib/B/Xref.pm cp B/Stackobj.pm ../../lib/B/Stackobj.pm cp B/disassemble ../../lib/B/disassemble cp B/makeliblinks ../../lib/B/makeliblinks Syntax error: Unterminated quoted string make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `/usr/src/perl-5.8.2/ext/B' make: *** [lib/auto/B/B.dll] Error 2 -- 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: Why 2 DLL names?
Roy Clemmons wrote: > libxx.dll.a is the import library > cygxx-1.dll is the dll > > Read > http://cygwin.com/cygwin-ug-net/dll.html > for a more complete explanation.Thanks for the reply. Unless I missed > it, I still don't understand why the shared lib was created a "cyg" > prefix and a -1 suffix. "cyg" to identify it as a Cygwin-using DLL, to avoid possible conflicts with a native-Windows version. "-1" to allow for ABI versioning. See the libtool docs, "-version-info" option. > But, be that as it may, can I rename the dll > to be the correct name?Roy No. For 2 reasons: 1) You cannot rename DLLs (and still expect them to work). 2) The name is already correct. It may not be what you were expecting, but it is correct. Max. -- 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 compile cygwin
I don't see how your sarcastic remarks relate to what i said... Yeah. You're right. It's better to just assume it's gloriously trustworthy if it's free software and maliciously bad if it comes from Microsoft. all i said was that its harder to prove something in a negative context rather than a positive one, I didn't say OSS was more secure than proprietary s/w. from a security pov everything is like a chain, and regardless of how strong some links in the chain are the old adage is true in that your chain is only as strong as its weakest link, meaning regardless of the fact that you have a good sense of s/w development or keep an eye open of buffer over run situations and the alike you will still have a weak link in the chain and that is the end user. who cares if cygwin is secure or not, because it doesn't matter and the reason is because its running on windows, an analogy would be having the front of your house fortified like a castle but leaving the back wide open which is what is happening with cygiwn on windows, who cares if you can use openssh with 2kb keys to let users login and do stuff, cause none of that matters when you are running windows, someone wanting to get into your system has only to invoke one of the thousands of remote access holes that are in the windows infrastructure to gain access to your system and thats the truth so instead of wasting time trying to make things "look'n'feel" secure why not spend some time on the inherent threading and signaling problems cygwin has, and please stop making sarcastic remarks, just imagine the things you could achieve if you spend the brain power you waste on coming up with such sarcastic remarks on this mailing list, on other more productive things to do with cygwin... Just imagine. Regards Arash _ Protect your inbox from harmful viruses with new ninemsn Premium. Click here http://ninemsn.com.au/premium/landing.asp -- 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 compile cygwin
On Tue, Dec 23, 2003 at 12:39:04AM +, Arash Partow wrote: >I don't see how your sarcastic remarks relate to what i said... > >>Yeah. You're right. It's better to just assume it's gloriously >>trustworthy if it's free software and maliciously bad if it comes from >>Microsoft. > >all i said was that its harder to prove something in a negative context >rather than a positive one, I didn't say OSS was more secure than >proprietary s/w. Yeah. I read what you wrote. Since I never advocated proving a negative, it made little sense. >from a security pov everything is like a chain, and regardless of >how strong some links in the chain are the old adage is true in >that your chain is only as strong as its weakest link, meaning >regardless of the fact that you have a good sense of s/w >development or keep an eye open of buffer over run situations and >the alike you will still have a weak link in the chain and that >is the end user. Cygwin is less secure than Windows. Hence, using your analogy, Cygwin is the weakest link in the chain and it makes Windows less secure. It's hard to imagine how anyone would think that is a good thing or how anyone would think that getting the word about about cygwin's flaws was unnecessary. Cygwin isn't insecure because Windows is insecure. Cygwin is insecure because it wasn't designed to be secure from the start. >just imagine the things you could achieve if you spend the brain power >you waste on coming up with such sarcastic remarks on this mailing >list, on other more productive things to do with cygwin... > >Just imagine. Once again, I am impaled by your razor sharp observations and amazing insight. I can only hang my head in shame and promise to devote the next thirty seconds to thinking about cygwin rather than feeding the dog. I think that should make up for the lost time from my previous response. 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: Unable to compile cygwin
On Mon, Dec 22, 2003 at 04:31:57PM -0600, Jim Ramsay wrote: >Christopher Faylor wrote: >>Yeah. You're right. It's better to just assume it's gloriously >>trustworthy if it's free software and maliciously bad if it comes from >>Microsoft. > >I like your sarcasm, but I prefer to assume that the only truly secure >network is one without computers attached, and the only truly secure >computer is one with no OS, or no users :) > >Sadly both of these are hard to do anything useful with, so in reality >I believe (in general) it is easier to check the security of an >open-source product since I can look at the source code and see if >there are unchecked buffers, backdoors, etc. I am by no means a >security expert, so I'm sure I'd miss lots of things, but theoretically >there are lots of other people also checking the same code as me and >helping make things more secure. This is a very good point and it is one of the reasons why free software is so powerful. So, in theory, free software *should* be more secure. It varies, in practice, however, depending on the project. Cygwin went many years before anyone cared enough to start looking into making it more secure. So, theoretically, it did not benefit very much from all of the theoretical eyes looking at the source code. In fact, the usual questions to this mailing list on this issue do not evince the slightest desire to investigate source code. It is refreshing to see someone approaching things from this angle even if it is unfortunate that the person had problems (which I can't explain) building cygwin. -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.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: Unable to compile cygwin
On Mon, Dec 22, 2003 at 08:53:33PM -0500, Christopher Faylor wrote: > On Mon, Dec 22, 2003 at 04:31:57PM -0600, Jim Ramsay wrote: > >Christopher Faylor wrote: > > >I like your sarcasm, but I prefer to assume that the only truly secure > >network is one without computers attached, and the only truly secure > >computer is one with no OS, or no users :) > > > >Sadly both of these are hard to do anything useful with, so in reality > >I believe (in general) it is easier to check the security of an > >open-source product since I can look at the source code and see if > >there are unchecked buffers, backdoors, etc. I am by no means a > >security expert, so I'm sure I'd miss lots of things, but theoretically > >there are lots of other people also checking the same code as me and > >helping make things more secure. > > This is a very good point and it is one of the reasons why free software > is so powerful. So, in theory, free software *should* be more secure. > It varies, in practice, however, depending on the project. > > Cygwin went many years before anyone cared enough to start looking into > making it more secure. So, theoretically, it did not benefit very much > from all of the theoretical eyes looking at the source code. In fact, > the usual questions to this mailing list on this issue do not evince the > slightest desire to investigate source code. It is refreshing to see > someone approaching things from this angle even if it is unfortunate > that the person had problems (which I can't explain) building cygwin. I believe that the latest snapshot is "as secure as Windows" in the case where the only Cygwin processes are logged in using Terminal Services on Windows 2003 or Windows 2000 sp4, and do not have the "Create Global Object" privilege (please don't laugh, that's an achievement). That is, if such a user runs cygwin compiled programs under a cygwin shell, he is no more exposed and has no more power that if running regular Windows programs under cmd.exe Now, how can we gain confidence in the above statement? Should Chris start distributing stars to those who provide exploits, or could Red Hat be persuaded to give away valuable Tee Shirts to same? To the contrary, it's likely that a user logged in with the above privilege, or from the console, can be tricked into doing things on behalf of another, and a user logged in over Cygwin telnetd, crond or sshd can escalate his privileges to those of system... (no price given for demonstrating those, at least for now). Note that the previous discussion concerns users that are legally logged in. When it comes to attacks from outside, the simple act of opening a service such as sshd can open a hole. However I would guess that it won't be Cygwin specific, i.e. the same attack could be used with the same daemon running on, say, Linux, or the attack will exploit a Windows weakness. Again, how can we gain confidence in such statements? Pierre -- 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 compile cygwin
On Mon, Dec 22, 2003 at 11:13:00PM -0500, Pierre A. Humblet wrote: >I believe that the latest snapshot is "as secure as Windows" in the case >where the only Cygwin processes are logged in using Terminal Services >on Windows 2003 or Windows 2000 sp4, and do not have the "Create Global >Object" privilege (please don't laugh, that's an achievement). >That is, if such a user runs cygwin compiled programs under a cygwin shell, >he is no more exposed and has no more power that if running regular Windows >programs under cmd.exe There are still other holes. However, while I understand that there is no real security in security through obscurity, I don't think it is useful to discuss all of the specific holes we know of in a public list. -- 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: Is perl-5.8.2 canonized for use on cygwin yet?
Blair P. Houghton wrote: The people who were crazy enough to leave their email addresses in perl's cygwin installation docs aren't being helpful (unless you call reflexive BOFH-grade whining helpful). You'd think they'd understand not to make themselves available as POC if they're not POC. Go figure. In response to a (private) "request" for help that included the polite statement: "I got your names out of http://search.cpan.org/~jhi/perl-5.8.1/README.cygwin . Hey, that's what you get for putting them in there." I (privately [*]) wrote the following "BOFH-grade whining": None of us (with the exception of Gerrit) have had anything to do with perl since before 5.6.0. And even Gerrit probably doesn't appreciate getting cygwin-related email in his personal box. Please keep cygwin-related question on the cygwin mailing list. [EMAIL PROTECTED] Gerrit is the current maintainer, reads the list, and is (one of) the most qualified to answer questions about the current perl distributions on cygwin. And if he doesn't know, somebody else on the list will. [*] well, restricted to the list of previous recipients Mr. Houghton, there is a difference between a POC and a historical record of major contributors. As with most projects, new contributors perl's cygwin port are loath to remove the record of their predecessors, and simply append their name to the existing list. Meanwhile, the earlier contributors have almost certainly moved on. I was perfectly content to ignore this, but I couldn't allow you to accuse Eric, alex, Steven, Sebastien, and Teun of whining and unhelpfulness. Unless you got other emails on which I was not CC'ed, blame ME not them for any "whining" you believe is represented by the above text. (Gerrit is around and can defend himself, and I really don't care what you say or think about me.) Gerrit: I suggest that you edit the README.cygwin file, leaving in the names of the contributors (hell, delete mine if you want) and eliminate all email addresses except [EMAIL PROTECTED], so we don't need to go thru this exercise again. End of my contributions to this thread. -- Chuck -- 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/
