Re: Building OpenSSH

[Karl M]

From: Igor Pechtchanski
Subject: Re: Building OpenSSH
Date: Thu, 3 Mar 2005 00:25:37 -0500 (EST)
On Wed, 2 Mar 2005, Karl M wrote:
> Hi All...
>
> While tracking down an occasional hang in keychain, I tracked it down to
> ssh-add...so I wanted to build OpenSSH. More on this when I finish 
tracking it
> down. But along the way...
>
> I used the following command from the cygwin openssh readme file.
>
> ./configure --prefix=/usr --sysconfdir=/etc --libexecdir='$(sbindir)' \
> --localstatedir=/var --datadir='$(prefix)/share' 
--mandir='$(datadir)/man' \
> --with-tcp-wrappers
>
> The configure complains that commands sbindir and datadir are not 
defined.
> Should I be doing things differently?

Those are supposed to be braces, not parentheses.  I.e., use "${sbindir}"
instead of "$(sbindir)".  I would also recommend using a font that makes
better distinction between "(" and "{".
That is what I suspected...so take a look at the openssh.README file...so it 
is a typo there.
> Also, would it be possible for the OpenSSH maintainer to create a 
package
> (pseudo package) that captures the dependencies required to build 
OpenSSH? It
> would make building it much easier.

Is this sentence from the end of /usr/share/doc/Cygwin/openssh.README:
You must have installed the zlib, the openssl-devel and the
minires-devel packages to be able to build OpenSSH!
Also TCP Wrappers and I don't recall if there was anything else (it is past 
my bedtime). It is not worth a lot of work, but it might not be a bad way to 
"document" the dependences.
not enough?  Or do you mean stuff like "gcc", "ash", "make", etc?
No, not the tools.
	Igor
Thanks,
...Karl

--
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: Building OpenSSH

[Igor Pechtchanski]

On Thu, 3 Mar 2005, Karl M wrote:

> > From: Igor Pechtchanski
> > Subject: Re: Building OpenSSH
> > Date: Thu, 3 Mar 2005 00:25:37 -0500 (EST)
> >
> > On Wed, 2 Mar 2005, Karl M wrote:
> >
> > > I used the following command from the cygwin openssh readme file.
> > >
> > > ./configure --prefix=/usr --sysconfdir=/etc --libexecdir='$(sbindir)' \
> > > --localstatedir=/var --datadir='$(prefix)/share' \
> > > --mandir='$(datadir)/man' --with-tcp-wrappers
> > >
> > > The configure complains that commands sbindir and datadir are not
> > > defined.  Should I be doing things differently?
> >
> > Those are supposed to be braces, not parentheses.  I.e., use
> > "${sbindir}" instead of "$(sbindir)".  I would also recommend using a
> > font that makes better distinction between "(" and "{".
>
> That is what I suspected...so take a look at the openssh.README
> file...so it is a typo there.

Ah, so it is.  Initially I missed the fact that this was coming from the
README file.  FWIW, the above recommendation (about the fonts) applies
equally well to the README author.  Corinna?

> > > Also, would it be possible for the OpenSSH maintainer to create a
> > > package (pseudo package) that captures the dependencies required to
> > > build OpenSSH?  It would make building it much easier.
> >
> > Is this sentence from the end of /usr/share/doc/Cygwin/openssh.README:
> >
> > You must have installed the zlib, the openssl-devel and the
> > minires-devel packages to be able to build OpenSSH!
>
> Also TCP Wrappers and I don't recall if there was anything else (it is
> past my bedtime).  It is not worth a lot of work, but it might not be a
> bad way to "document" the dependences.

Hmm, that's certainly a valid point.  However, setup.exe doesn't currently
support source package dependencies, so I guess listing them in the README
is the only way to go ATM.

> > not enough?  Or do you mean stuff like "gcc", "ash", "make", etc?
>
> No, not the tools.

Right.  Just clarifying.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Building OpenSSH

[Igor Pechtchanski]

On Thu, 3 Mar 2005, Igor Pechtchanski wrote:

> On Thu, 3 Mar 2005, Karl M wrote:
>
> > > From: Igor Pechtchanski
> > > Subject: Re: Building OpenSSH
> > > Date: Thu, 3 Mar 2005 00:25:37 -0500 (EST)
> > >
> > > On Wed, 2 Mar 2005, Karl M wrote:
> > >
> > > > Also, would it be possible for the OpenSSH maintainer to create a
> > > > package (pseudo package) that captures the dependencies required to
> > > > build OpenSSH?  It would make building it much easier.
> > >
> > > Is this sentence from the end of /usr/share/doc/Cygwin/openssh.README:
> > >
> > >   You must have installed the zlib, the openssl-devel and the
> > >   minires-devel packages to be able to build OpenSSH!
> >
> > Also TCP Wrappers and I don't recall if there was anything else (it is
> > past my bedtime).  It is not worth a lot of work, but it might not be a
> > bad way to "document" the dependences.
>
> Hmm, that's certainly a valid point.  However, setup.exe doesn't currently
> support source package dependencies, so I guess listing them in the README
> is the only way to go ATM.

Oops, just realized that those *aren't* source packages after all.  It's
obviously way past my bedtime as well. :-)
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

keychain service--hanging in ssh-add

[Karl M]

Hi All...
I tracked it down. It is not a problem with keychain, openssh or cygwin.
Occasionally, on this particular laptop (XP SP2), the user can reboot, log 
in and start a bash shell before all of the services are running or while 
they are still starting. Gotta love Microsoft. So that was causing the 
problem.

I have a little more handshaking to prevent the problem now.
I think the keychain service stuff just is about ready for a wider audience.
Corinna...I have not heard back from Hack after I sent him an e-mail a week 
ago. I am happy to support an updated keychain package, or just place my 
files in the archives. We can wait a while longer to see if we hear from 
Hack. Just let me know how you would like to proceed.

Thanks,
...Karl

--
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: Error linking under Cygwin: fork: can't reserve memory for stack XXX, Win32 error 487

[Martin Egholm Nielsen]

Hi,
I've ended up here after having rounded the gcc-irc-channel and the 
crosscompiler mailing-list.

The story:
I have compiled a gcc crosscompiler hosted under Cygwin using Dan 
Kegel's Crosstool scripts.

However, as my application is growing in size (number of .o files) I 
suddenly get the following fault message from collect2.exe when trying 
to link them all together:

$ powerpc-405-linux-gnu-gcj --main=foo.Main *.o
C:\cygwin\opt\crosstool\powerpc-405-linux-gnu\gcc-3.4.0-glibc-2.2.5\libexec\gcc\powerpc-405-linux-gnu\3.4.0\collect2.exe 
(1740): *** fork: can't reserve memory for stack 0x4 - 0x24, Win32 
error 487


There is roughly 600 .o files to link together.
Andrew Haley from RedHat mentioned that
"There's some magic in Win32 to extend the size of a stack segment"
"I can't remember the command"
Can anybody on this list help me out here?

  % gcc -v --help |& grep stack
-fstack-limit-register=  Trap if the stack goes past 
-fstack-limit-symbol=  Trap if the stack goes past symbol 
-fstack-check   Insert stack checking code into the program
-fomit-frame-pointerWhen possible do not generate stack frames
-fdefer-pop Defer popping functions args from stack until later
-fstack-checkingEnable stack checking (same as `{$S+}')
-fno-stack-checking Disable stack checking (same as `{$S-} (default)')
-mstack-arg-probe Enable stack probing
-mpreferred-stack-boundar Attempt to keep stack aligned to this power of 2
--stack  Set size of the initial stack

Hum, these options are not available in my crosscompiler:
$ powerpc-405-linux-gnu-gcc -v --help 2>&1 | grep stack
  -fdefer-pop Defer popping functions args from stack until
  -fomit-frame-pointerWhen possible do not generate stack frames
  -fstack-check   Insert stack checking code into the program
  -fstack-limit   This switch lacks documentation
  -fstack-limit-register= Trap if the stack goes past 
  -fstack-limit-symbol= Trap if the stack goes past symbol 
  --execstack require executable stack for this object
  --noexecstack   don't require executable stack for this object
  -z execstack  Mark executable as requiring executable stack
  -z noexecstackMark executable as not requiring executable stack
  -z execstack  Mark executable as requiring executable stack
  -z noexecstackMark executable as not requiring executable stack
  -z execstack  Mark executable as requiring executable stack
  -z noexecstackMark executable as not requiring executable stack
However, this may actually also be a sign that you need to run rebaseall.
I've tried running rebaseall without any errors, but also without any 
changes in the above behavior...

// Martin
--
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/

Buiding net-snmp perl in cygwin - Please anyone help me

[Aparna R]

I Downloaded net-snmp-5.2.1.tar.gz and it got successfully installed on
cygwin.
Installed Modules: ActivePerl 5.8.6
 Perl that comes with cygwin


When Net-SNMP Perl modules are installed in cygwin I am getting
following error


$perl MakeFile.PL  is successful

Writing Makefile for NetSNMP::default_store
Writing Makefile for NetSNMP::ASN
Writing Makefile for NetSNMP::OID
Note (probably harmless): No library found for -liphlpapi
Writing Makefile for NetSNMP::agent::default_store
Writing Makefile for NetSNMP::agent
Writing Makefile for SNMP
Warning: prerequisite NetSNMP::OID 5.1 not found.
Writing Makefile for NetSNMP::TrapReceiver
Writing Makefile for Bundle::NetSNMP


$make  (-- following error is thrown)


collect2: ld returned 1 exit status
perlld: *** system() failed to execute
gcc -shared -o  agent.dll -Wl,--out-implib=libagent.dll.a
-Wl,--export-all-symbo
ls -Wl,--enable-auto-import -Wl,--stack,8388608 \
-s -L/usr/local/lib agent.o
/usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a -L/usr
/local/lib -lnetsnmpagent -lnetsnmpmibs -lnetsnmphelpers -lnetsnmp
-lcrypto -lm


make[1]: *** [../blib/arch/auto/NetSNMP/agent/agent.dll] Error 1
make[1]: Leaving directory `/cygdrive/c/net-snmp-5.2.1/perl/agent'
make: *** [subdirs] Error 2


Pls anyone help me on this. What could be the issue?

I have gcc,make,win32api everything got installed along with cygwin. But I
could not able to figure out the issue.


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: cp (coreutils) 5.2.1 Corrupts Binary File

[Vincent Rowley]

Igor Pechtchanski  cs.nyu.edu> writes:

> Two more (probably easier) ways:
> 1) Run setup.exe and select "Unix line endings"; then select the "Keep"
> mode (switch to the "Partial" view to make sure no packages will get
> installed), and complete the installation.  The mounts will be switched.
> 2) From a bash prompt in /bin, run
> 
> PATH="$PATH:." eval "`mount -m | grep ' -t ' | sed 's/ -t / -b /'`"
> 
> (Google for "cygwin remount binary").
> HTH,
>   Igor


Hi Corinna and Igor,

FYI, a co-worker tried a newer version of coreutils and it solved the issue.

In my case, I just re-ran Setup.exe specifying the Unix mode and it solved the 
issue (i.e. still using the coreutils that I used to use).

Thank you for the support.

Regards,

Vincent



--
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/

ghostscript/fontconfig issues

[Bertalan Fodor]

Hello,
I've found the following bugs/issues about the ghostscript and 
fontconfig packages and their cooperation:
- fontconfig segfaults with old fonts in ghostscript (hr*), because they 
are buggy. AFAIK other ghostscript distributions do not contain them for 
the same reason.
- fontconfig's /etc/fonts/local.conf should contain the  tag for 
/usr/share/ghostscript/fonts, to enable fontconfig-aware applications to 
use them. So gs and font-config should play together.

I think these two issues are to be solved by the maintainers of 
fontconfig and ghostscript.

Thank you,
Bert
--
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: ctime: creation or change time?

[Corinna Vinschen]

On Mar  2 13:19, [EMAIL PROTECTED] wrote:
> In fact, NTFS has no notion of file change time as described in POSIX.  Is 
> there
> any chance of undoing this change?  An alternative solution might be to simply
> use the NTFS file modify time for both the mtime and ctime of the file, since
> those two are almost always updated together anyway.

Well, we're trying to be POSIX like, so that's nothing we're going to
revert.  I guess we're using ctime as change time even more in future.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
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: Building OpenSSH

[Corinna Vinschen]

On Mar  3 00:04, Karl M wrote:
> >> ./configure --prefix=/usr --sysconfdir=/etc --libexecdir='$(sbindir)' \
> >> --localstatedir=/var --datadir='$(prefix)/share' 
> >--mandir='$(datadir)/man' \
> >> --with-tcp-wrappers
> >>
> >> The configure complains that commands sbindir and datadir are not 
> >defined.
> >> Should I be doing things differently?
> >
> >Those are supposed to be braces, not parentheses.  I.e., use "${sbindir}"
> >instead of "$(sbindir)".  I would also recommend using a font that makes
> >better distinction between "(" and "{".
> That is what I suspected...so take a look at the openssh.README file...so 
> it is a typo there.
> >
> >> Also, would it be possible for the OpenSSH maintainer to create a 
> >package
> >> (pseudo package) that captures the dependencies required to build 
> >OpenSSH? It
> >> would make building it much easier.
> >
> >Is this sentence from the end of /usr/share/doc/Cygwin/openssh.README:
> >
> > You must have installed the zlib, the openssl-devel and the
> > minires-devel packages to be able to build OpenSSH!
> Also TCP Wrappers and I don't recall if there was anything else (it is past 
> my bedtime). It is not worth a lot of work, but it might not be a bad way 
> to "document" the dependences.

I'll change the README to use braces and add the tcp_wrappers dependency.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
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: keychain service--hanging in ssh-add

[Corinna Vinschen]

On Mar  3 00:22, Karl M wrote:
> Corinna...I have not heard back from Hack after I sent him an e-mail a week 
> ago. I am happy to support an updated keychain package, or just place my 
> files in the archives. We can wait a while longer to see if we hear from 
> Hack. Just let me know how you would like to proceed.

If you like you can send an ITP to cygwin-apps.  Considering that Hack
could be on vacations or something like that, let's wait another two weeks
or three, though.  After that, I think we can define the keychain package
yours.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
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: keychain service--hanging in ssh-add

[Brian Dessent]

Karl M wrote:

> I tracked it down. It is not a problem with keychain, openssh or cygwin.
> 
> Occasionally, on this particular laptop (XP SP2), the user can reboot, log
> in and start a bash shell before all of the services are running or while
> they are still starting. Gotta love Microsoft. So that was causing the
> problem.

You can solve this by using the --dep option of cygrunsrv when you
install the service.  For example I use "--dep Tcpip" or "--dep
dnscache" for Cygwin services that depend on TCP/IP networking and/or
name resolution.

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: cygstart patch

[Derosa, Anthony CIV NAVAIR 2035, 2, 205/214]

>OTOH, I can't see anyway around it without ALSO calling strlen()

I'm no expert either, but I did use strlen() when allocating the
memory (with malloc() and realloc()).  So if we successfully allocated
enough memory (args != NULL), then the string "*rest" has some
finite length and won't cause strcat() to "go off into the weeds".
Or did you already observe that?  I don't have a better solution.

If this is a buffer overrun/security issue, how could someone
exploit it?

-Anthony

> -Original Message-
> From: Charles Wilson [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 03, 2005 1:59
> To: cygwin@cygwin.com
> Subject: Re: cygstart patch
> 
> 
> Derosa, Anthony CIV NAVAIR 2035, 2, 205/214 wrote:
> > I found a small bug and added a feature to the cygstart 
> utility, which is part of the cygutils package.  The feature 
> that I added removes the limit on the length of the command 
> line arguments passed to the target application, which was 
> previously limited to MAX_PATH.  The bug I fixed was in 
> regard to freeing the variable "args" instead of tyring to 
> free "workDir" twice.  A patch and change log follow below.  
> As this is my first contribution, please correct me if I did 
> something incorrectly.
> 
> Thanks for the patch, Anthony.  It looks good (I can't beLIEVE the 
> thinko on free(workDir) )  -- but I have one concern.  Maybe it's 
> overblown, but replacing all of the strNcat calls (which are somewhat 
> resistant to buffer overruns) with strcat (which are NOT) seems to be 
> mistake.
> 
> OTOH, I can't see anyway around it without ALSO calling 
> strlen() -- and 
> if strlen() succeeds without "going off into the weeds", the strcat() 
> will too, so you might as well just use strcat since 
> strNcat+strlen is 
> not really any more safe.
> 
> I'm not an expert on these issues; anybody else want to chime in here 
> before I apply Anthony's patch?
> 
> --
> Chuck
> 
> 
> 
> > --- ../cygutils-1.2.6/src/cygstart/cygstart.c   
> 2002-03-16 00:49:44.0 -0500
> > +++ src/cygstart/cygstart.c 2005-03-02 09:16:00.383625000 -0500
> > @@ -340,14 +340,18 @@ int main(int argc, const char **argv)
> >  
> >  /* Retrieve any arguments */
> >  if (rest && *rest) {
> > -if ((args = (char *) malloc(MAX_PATH+1)) == NULL) {
> > +if ((args = (char *) malloc(strlen(*rest)+1)) == NULL) {
> >  fprintf(stderr, "%s: memory allocation 
> error\n", argv[0]);
> >  exit(1);
> > -}
> > -strncpy(args, *rest, MAX_PATH);
> > +}   
> > +strcpy(args, *rest);
> >  while (rest++ && *rest) {
> > -strncat(args, " ", MAX_PATH-strlen(args));
> > -strncat(args, *rest, MAX_PATH-strlen(args));
> > +if ( (args = (char *) realloc(args, 
> strlen(args) + strlen(*rest) + 1)) == NULL) {
> > +fprintf(stderr, "%s: memory allocation 
> error\n", argv[0]);
> > +exit(1);
> > +}  
> > +strcat(args, " ");
> > +strcat(args, *rest);
> >  }
> >  }
> >  
> > @@ -359,7 +363,7 @@ int main(int argc, const char **argv)
> >  if (action)
> >  free(action);
> >  if (args)
> > -free(workDir);
> > +free(args);
> 
> D'oh!
> 
> 
> >  if (workDir)
> >  free(workDir);
> >  if (file)
> > 
> 
> 

--
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: loading of wsock32 disturbs FPU

[Dave Korn]

Original Message
>From: Christopher Faylor
>Sent: 03 March 2005 00:59

> I've checked in a patch to cygwin which saves and restores the FPU control
> register around calls to LoadLibrary.  That seems to solve the problem.


  Confirmed here, but why did you remove the comment?  It's still true isn't
it?


@@ -256,7 +261,6 @@ wsock_init ()

   if (!wsock_started)
 {
-  /* Don't use autoload to load WSAStartup to eliminate recursion. */
   int (*wsastartup) (int, WSADATA *);

   wsastartup = (int (*)(int, WSADATA *))




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: Buiding net-snmp perl in cygwin - Please anyone help me

[Igor Pechtchanski]

Please start a new thread instead of replying to an unrelated message.
More below.

On Thu, 3 Mar 2005, Aparna R wrote:

> I Downloaded net-snmp-5.2.1.tar.gz and it got successfully installed on
> cygwin.
> Installed Modules: ActivePerl 5.8.6
> Perl that comes with cygwin

This is unclear.  ActivePerl does not come with Cygwin.  Are you saying
you've installed both?  Are both in your PATH?
Please review and follow the Cygwin problem reporting guidelines at
 to provide the necessary information
about your installation.  The guidelines can also help you with the
phrasing of your question.

> When Net-SNMP Perl modules are installed in cygwin I am getting
> following error
>
> $make  (-- following error is thrown)
>
> collect2: ld returned 1 exit status
> perlld: *** system() failed to execute
> gcc -shared -o  agent.dll -Wl,--out-implib=libagent.dll.a 
> -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \
> -s -L/usr/local/lib agent.o /usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a 
> -L/usr/local/lib -lnetsnmpagent -lnetsnmpmibs -lnetsnmphelpers -lnetsnmp 
> -lcrypto -lm
>
> make[1]: *** [../blib/arch/auto/NetSNMP/agent/agent.dll] Error 1
> make[1]: Leaving directory `/cygdrive/c/net-snmp-5.2.1/perl/agent'
> make: *** [subdirs] Error 2

Is there a log available where the *exact* error could be seen?  If not,
try running the above command by hand from the given directory, and see
what it prints.

> Pls anyone help me on this. What could be the issue?

It could be any one of several issues: missing libraries, conflicting
Perl installations, rogue environment variables, a rebase issue,
conflicting compiler installations, a Makefile/configure error, etc.
Engaging in guesses without the exact system information is futile.

> I have gcc,make,win32api everything got installed along with cygwin. But I
> could not able to figure out the issue.

Please provide the information requested in the problem reporting
guidelines (the output of "cygcheck -svr" should be *attached* rather than
included inline).  That way, someone may be able to help you.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Error linking under Cygwin: fork: can't reserve memory for stack XXX, Win32 error 487

[Dave Korn]

Original Message
>From: Martin Egholm Nielsen
>Sent: 03 March 2005 08:42


>>> However, as my application is growing in size (number of .o files) I
>>> suddenly get the following fault message from collect2.exe when trying
>>> to link them all together:
>>> 
>>> $ powerpc-405-linux-gnu-gcj --main=foo.Main *.o
>>>
C:\cygwin\opt\crosstool\powerpc-405-linux-gnu\gcc-3.4.0-glibc-2.2.5\libexec\
gcc\powerpc-405-linux-gnu\3.4.0\collect2.exe
>>> (1740): *** fork: can't reserve memory for stack 0x4 - 0x24,
>>> Win32 error 487 

>> --stack  Set size of the initial stack
>> 
> Hum, these options are not available in my crosscompiler:
> 
> $ powerpc-405-linux-gnu-gcc -v --help 2>&1 | grep stack


  You would need to add it to the CFLAGS when _building_ the crossbinutils
linker rather than to the command line when _using_ it, so that the compiled
crossversion of collect2 runs with a bigger stack.

  If indeed that is the underlying problem.


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: cygstart patch

[Dave Korn]

Original Message
>From: Charles Wilson
>Sent: 03 March 2005 06:59

> Derosa, Anthony CIV NAVAIR 2035, 2, 205/214 wrote:
>> I found a small bug and added a feature to the cygstart utility, which
>> is part of the cygutils package.  The feature that I added removes the
>> limit on the length of the command line arguments passed to the target
>> application, which was previously limited to MAX_PATH.  The bug I fixed
>> was in regard to freeing the variable "args" instead of tyring to free
>> "workDir" twice.  A patch and change log follow below.  As this is my
>> first contribution, please correct me if I did something incorrectly.   

> I'm not an expert on these issues; anybody else want to chime in here
> before I apply Anthony's patch?

>> --- ../cygutils-1.2.6/src/cygstart/cygstart.c2002-03-16
>> 00:49:44.0 -0500 +++ src/cygstart/cygstart.c 2005-03-02
>> 09:16:00.383625000 -0500 @@ -340,14 +340,18 @@ int main(int argc, const
>> char **argv) 
>> 
>>  /* Retrieve any arguments */
>>  if (rest && *rest) {
>> -if ((args = (char *) malloc(MAX_PATH+1)) == NULL) {
>> +if ((args = (char *) malloc(strlen(*rest)+1)) == NULL) {
>>  fprintf(stderr, "%s: memory allocation error\n", argv[0]); 
>> exit(1); 
>> -}
>> -strncpy(args, *rest, MAX_PATH);
>> +}
>> +strcpy(args, *rest);
>>  while (rest++ && *rest) {
>> -strncat(args, " ", MAX_PATH-strlen(args));
>> -strncat(args, *rest, MAX_PATH-strlen(args));
>> +if ( (args = (char *) realloc(args, strlen(args) 
>> + strlen(*rest) + 1)) == NULL) { 
>> +fprintf(stderr, "%s: memory allocation error\n",
argv[0]); 
>> +exit(1); 
>> +} 
>> +strcat(args, " ");
>> +strcat(args, *rest);
>>  }
>>  }



  Let me see if I'm following this right:

  First you allocate enough space for the length of the 'rest' string (+
final NUL)
  Then you copy 'rest' into that space
  Then while there are any more args you realloc the space to extend it and
copy the new arg in place (along with a space).

  I think the realloc is off-by-one, isn't it?
  You already have args completely full with a string and NUL-term from the
initial malloc.
  You want to add another string and a space.
  So the final size is strlen of the original string + 1 for the space +
strlen of the string you are concatenating + 1 for the terminating NUL.
  But you only malloc the sum of the two strlens plus one.

  Have I misunderstood something?



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: how to stop cron logging into NT eventlog ?

[kagemaru]

Hello,
Sadly, the - at the beggining of the crontab does not work, it keeps 
loggin in the eventlog.

Thanks for your help !
Best regards,
Emmanuel
--
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: perl 5.8.6: unable to compile PAR 0.87

[Kevin Everets]

On Wed, Mar 02, 2005 at 11:29:55PM +0100, Gerrit P. Haase wrote:

> This is an already known issue with the first 5.8.6 perl including the 
> Win32CORE parts.  It was released an update to fix this issue, please 
> upgrade to the latest release.

Yup, sorry.  perl-5.8.6-1 was what I was using, and with perl-5.8.6-4
the problem is gone.  Thanks for the help,

Kevin.

--
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: cygstart patch

[Derosa, Anthony CIV NAVAIR 2035, 2, 205/214]

Dave, you're right!  I was forgetting the NUL in realloc.
I'm surprised that the original fix has been working for me.
What do you think about Chuck's concerns regarding strcat()
vs. strncat()?

So, after adding 1 to the realloc line, the patch follows
(I *didn't* regenerate this with diff, is that OK?
I just changed the "1" to "2" and removed some whitespace.):

--- ../cygutils-1.2.6/src/cygstart/cygstart.c   2002-03-16 00:49:44.0 
-0500
+++ src/cygstart/cygstart.c 2005-03-02 09:16:00.383625000 -0500
@@ -340,14 +340,18 @@ int main(int argc, const char **argv)
 
 /* Retrieve any arguments */
 if (rest && *rest) {
-if ((args = (char *) malloc(MAX_PATH+1)) == NULL) {
+if ((args = (char *) malloc(strlen(*rest)+1)) == NULL) {
 fprintf(stderr, "%s: memory allocation error\n", argv[0]);
 exit(1);
-}
-strncpy(args, *rest, MAX_PATH);
+}   
+strcpy(args, *rest);
 while (rest++ && *rest) {
-strncat(args, " ", MAX_PATH-strlen(args));
-strncat(args, *rest, MAX_PATH-strlen(args));
+if ( (args = (char *) realloc(args, strlen(args)+strlen(*rest)+2)) 
== NULL) {
+fprintf(stderr, "%s: memory allocation error\n", argv[0]);
+exit(1);
+}  
+strcat(args, " ");
+strcat(args, *rest);
 }
 }
 
@@ -359,7 +363,7 @@ int main(int argc, const char **argv)
 if (action)
 free(action);
 if (args)
-free(workDir);
+free(args);
 if (workDir)
 free(workDir);
 if (file)


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] Behalf
> Of Dave Korn
> Sent: Thursday, March 03, 2005 8:59
> To: cygwin@cygwin.com
> Subject: RE: cygstart patch
> 
> 
> Original Message
> >From: Charles Wilson
> >Sent: 03 March 2005 06:59
> 
> > Derosa, Anthony CIV NAVAIR 2035, 2, 205/214 wrote:
> >> I found a small bug and added a feature to the cygstart 
> utility, which
> >> is part of the cygutils package.  The feature that I added 
> removes the
> >> limit on the length of the command line arguments passed 
> to the target
> >> application, which was previously limited to MAX_PATH.  
> The bug I fixed
> >> was in regard to freeing the variable "args" instead of 
> tyring to free
> >> "workDir" twice.  A patch and change log follow below.  As 
> this is my
> >> first contribution, please correct me if I did something 
> incorrectly.   
> 
> > I'm not an expert on these issues; anybody else want to 
> chime in here
> > before I apply Anthony's patch?
> 
> >> --- ../cygutils-1.2.6/src/cygstart/cygstart.c  2002-03-16
> >> 00:49:44.0 -0500 +++ src/cygstart/cygstart.c   
> 2005-03-02
> >> 09:16:00.383625000 -0500 @@ -340,14 +340,18 @@ int 
> main(int argc, const
> >> char **argv) 
> >> 
> >>  /* Retrieve any arguments */
> >>  if (rest && *rest) {
> >> -if ((args = (char *) malloc(MAX_PATH+1)) == NULL) {
> >> +if ((args = (char *) malloc(strlen(*rest)+1)) == NULL) {
> >>  fprintf(stderr, "%s: memory allocation 
> error\n", argv[0]); 
> >> exit(1); 
> >> -}
> >> -strncpy(args, *rest, MAX_PATH);
> >> +}
> >> +strcpy(args, *rest);
> >>  while (rest++ && *rest) {
> >> -strncat(args, " ", MAX_PATH-strlen(args));
> >> -strncat(args, *rest, MAX_PATH-strlen(args));
> >> +if ( (args = (char *) realloc(args, strlen(args) 
> >> + strlen(*rest) + 1)) == NULL) { 
> >> +fprintf(stderr, "%s: memory allocation error\n",
> argv[0]); 
> >> +exit(1); 
> >> +} 
> >> +strcat(args, " ");
> >> +strcat(args, *rest);
> >>  }
> >>  }
> 
> 
> 
>   Let me see if I'm following this right:
> 
>   First you allocate enough space for the length of the 
> 'rest' string (+
> final NUL)
>   Then you copy 'rest' into that space
>   Then while there are any more args you realloc the space to 
> extend it and
> copy the new arg in place (along with a space).
> 
>   I think the realloc is off-by-one, isn't it?
>   You already have args completely full with a string and 
> NUL-term from the
> initial malloc.
>   You want to add another string and a space.
>   So the final size is strlen of the original string + 1 for 
> the space +
> strlen of the string you are concatenating + 1 for the 
> terminating NUL.
>   But you only malloc the sum of the two strlens plus one.
> 
>   Have I misunderstood something?
> 
> 
> 
> 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/
> 
> 

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Proble

RE: cygstart patch

[Igor Pechtchanski]

On Thu, 3 Mar 2005, Derosa, Anthony  CIV NAVAIR 2035, 2, 205/214 wrote:

> What do you think about Chuck's concerns regarding strcat()
> vs. strncat()?

I'm no expert either, but usually the purpose of strncat() is to avoid a
buffer overrun when copying an arbitrary-sized string into a
statically-sized buffer (as the string may be longer than the buffer).
Since you're sizing the buffer dynamically to the exact string size, I
don't think there's anything wrong with using strcpy/strcat here (as long
as you check that the buffer is not NULL -- and you do).

> (I *didn't* regenerate this with diff, is that OK?
> I just changed the "1" to "2" and removed some whitespace.):

Mind the spaces/tabs in the *original* code.  As long as what you edited
is in your newly-added (or replacement) code, it should still apply.
HTH,
Igor

> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave Korn
> > To: [EMAIL PROTECTED]

Oh, and .  Thanks.
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: cygstart patch

[Derosa, Anthony CIV NAVAIR 2035, 2, 205/214]

> Mind the spaces/tabs in the *original* code.  As long as what
> you edited in your newly-added (or replacement) code,
> it should still apply.

Igor, thanks.  I didn't modify the original - only my changes.
I asked because I didn't know if the diff format contains
some checksum that would be messed up by *any* changes.  I
guess the format is about as simple as it looks.

One more question: should I have changed the version of the
program in the patch, or is that up to the maintainer?

-Anthony

> -Original Message-
> From: Igor Pechtchanski [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 03, 2005 9:34
> To: Derosa, Anthony CIV NAVAIR 2035, 2, 205/214
> Cc: cygwin@cygwin.com
> Subject: RE: cygstart patch
> 
> 
> On Thu, 3 Mar 2005, Derosa, Anthony  CIV NAVAIR 2035, 2, 
> 205/214 wrote:
> 
> > What do you think about Chuck's concerns regarding strcat()
> > vs. strncat()?
> 
> I'm no expert either, but usually the purpose of strncat() is 
> to avoid a
> buffer overrun when copying an arbitrary-sized string into a
> statically-sized buffer (as the string may be longer than the buffer).
> Since you're sizing the buffer dynamically to the exact string size, I
> don't think there's anything wrong with using strcpy/strcat 
> here (as long
> as you check that the buffer is not NULL -- and you do).
> 
> > (I *didn't* regenerate this with diff, is that OK?
> > I just changed the "1" to "2" and removed some whitespace.):
> 
> Mind the spaces/tabs in the *original* code.  As long as what 
> you edited
> is in your newly-added (or replacement) code, it should still apply.
> HTH,
>   Igor
> 
> > > From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] Behalf Of Dave Korn
> > > To: [EMAIL PROTECTED]
> 
> Oh, and .  Thanks.
> -- 
>   http://cs.nyu.edu/~pechtcha/
>   |\  _,,,---,,_  [EMAIL PROTECTED]
> ZZZzz /,`.-'`'-.  ;-;;,_  [EMAIL PROTECTED]
>  |,4-  ) )-,_. ,\ (  `'-' Igor Pechtchanski, Ph.D.
> '---''(_/--'  `-'\_) fL   a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
> 
> "The Sun will pass between the Earth and the Moon tonight for a total
> Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
> 

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: cygstart patch

[Dave Korn]

Original Message
>From: Derosa, Anthony CIV NAVAIR 2035, 2, 205/214
>Sent: 03 March 2005 14:22

> Dave, you're right!  I was forgetting the NUL in realloc.
> I'm surprised that the original fix has been working for me.
> What do you think about Chuck's concerns regarding strcat()
> vs. strncat()?

  I thought about that as well.  I totally concur with your analysis: you've
just allocated X amount of space, based on having *measured* the size of the
X amount of data you want to copy into it; there's no way the strlen could
change in between your allocation and your string copy operation, and it
*has to be* safe.  Using strncpy adds a check of a counter with each byte
copied: but unless mathematics has suddenly stopped working and adding and
subtracting no longer give the right answers, there can't possibly be any
different result.

> So, after adding 1 to the realloc line, the patch follows
> (I *didn't* regenerate this with diff, is that OK?
> I just changed the "1" to "2" and removed some whitespace.):

  Yeh, with the cautions noted by Igor, there's no _technical_ problem: the
patch will still apply cleanly to the sources.  But there is an important
_process_ problem.  It is the number one sin of CVS to checkin anything
other than ***exactly*** the code that you compiled and tested, so you
aren't excused from having to re-compile and re-test the code with the +1 =>
+2 modification applied to it, and at that point you may as well re-generate
the diff.

   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: keychain service--hanging in ssh-add

[Karl M]

From: Brian Dessent
Subject: Re: keychain service--hanging in ssh-add
Date: Thu, 03 Mar 2005 04:16:23 -0800
Karl M wrote:
> I tracked it down. It is not a problem with keychain, openssh or cygwin.
>
> Occasionally, on this particular laptop (XP SP2), the user can reboot, 
log
> in and start a bash shell before all of the services are running or 
while
> they are still starting. Gotta love Microsoft. So that was causing the
> problem.

You can solve this by using the --dep option of cygrunsrv when you
install the service.  For example I use "--dep Tcpip" or "--dep
dnscache" for Cygwin services that depend on TCP/IP networking and/or
name resolution.
I do use --dep as needed. The problem here is the other way around. The user 
is logging in and starting before the service finished starting. XP in its 
desire to look like it starts up quickly is letting the user in very early.

So I guard against this by creating a file after the keychain service 
finishes launching ssh-agent...then my .profile leaves keychain alone if the 
service has not finished starting.

Thanks,
...Karl

--
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: loading of wsock32 disturbs FPU

[Christopher Faylor]

On Thu, Mar 03, 2005 at 08:15:08PM +1300, Danny Smith wrote:
>cgf wrote:
>>On Wed, Mar 02, 2005 at 03:37:42PM +0100, Corinna Vinschen wrote:
>>>On Mar  2 15:31, Corinna Vinschen wrote:
On Mar 2 13:33, Dave Korn wrote:
>Hm.  We probably need to put a finit instruction into the autoload code
>somewhere.  wsock_init () looks like just the place..  now if I
>just persuade the CVS code to build without a SIG11 (grmbl grmbl)

Hmm?  -v please.
>>>
>>>I just added an finit call to wsock_init and it seems to work fine.
>>>
>>>Are there any non-FPU CPUs >= i386 out there which would choke on this
>>>machine instruction?  I guess not, but I'm not exactly fluent in ix86
>>>history...
>>
>>I mentioned to Corinna on irc that I don't think that just calling finit
>>is the right way to handle this.  What if someone had already set the
>>precision as they liked?  Then loading winsock would reset it.
>
>Seeing this I got a fright, thinking mingw would have the same problem, with
>very bad consequences for eg,
>libgcj.a, which _always_ loads ws2_32.dll, and many, many other projects
>
>But no, I get:
>
>FPU test OK
>FPU test OK
>FPU test OK
>FPU test OK

>I think ws2_32.dll calls _fpreset() which is normally supplied by msvcrt.dll
>Mingw provides its own _fpreset  in libmingwex.a (crt_fp10.o) )  which  sets
>64-bit mantissa so all is well

I'm confused.  Where would you put a _fpreset() such that it would be
called by ws2_32.dll?  I doubt that ws2_32.dll iterates over all of the
loaded dlls looking for this function.

This would appear to be working ok if ws2_32.dll is either loaded early
in the process or if it not dynamically loaded.  Things seemed to be
working fine for me when cygwin's thread was causing ws2_32.dll to be
loaded right away.

>If I load in mingw's crt_fp8.o module, which provides a stub for the msvcrt.dll
>import  _fpreset,  I get the error.

That would imply that this has to be linked into a progarm to work.  That's not
a solution for cygwin since it seems like it would require all cygwin programs
to be relinked.

>A cygwin version of _fpreset (that calls finit) should do the trick, without 
>the
>overhead of  fpu environment  sav and restore

Maybe I'm missing something since I am not a floating point person but I
don't think saving/storing 16 bits to a location on the stack is too big
a price to pay for this.

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/

Problem with bash under cygwin 1.5.13

[Andrew Waltman]

Hi,

I frequently start multiple copies of bash at the same time when first
logging in to my computer. As of the latest update of the cygwin package
when I start more than one bash at the same time (without waiting for the
prompt to appear in the first one) I get a stack dump in the second window:

andreww:~/p4/ex70 $ bash
Exception: STATUS_ACCESS_VIOLATION at eip=61056D4D
eax=42272844 ebx= ecx=0A03 edx= esi=0022E270
edi=0A80
ebp=0022E328 esp=0022E210 program=C:\cygwin\bin\bash.exe, pid 2696, thread
main
cs=001B ds=0023 es=0023 fs=0038 gs= ss=0023
Stack trace:
Frame Function  Args
0022E328  61056D4D  (0022E480, 0022E484, 0022E488, 0022E330)
0022E4A8  6105768D  (0001, 0022E4C8, 0022E4C4, 0043D097)
0022E4D8  610938EF  (0A0520C0, , 0022E518, 6105E532)
0022E548  00413981  (0A058C98, , 0004, )
0022E588  004107BF  (0A055E18, , , 0004)
0022E5D8  004118D4  (0A05DEE8, , , )
0022E608  00411C27  (0A05DEE8, , , )
0022E648  00410A1D  (0A05DEE8, , , )
0022E688  0044D4D4  (0A05DE28, 004256E2, 0004, 0A05DE28)
0022E6E8  004259D0  (0A05DE28, , 00421EAC, )
0022E778  00428D34  (0022E7B8, , , )
0022E798  00423D70  (0022E7B8, , , )
0022E7C8  00423E31  (0A05D038, , 0022E828, 0040FA52)
0022E7E8  00423E89  (0A05D038, , 0022E83C, 0A05CA38)
0022E808  00423AD0  (0A05D038, , 00423E50, 0A053AB8)
0022E848  0042367B  (0A05D9A8, 0001, 0022E878, 00429954)
End of stack trace (more stack frames may be present)
andreww:~/p4/ex70 $

However, if I wait for eash instance of bash to come to a command prompt I
can start the 2nd, 3rd, etc. bash window. This behavior started after
updating the cygwin library to the latest revision (1.5.13).

Thanks,
Andrew

--
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: cygstart patch

[Derosa, Anthony CIV NAVAIR 2035, 2, 205/214]

> But there is an important _process_ problem.  It is the 
> number one sin of CVS to checkin anything
> other than ***exactly*** the code that you compiled and tested, so you
> aren't excused from having to re-compile and re-test the code 
> with the +1 = +2 modification applied to it, and at that point 
> you may as well re-generate the diff.

Per Dave's advice, here is the regenerated patch (re-compiled 
and re-tested code) for cygstart.

--- ../cygutils-1.2.6/src/cygstart/cygstart.c   2002-03-16 00:49:44.0 
-0500
+++ src/cygstart/cygstart.c 2005-03-03 10:04:04.09750 -0500
@@ -340,14 +340,18 @@ int main(int argc, const char **argv)
 
 /* Retrieve any arguments */
 if (rest && *rest) {
-if ((args = (char *) malloc(MAX_PATH+1)) == NULL) {
+if ((args = (char *) malloc(strlen(*rest)+1)) == NULL) {
 fprintf(stderr, "%s: memory allocation error\n", argv[0]);
 exit(1);
-}
-strncpy(args, *rest, MAX_PATH);
+}   
+strcpy(args, *rest);
 while (rest++ && *rest) {
-strncat(args, " ", MAX_PATH-strlen(args));
-strncat(args, *rest, MAX_PATH-strlen(args));
+if ((args = (char *) realloc(args, strlen(args)+strlen(*rest)+2)) 
== NULL) {
+fprintf(stderr, "%s: memory allocation error\n", argv[0]);
+exit(1);
+}  
+strcat(args, " ");
+strcat(args, *rest);
 }
 }
 
@@ -359,7 +363,7 @@ int main(int argc, const char **argv)
 if (action)
 free(action);
 if (args)
-free(workDir);
+free(args);
 if (workDir)
 free(workDir);
 if (file)

--
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: Buiding net-snmp perl in cygwin - Please anyone help me

[Gerrit P. Haase]

Aparna R wrote:
I Downloaded net-snmp-5.2.1.tar.gz and it got successfully installed on
cygwin.
Installed Modules: ActivePerl 5.8.6
 Perl that comes with cygwin
When Net-SNMP Perl modules are installed in cygwin I am getting
following error
$perl MakeFile.PL  is successful
Writing Makefile for NetSNMP::default_store
Writing Makefile for NetSNMP::ASN
Writing Makefile for NetSNMP::OID
Note (probably harmless): No library found for -liphlpapi
Writing Makefile for NetSNMP::agent::default_store
Writing Makefile for NetSNMP::agent
Writing Makefile for SNMP
Warning: prerequisite NetSNMP::OID 5.1 not found.
Writing Makefile for NetSNMP::TrapReceiver
Writing Makefile for Bundle::NetSNMP
$make  (-- following error is thrown)
collect2: ld returned 1 exit status
perlld: *** system() failed to execute
gcc -shared -o  agent.dll -Wl,--out-implib=libagent.dll.a
-Wl,--export-all-symbo
ls -Wl,--enable-auto-import -Wl,--stack,8388608 \
-s -L/usr/local/lib agent.o
/usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a -L/usr
/local/lib -lnetsnmpagent -lnetsnmpmibs -lnetsnmphelpers -lnetsnmp
-lcrypto -lm
make[1]: *** [../blib/arch/auto/NetSNMP/agent/agent.dll] Error 1
make[1]: Leaving directory `/cygdrive/c/net-snmp-5.2.1/perl/agent'
make: *** [subdirs] Error 2
Pls anyone help me on this. What could be the issue?
This is not the actual error message, this is just the output of the
ld wrapper script which rephrases the used command which failed to 
execute, please send the actual compiler / linker output.

Gerrit
--
=^..^=
Action Soccer: http://www.action-soccer.de/?lv=de&id=505
(german online game)
--
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/

cron copy on network drives

[Paul Hodor]

Hi,

I am trying to set up a cron service to update some directories on a
network drive, but I ran into a problem.

This copy command works from the command-line:
cp -a -u -v //mydrive/myshare/dir1/* //mydrive/myshare/dir2 >> log 2>&1

However, if I run it with cron I get the following error:
cp: cannot stat `//mydrive/myshare/dir1/*': No such file or directory

Do I need to use a different syntax for the path or am I doing
something else wrong? I am running Windows XP Professional version 2002
SP1 and cygwin DLL version 1.5.12.

Thanks,
Paul






__ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/

--
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/

Slow pipes after upgrade cygwin 1.5.12-1->1.5.13-1 when running boinc

[Bengt-Arne Fjellner]

With boinc running [EMAIL PROTECTED] at lowest priority ( uses 100% cpu but 
yields easily)
simple pipes takes a long time.
Example: from a bash prompt
echo hello|grep -v xyz
with boinc running and 1.5.13-1 takes about 7 seconds.
if i stop boinc it takes parts of a second.
after downgrade to 1.5.12-1 with boinc running: parts of a second.

i have seen this on two different computers one HT one normal.

Single commands are still fast.

-- 
Bengt-Arne Fjellner
Luleå University of technology
LTU Skellefteå
Skellefteå
Sweden
0910-58 53 69



--
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: cron copy on network drives

[Bryan Thrall]

From: Paul Hodor
Date: Thu, 3 Mar 2005 08:13:36 -0800 (PST)
Hi,
I am trying to set up a cron service to update some directories on a
network drive, but I ran into a problem.
This copy command works from the command-line:
cp -a -u -v //mydrive/myshare/dir1/* //mydrive/myshare/dir2 >> log 2>&1
However, if I run it with cron I get the following error:
cp: cannot stat `//mydrive/myshare/dir1/*': No such file or directory
Do I need to use a different syntax for the path or am I doing
something else wrong? I am running Windows XP Professional version 2002
SP1 and cygwin DLL version 1.5.12.
Thanks,
Paul
I think I've run into this very problem. Are you running cron as a 
different user than your login (such as SYSTEM)? My understanding is 
that in that case, cron has a limited form of su which does not allow it 
to fully authenticate as you when accessing network drives. So, it tries 
to su to your login when it runs your cron job, but cannot read or write 
to network drives you have mapped.

Unfortunately, I don't know a workaround for this. You could have cron 
map the network drive itself (using 'net use') but that would probably 
require a password - in plain text! You could also run cron as yourself 
so it actually uses your login (rather than trying to su), but that 
means every time you login you have to start cron and it won't be 
running after you log out!

You might be able to get around this by using ssh instead of network 
drives (a combination of a ssh server on the remote machine and 
ssh-agent to avoid plaintext passwords in your cron job script, maybe).

That's how it was explained to me, anyway. HTH!
--
Bryan Thrall
Realtime Software Engineer
FlightSafety International
--
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: cron copy on network drives

[Larry Hall]

At 11:13 AM 3/3/2005, you wrote:
>Hi,
>
>I am trying to set up a cron service to update some directories on a
>network drive, but I ran into a problem.
>
>This copy command works from the command-line:
>cp -a -u -v //mydrive/myshare/dir1/* //mydrive/myshare/dir2 >> log 2>&1
>
>However, if I run it with cron I get the following error:
>cp: cannot stat `//mydrive/myshare/dir1/*': No such file or directory
>
>Do I need to use a different syntax for the path or am I doing
>something else wrong? I am running Windows XP Professional version 2002
>SP1 and cygwin DLL version 1.5.12.



Read:

Why don't my services work (or access network shares)?


Most likely you're trying to access a network share when cron doesn't have
access to it.

--
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: Slow pipes after upgrade cygwin 1.5.12-1->1.5.13-1 when running boinc

[Christopher Faylor]

On Thu, Mar 03, 2005 at 05:36:00PM +0100, Bengt-Arne Fjellner wrote:
>With boinc running [EMAIL PROTECTED] at lowest priority ( uses 100% cpu but 
>yields easily)
>simple pipes takes a long time.
>Example: from a bash prompt
>echo hello|grep -v xyz
>with boinc running and 1.5.13-1 takes about 7 seconds.  if i stop boinc
>it takes parts of a second.  after downgrade to 1.5.12-1 with boinc
>running: parts of a second.
>
>i have seen this on two different computers one HT one normal.
>
>Single commands are still fast.

Is there some reason why you'd expect us to know what "boinc" is?

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: Slow pipes after upgrade cygwin 1.5.12-1->1.5.13-1 when running boinc

[Bengt-Arne Fjellner]

Christopher Faylor skrev:
> On Thu, Mar 03, 2005 at 05:36:00PM +0100, Bengt-Arne Fjellner wrote:
>>With boinc running [EMAIL PROTECTED] at lowest priority ( uses 100% cpu but 
>>yields
>> easily)
>>simple pipes takes a long time.
>>Example: from a bash prompt
>>echo hello|grep -v xyz
>>with boinc running and 1.5.13-1 takes about 7 seconds.  if i stop boinc it 
>>takes
parts of a second.  after downgrade to 1.5.12-1 with boinc running: parts of a
second.
>>
>>i have seen this on two different computers one HT one normal.
>>
>>Single commands are still fast.
>
> Is there some reason why you'd expect us to know what "boinc" is?
>
> cgf
>

My stupidity i think...
Really its a community infrastructure for networked computing
"Berkeley Open Infrastructure for Network Computing"
http://boinc.berkeley.edu/

With currently this subproject running:
[EMAIL PROTECTED]
http://einstein.phys.uwm.edu/
Dont know if any other subprojects are affected.

-- 
Bengt-Arne Fjellner
0910-58 53 69




--
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: Slow pipes after upgrade cygwin 1.5.12-1->1.5.13-1 when running boinc

[Christopher Faylor]

On Thu, Mar 03, 2005 at 06:26:44PM +0100, Bengt-Arne Fjellner wrote:
>Christopher Faylor skrev:
>> On Thu, Mar 03, 2005 at 05:36:00PM +0100, Bengt-Arne Fjellner wrote:
>>>With boinc running [EMAIL PROTECTED] at lowest priority ( uses 100% cpu but 
>>>yields
>>> easily)
>>>simple pipes takes a long time.
>>>Example: from a bash prompt
>>>echo hello|grep -v xyz
>>>with boinc running and 1.5.13-1 takes about 7 seconds.  if i stop boinc
>>>it takes parts of a second.  after downgrade to 1.5.12-1 with boinc
>>>running: parts of a second.
>>>
>>>i have seen this on two different computers one HT one normal.
>>>
>>>Single commands are still fast.
>>
>> Is there some reason why you'd expect us to know what "boinc" is?
>
>My stupidity i think...
>Really its a community infrastructure for networked computing
>"Berkeley Open Infrastructure for Network Computing"
>http://boinc.berkeley.edu/
>
>With currently this subproject running:
>[EMAIL PROTECTED]
>http://einstein.phys.uwm.edu/
>Dont know if any other subprojects are affected.

If I had to guess, I'd say that boinc is putting itself into a high priority
class for some reason and is eating cpu cycles, causing cygwin's pipe reading
code to stall.

I've made a change to cygwin to put it's pipe reading code into a slightly
higher priority class.  This change is in the latest snapshot:

http://cygwin.com/snapshots/

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: Slow pipes after upgrade cygwin 1.5.12-1->1.5.13-1 when running boinc

[Morche Matthias]

[EMAIL PROTECTED] wrote:
...
> If I had to guess, I'd say that boinc is putting itself into a high
> priority class for some reason and is eating cpu cycles, causing
> cygwin's pipe reading code to stall.
> 
> I've made a change to cygwin to put it's pipe reading code into a
> slightly higher priority class.  This change is in the latest
> snapshot: 
> 
> http://cygwin.com/snapshots/
> 
> cgf

I think You're right. My problem with very slow startup and slow execution of 
"echo `echo 1`" went away when I stopped boinc...

  matthias

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Problem with bash under cygwin 1.5.13

[Dave Korn]

Original Message
>From: Andrew Waltman
>Sent: 03 March 2005 15:12

> Hi,
> 
> I frequently start multiple copies of bash at the same time when first
> logging in to my computer. As of the latest update of the cygwin package
> when I start more than one bash at the same time (without waiting for the
> prompt to appear in the first one) I get a stack dump in the second
> window: 
 
> andreww:~/p4/ex70 $ bash
> Exception: STATUS_ACCESS_VIOLATION at eip=61056D4D
> eax=42272844 ebx= ecx=0A03 edx= esi=0022E270
> edi=0A80
> ebp=0022E328 esp=0022E210 program=C:\cygwin\bin\bash.exe, pid 2696, thread
> main
> cs=001B ds=0023 es=0023 fs=0038 gs= ss=0023
> Stack trace:
> Frame Function  Args
> 0022E328  61056D4D  (0022E480, 0022E484, 0022E488, 0022E330)


[FAQ ENTRY Alert!]

  Don't even bother posting stackdump files.  They're of no use to anyone
else if you don't have debug info in your version of the cygwin dll, and if
you do then they're only of any direct use to you.

  If you _do_ have a debug version of the dll, then you can run "addr2line
--exe=/bin/cygwin1.dll", and cut and paste the second column of numbers
(under the "Function" header) into it when it's running; that will give you
references to the source code file and line of every function in the call
stack (but only from the point where your executable entered the cygwin dll;
not within the exe itself).

  If you don't have the .dll with debug info already in it (and the standard
cygwin install packages the .dll without debug info), it's a pretty hopeless
task to try rebuilding it with debug info enabled.  The chances of
everything being so exactly the same between builds that every function ends
up in the exact same memory location in the newly-built dll as it was
located at in the old dll are next to zero.  So there's absolutely no use in
showing those numbers to anyone else either.  The only way they could be
useful is to someone who had the exact same version of the .dll as you did,
only with debug info already in it.


> However, if I wait for eash instance of bash to come to a command prompt I
> can start the 2nd, 3rd, etc. bash window. This behavior started after
> updating the cygwin library to the latest revision (1.5.13).

  I'm running with current code (built from CVS earlier today) and I can't
reproduce this.  I can fire up a dozen or more windows simultaneously and
they all have no problems while running through their profile/.rc startup
scripts.


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: Slow pipes after upgrade cygwin 1.5.12-1->1.5.13-1 when running boinc

[Bengt-Arne Fjellner]

Christopher Faylor skrev:
> On Thu, Mar 03, 2005 at 06:26:44PM +0100, Bengt-Arne Fjellner wrote:
>>Christopher Faylor skrev:
>>> On Thu, Mar 03, 2005 at 05:36:00PM +0100, Bengt-Arne Fjellner wrote:
>>>>With boinc running [EMAIL PROTECTED] at lowest priority ( uses 100% cpu but 
>>>>yields
>>>> easily)
>>>>simple pipes takes a long time.
>>>>Example: from a bash prompt
>>>>echo hello|grep -v xyz
>>>>with boinc running and 1.5.13-1 takes about 7 seconds.  if i stop boinc
>>>>it takes parts of a second.  after downgrade to 1.5.12-1 with boinc
>>>>running: parts of a second.
>>>>
>>>>i have seen this on two different computers one HT one normal.
>>>>
>>>>Single commands are still fast.
>>>
>>> Is there some reason why you'd expect us to know what "boinc" is?
>>
>>My stupidity i think...
>>Really its a community infrastructure for networked computing
>>"Berkeley Open Infrastructure for Network Computing"
>>http://boinc.berkeley.edu/
>>
>>With currently this subproject running:
>>[EMAIL PROTECTED]
>>http://einstein.phys.uwm.edu/
>>Dont know if any other subprojects are affected.
>
> If I had to guess, I'd say that boinc is putting itself into a high priority
> class for some reason and is eating cpu cycles, causing cygwin's pipe reading
> code to stall.
>
> I've made a change to cygwin to put it's pipe reading code into a slightly
> higher priority class.  This change is in the latest snapshot:
>
> http://cygwin.com/snapshots/
>
> cgf
>

No change with cygwin1-20050303.dll.bz2 or cygwin-inst-20050303.tar.bz2

-- 
Bengt-Arne Fjellner
0910-58 53 69



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Problem with bash under cygwin 1.5.13

[Dave Korn]

Original Message
>From: Dave Korn
>Sent: 03 March 2005 17:48

> Original Message
>> From: Andrew Waltman
>> Sent: 03 March 2005 15:12


>> However, if I wait for eash instance of bash to come to a command prompt
>> I can start the 2nd, 3rd, etc. bash window. This behavior started after
>> updating the cygwin library to the latest revision (1.5.13).
> 
>   I'm running with current code (built from CVS earlier today) and I can't
> reproduce this.  I can fire up a dozen or more windows simultaneously and
> they all have no problems while running through their profile/.rc startup
> scripts.


 but perhaps it would be worthwhile to add the "-x" flag to the line in
your cygwin.bat that invokes bash, and see if they're all crashing at the
same point, and if we think there's anything special about what it's doing
at that time that might offer us some clues 



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/

chere doesn't cd to directory

[Wayne Johnson]

I just discovered chere.  I'd been using my own version called bash here, but
chere is so much easier to install.

One problem though.  Where I do the chere "Bash here" menu entry, it starts the
bash in the home directory.  I dug through the xhere script and found the
"export CHERE_DIR=`cygpath -u $2`" commented out.  If I comment it back in, I
get an error because the registry entry didn't pass in the directory name as $2.

WHat am I missing?

Thanks in advance.


--
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: Error linking under Cygwin: fork: can't reserve memory for stack XXX, Win32 error 487

[Martin Egholm Nielsen]

Hi,
However, as my application is growing in size (number of .o files) I
suddenly get the following fault message from collect2.exe when trying
to link them all together:
$ powerpc-405-linux-gnu-gcj --main=foo.Main *.o
C:\cygwin\opt\crosstool\powerpc-405-linux-gnu\gcc-3.4.0-glibc-2.2.5\libexec\gcc\powerpc-405-linux-gnu\3.4.0\collect2.exe
(1740): *** fork: can't reserve memory for stack 0x4 - 0x24,
Win32 error 487 

   --stack  Set size of the initial stack
   
Hum, these options are not available in my crosscompiler:
$ powerpc-405-linux-gnu-gcc -v --help 2>&1 | grep stack

You would need to add it to the CFLAGS when _building_ the crossbinutils
linker rather than to the command line when _using_ it, so that the compiled
crossversion of collect2 runs with a bigger stack.
  If indeed that is the underlying problem.
I suddenly ran into another problem today (after adding some more .o 
files) - bash reported that the argument line was too long. That is, the 
expansion of "*.o" was too large. Hence, I created a shell script that 
renamed all the .o files into incremental filenames: 1.o, 2.o, etc.
Then suddenly both problems vanished...
Weird?
Maybe the first problem was related to the fact that I almost ran into 
the "*.o" expansion-boundary?

BR,
 Martin
--
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: Slow pipes after upgrade cygwin 1.5.12-1->1.5.13-1 when running boinc

[David Rothenberger]

On 3/3/2005 8:36 AM, Bengt-Arne Fjellner wrote:
> With boinc running [EMAIL PROTECTED] at lowest priority ( uses 100% cpu but 
> yields easily)
> simple pipes takes a long time.
> Example: from a bash prompt
> echo hello|grep -v xyz
> with boinc running and 1.5.13-1 takes about 7 seconds.
> if i stop boinc it takes parts of a second.
> after downgrade to 1.5.12-1 with boinc running: parts of a second.
> 
> i have seen this on two different computers one HT one normal.

I was able to reproduce this without using BOINC.

I started two cmd.exe shells. In the first shell, I ran:

  sh -c 'nice -20 sh -c "while true; do :; done"'

Then, in the second cmd shell, I ran "sh" to start an ash shell I typed:

  echo hello | grep -v xyz

This takes several seconds to complete on a non-HT machine. It runs
quickly with 1.5.12.

I also noticed that if I ran

   sh -c 'echo hello | grep -v xyz'

from a cmd.exe shell, it completed quickly with 1.5.13.

The latest 20050303 snapshot fixed this problem for me. It also fixed
the problem I was having with BOINC.

-- 
David Rothenbergerspammer? -> [EMAIL PROTECTED]
GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734

To stand and be still,
At the Birkenhead drill,
Is a damned tough bullet to chew.
-- Rudyard Kipling


--
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: chere doesn't cd to directory

[Wayne Johnson]

Wayne Johnson  yahoo.com> writes:

> 
> One problem though.  Where I do the chere "Bash here" menu entry, it starts 
the
> bash in the home directory.  I dug through the xhere script and found the
> "export CHERE_DIR=`cygpath -u $2`" commented out.  If I comment it back in, I
> get an error because the registry entry didn't pass in the directory name as 
$2.

I just figured out what is wrong.  In /etc/profile I need to replace 
the line:

cd "$HOME"

with

[ -z "$CHERE_INVOKING" ] && cd "$HOME"


Whether this will fix it for all shells, I'm not sure.

Thanks for a great utility.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Problem with bash under cygwin 1.5.13

[Andrew Waltman]

>>> However, if I wait for eash instance of bash to come to a command prompt
>>> I can start the 2nd, 3rd, etc. bash window. This behavior started after
>>> updating the cygwin library to the latest revision (1.5.13).
>> 
>> I'm running with current code (built from CVS earlier today) and I can't
>> reproduce this.  I can fire up a dozen or more windows simultaneously and
>> they all have no problems while running through their profile/.rc startup
>> scripts.

>  but perhaps it would be worthwhile to add the "-x" flag to the line in
> your cygwin.bat that invokes bash, and see if they're all crashing at the
> same point, and if we think there's anything special about what it's doing
> at that time that might offer us some clues 

I'm not using the cygwin.bat to start bash, but that got me thinking that
the problem was probably getting tickled by something in my .bashrc. So I
removed everyting and started adding things until I got the error again. It
turned out to be caused by the version of keychain I was using
(2.3.0). Running that version of keychain twice at the same time resulted in
the same stack dump. I downloaded the latest version from Gentoo and it
does not error out AND is noticeably faster.

Thanks,
Andrew

--
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/

[ANNOUNCEMENT] New package: psmisc-21.5-1

[Corinna Vinschen]

I have uploaded psmisc-21.5-1.

The psmisc package contains utilities for managing processes on your
system: pstree, killall and fuser.  The pstree command displays a tree
structure of all of the running processes on your system.  The killall
command sends a specified signal (SIGTERM if nothing is specified) to
processes identified by name.  The fuser command identifies the PIDs of
processes that are using specified files or filesystems.


The Cygwin release has a couple of patches applied to get the tools
running.  Mainly all TCP and UDP search facilities in fuser have been
disabled.  pstree uses ASCII art automatically when TERM=cygwin.

Be aware that these tools use /proc to collect information, so they
don't interact with native Windows processes.

Note that I just added this package for fun.  In its current state it
doesn't build OOTB, but needs a Makefile tweak.  If you want to build
it from source, use the following configure command:

  ./configure \
--prefix=/usr \
--datadir=$(prefix)/share \
--mandir=$(prefix)/share/man \
--without-libiconv-prefix \
--without-libintl-prefix

then edit the "LIBS=" line in src/Makefile and set it to

  LIBS = -liconv -lintl

That's it.  Have fun.


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available  
starting at the above URL.

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:cygwin@cygwin.com
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: [SPAM] mkpasswd (249): [5] Access is denied. #workaround & speculation on cause

[Tom Rodman]

The workaround I'm considering is: to build a list of only the user logon names
we need for /etc/passwd (a fairly small subset of the domain), and then
write a shell script (driven by this list) to repeatedly call
"mkpasswd -l -d -u USERNAMEHERE >> /etc/passwd".

A co-worker speculates that Microsoft is "throttling" the queries to the
domain controller - allowing no more than 1500 or so account records at
a time; in order to prevent overloading the AD server.

I'd still be interested in what intelligent question I should ask of
our enterprise active directory admin though..

On Wed 3/2/05 14:03 CST Tom Rodman wrote:
> When running
> 
>   mkpasswd -l -d
> 
> I get the error:
> 
>   mkpasswd (249): [5] Access is denied.
> 
> See below bash session:
> 
>   [EMAIL PROTECTED] ~
>   $ date; uname -a
>   Wed Mar  2 10:37:14 CST 2005
>   CYGWIN_NT-5.2 c7mkes132 1.5.13(0.122/4/2) 2005-03-01 11:01 i686 unknown 
> unknown Cygwin
>   [EMAIL PROTECTED] ~
>   $ mkpasswd -l -d >/etc/passwd
>   mkpasswd (249): [5] Access is denied.
> 
>   [EMAIL PROTECTED] ~
>   $ echo $CYGWIN
>   binmode tty ntsec smbntsec
> 
> The command *does* list all local users ok ("mkpasswd -l" has no
> error), "mkpasswd -d" takes minutes to error out, but does output a
> substancial subset of the domain users.  I've also tried uninstalling
> cygwin and loading a much older version that I trust; I get the same
> error.
> 
> This is the *first* time I've installed cygwin in this particular
> active directory domain.  It works in two other active directory
> domains just fine.  I'm not a domain administrator  - what rights do I
> need ask our corporate admins to give my account so "mkpasswd -l -d"
> completes w/o error?  (I *am* a local administrator.)

--
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/

Problems instaling perl Net::Pcap module

[SonOfLilit]

I hope this is the right place to post this.

The steps I went through:
* d/l it
* extract
* cd to dir
* d/l WinPcap developer kit and put ./lib to my /lib/Pcap and ./include to my
/usr/include, without replacing 2-3 .h headers that I already had
* $ perl Makefile.PL INC=-I/usr/include LIBS=-L/lib/Pcap
Says that all is right
* $ make
Gives me tons of warnings and errors - the errors about undefined references to
many pcap related symbols like '_pcap_dump' in pcap.c, while processing 
*pcap.o*.

Clue anyone?

Errors:
'Pcap.o(.text+0x12b7):Pcap.c: undefined reference to `_pcap_open_live
'Pcap.o(.text+0x1764):Pcap.c: undefined reference to `_pcap_open_offline
'Pcap.o(.text+0x1b90):Pcap.c: undefined reference to `_pcap_dump_open
'Pcap.o(.text+0x2039):Pcap.c: undefined reference to `_pcap_loop
'Pcap.o(.text+0x2549):Pcap.c: undefined reference to `_pcap_dispatch
'Pcap.o(.text+0x28d4):Pcap.c: undefined reference to `_pcap_close
'Pcap.o(.text+0x2b14):Pcap.c: undefined reference to `_pcap_dump_close
'Pcap.o(.text+0x2dc9):Pcap.c: undefined reference to `_pcap_datalink
'Pcap.o(.text+0x3139):Pcap.c: undefined reference to `_pcap_snapshot
'Pcap.o(.text+0x34a9):Pcap.c: undefined reference to `_pcap_is_swapped
'Pcap.o(.text+0x3819):Pcap.c: undefined reference to `_pcap_major_version
'Pcap.o(.text+0x3b89):Pcap.c: undefined reference to `_pcap_minor_version
'Pcap.o(.text+0x3f00):Pcap.c: undefined reference to `_pcap_geterr
'Pcap.o(.text+0x41fe):Pcap.c: undefined reference to `_pcap_strerror
'Pcap.o(.text+0x46bf):Pcap.c: undefined reference to `_pcap_compile
'Pcap.o(.text+0x4ce7):Pcap.c: undefined reference to `_pcap_setfilter
'Pcap.o(.text+0x50a9):Pcap.c: undefined reference to `_pcap_fileno
'Pcap.o(.text+0x5400):Pcap.c: undefined reference to `_pcap_perror
'Pcap.o(.text+0x561c):Pcap.c: undefined reference to `_pcap_findalldevs
'Pcap.o(.text+0x59b6):Pcap.c: undefined reference to `_pcap_stats
'Pcap.o(.text+0x5df4):Pcap.c: undefined reference to `_pcap_file
'Pcap.o(.text+0x6438):Pcap.c: undefined reference to `_pcap_dump
'Pcap.o(.text+0x67dd):Pcap.c: undefined reference to `_pcap_next
collect2: ld returned 1 exit status 
perlld: *** system() failed to execute
gcc -shared -o  Pcap.dll -Wl,--out-implib=libPcap.dll.a -Wl,--export-all-symbols
\ Wl,--enable-auto-import -Wl,--stack,8388608-
s -L/usr/local/lib Pcap.o  /usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a-

make: *** [blib/arch/auto/Net/Pcap/Pcap.dll] Error 1 


--
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/

"cannot set time" - cvs checkout breaks after installing cygwin-1.5.13-1

[Jacek Piskozub]

Hi,
After installing cygwin-1.5.13-1 I cannot build Mozilla anymore. During 
updating the mozilla tree using cvs I receive "cannot set time" errors. 
The updated files have (wrongly) the current time, instead of the 
expected original timestamp when they were checked into the cvs tree. 
That would not be critical if the same error did not happen while 
building the build dependencies. This kills the compilation.

All this happens on Windows ME. The CVS I use is 1.11.17 (cygwin supplied).
The problem stopped after downgrading to cygwin-1.5.12-1.
Regards,
Jacek Piskozub

--
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: ctime: creation or change time?

[Eric Melski]

Corinna Vinschen wrote:
On Mar  2 13:19, [EMAIL PROTECTED] wrote:
In fact, NTFS has no notion of file change time as described in POSIX.  Is there
any chance of undoing this change?  An alternative solution might be to simply
use the NTFS file modify time for both the mtime and ctime of the file, since
those two are almost always updated together anyway.

Well, we're trying to be POSIX like, so that's nothing we're going to
revert.  I guess we're using ctime as change time even more in future.
I understand that you're trying to be POSIX-like, but I wonder if 
doing so at the cost of compatibility with the host OS is wise. 
To be sure, the implementation you have chosen will break some 
Windows applications.

It seems to me that ultimately you are emulating POSIX-like 
behavior on top of what is fundamentally NOT a POSIX-like system. 
 If that is so, then why not use a different implementation that 
is sure not to break existing non-Cygwin Windows applications? 
The proposal I made previously (report Windows modify time as 
both Cygwin mtime and ctime) would give Cygwin applications a 
reasonable approximation of ctime in the POSIX sense, while 
retaining a correct value of creation time for Windows applications.

Thanks,
Eric Melski
--
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: ctime: creation or change time?

[Christopher Faylor]

On Thu, Mar 03, 2005 at 03:50:56PM -0800, Eric Melski wrote:
>Corinna Vinschen wrote:
>>On Mar  2 13:19, [EMAIL PROTECTED] wrote:
>>>In fact, NTFS has no notion of file change time as described in POSIX.
>>>Is there any chance of undoing this change?  An alternative solution
>>>might be to simply use the NTFS file modify time for both the mtime and
>>>ctime of the file, since those two are almost always updated together
>>>anyway.
>>
>>Well, we're trying to be POSIX like, so that's nothing we're going to
>>revert.  I guess we're using ctime as change time even more in future.
>
>I understand that you're trying to be POSIX-like, but I wonder if doing
>so at the cost of compatibility with the host OS is wise.  To be sure,
>the implementation you have chosen will break some Windows
>applications.
>
>It seems to me that ultimately you are emulating POSIX-like behavior on
>top of what is fundamentally NOT a POSIX-like system.  If that is so,
>then why not use a different implementation that is sure not to break
>existing non-Cygwin Windows applications?  The proposal I made
>previously (report Windows modify time as both Cygwin mtime and ctime)
>would give Cygwin applications a reasonable approximation of ctime in
>the POSIX sense, while retaining a correct value of creation time for
>Windows applications.

Your arguments would be a little more persuasive if you did more than
postulate the surety of breakage and actually pointed to real breakage
or, at least, demonstrated how a windows application would be harmed by
cygwin's handling of ctime.

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: cron copy on network drives

[Pierre A. Humblet]

At 10:49 AM 3/3/2005 -0600, Bryan Thrall wrote:
>> From: Paul Hodor
>> Date: Thu, 3 Mar 2005 08:13:36 -0800 (PST)
>> 
>> Hi,
>> 
>> I am trying to set up a cron service to update some directories on a
>> network drive, but I ran into a problem.
>> 
>> This copy command works from the command-line:
>> cp -a -u -v //mydrive/myshare/dir1/* //mydrive/myshare/dir2 >> log 2>&1
>> 
>> However, if I run it with cron I get the following error:
>> cp: cannot stat `//mydrive/myshare/dir1/*': No such file or directory
>> 
>> Do I need to use a different syntax for the path or am I doing
>> something else wrong? I am running Windows XP Professional version 2002
>> SP1 and cygwin DLL version 1.5.12.
>> 
>> Thanks,
>> Paul
>> 
>
>I think I've run into this very problem. Are you running cron as a 
>different user than your login (such as SYSTEM)? My understanding is 
>that in that case, cron has a limited form of su which does not allow it 
>to fully authenticate as you when accessing network drives. So, it tries 
>to su to your login when it runs your cron job, but cannot read or write 
>to network drives you have mapped.
>
>Unfortunately, I don't know a workaround for this. You could have cron 
>map the network drive itself (using 'net use') but that would probably 
>require a password - in plain text! You could also run cron as yourself 
>so it actually uses your login (rather than trying to su), but that 
>means every time you login you have to start cron and it won't be 
>running after you log out!

Run /bin/cron-config . It will offer to run cron as a service under your
account. It will keep running after you log out.

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: ctime: creation or change time?

[Eric Melski]

Christopher Faylor wrote:
I understand that you're trying to be POSIX-like, but I wonder if doing
so at the cost of compatibility with the host OS is wise.  To be sure,
the implementation you have chosen will break some Windows
applications.
It seems to me that ultimately you are emulating POSIX-like behavior on
top of what is fundamentally NOT a POSIX-like system.  If that is so,
then why not use a different implementation that is sure not to break
existing non-Cygwin Windows applications?  The proposal I made
previously (report Windows modify time as both Cygwin mtime and ctime)
would give Cygwin applications a reasonable approximation of ctime in
the POSIX sense, while retaining a correct value of creation time for
Windows applications.

Your arguments would be a little more persuasive if you did more than
postulate the surety of breakage and actually pointed to real breakage
or, at least, demonstrated how a windows application would be harmed by
cygwin's handling of ctime.
The problem described in the following post to this mailing list 
earlier today sounds like it is caused by Cygwin's new treatment 
of ctime:

http://cygwin.com/ml/cygwin/2005-03/msg00165.html
Thanks,
Eric Melski
--
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/

1.5.13-1 setup does not complete

[N. Brad Garrett]

When I try to install the latest cygwin (this is my first time trying to 
install it), it downloads the list of mirrors fine. But then no matter 
which mirror I choose, it gets about 80% done before displaying this 
message in an alert box:

(null) line 6: syntax error, unexpected LT, expecting $end
It doesn't matter whether I try to install straight from internet or 
download first, the same thing happens. I looked on the mailing list, 
and could not find anyone having this problem when installing (there are 
similar problems after installing) so any help is appreciated.

--brad g.
--
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: ctime: creation or change time?

[Christopher Faylor]

On Thu, Mar 03, 2005 at 05:14:28PM -0800, Eric Melski wrote:
>Christopher Faylor wrote:
>
>>>I understand that you're trying to be POSIX-like, but I wonder if doing
>>>so at the cost of compatibility with the host OS is wise.  To be sure,
>>>the implementation you have chosen will break some Windows
>>>applications.
>>>
>>>It seems to me that ultimately you are emulating POSIX-like behavior on
>>>top of what is fundamentally NOT a POSIX-like system.  If that is so,
>>>then why not use a different implementation that is sure not to break
>>>existing non-Cygwin Windows applications?  The proposal I made
>>>previously (report Windows modify time as both Cygwin mtime and ctime)
>>>would give Cygwin applications a reasonable approximation of ctime in
>>>the POSIX sense, while retaining a correct value of creation time for
>>>Windows applications.
>>
>>
>>Your arguments would be a little more persuasive if you did more than
>>postulate the surety of breakage and actually pointed to real breakage
>>or, at least, demonstrated how a windows application would be harmed by
>>cygwin's handling of ctime.
>
>The problem described in the following post to this mailing list 
>earlier today sounds like it is caused by Cygwin's new treatment 
>of ctime:
>
>http://cygwin.com/ml/cygwin/2005-03/msg00165.html

Since the CVS in question is a cygwin version, if this really is a
problem with ctime then it seems rather strange that cygwin's attempts
to behave more like POSIX would break a utility which relies on that
very behavior.

In any event, this isn't the postulated problem with a native windows
application.

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: cygstart patch

[Charles Wilson]

Anthony --
I've applied this patch.  Thanks!
--
Chuck
Derosa, Anthony CIV NAVAIR 2035, 2, 205/214 wrote:
But there is an important _process_ problem.  It is the 
number one sin of CVS to checkin anything
other than ***exactly*** the code that you compiled and tested, so you
aren't excused from having to re-compile and re-test the code 
with the +1 = +2 modification applied to it, and at that point 
you may as well re-generate the diff.

Per Dave's advice, here is the regenerated patch (re-compiled 
and re-tested code) for cygstart.
--
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: Buiding net-snmp perl in cygwin - Please anyone help me

[Aparna R]

Hello,

Currently I uninstalled activeperl and I am having cygwin perl alone and
correspondingly I changed the Path variable to D:\cygwin\bin.

Herewith I am attcahing the output of "perl Makefile.PL", "make" and
"cygcheck -svr"

$cd net-snmp5.2.1/perl
$perl Makefile.PL

Writing Makefile for NetSNMP::default_store
Writing Makefile for NetSNMP::ASN
Writing Makefile for NetSNMP::OID
Note (probably harmless): No library found for -liphlpapi
Writing Makefile for NetSNMP::agent::default_store
Writing Makefile for NetSNMP::agent
Writing Makefile for SNMP
Warning: prerequisite NetSNMP::OID 5.1 not found.
Writing Makefile for NetSNMP::TrapReceiver
Writing Makefile for Bundle::NetSNMP


--
$make

make[1]: Entering directory `/cygdrive/d/net-snmp-5.2.1/perl/default_store'
gcc -c   -g -O2 -Dcygwin -I. -I/usr/local/include -DPERL_USE_SAFE_PUTENV -fn
o-st
rict-aliasing -pipe -I/usr/local/include -DUSEIMPORTLIB -O3   -DVERSION=\"5.
2.1\
" -DXS_VERSION=\"5.2.1\"  "-I/usr/lib/perl5/5.8/cygwin/CORE"
default_store.c
Running Mkbootstrap for NetSNMP::default_store ()
chmod 644 default_store.bs
rm -f ../blib/arch/auto/NetSNMP/default_store/default_store.dll
LD_RUN_PATH="" ld2  -s -L/usr/local/lib default_store.o  -o
../blib/arch/auto/Ne
tSNMP/default_store/default_store.dll
/usr/lib/perl5/5.8/cygwin/CORE/libperl.dl
l.a -L/usr/local/lib -lnetsnmp -lm
gcc -shared -o
 default_store.dll -Wl,--out-implib=libdefault_store.dll.a -Wl,--
export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \
-s -L/usr/local/lib default_store.o
/usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.
a -L/usr/local/lib -lnetsnmp -lm
Creating library file: libdefault_store.dll.a
mv default_store.dll libdefault_store.dll.a
../blib/arch/auto/NetSNMP/default_st
ore/
chmod 755 ../blib/arch/auto/NetSNMP/default_store/default_store.dll
cp default_store.bs ../blib/arch/auto/NetSNMP/default_store/default_store.bs
chmod 644 ../blib/arch/auto/NetSNMP/default_store/default_store.bs
make[1]: Leaving directory `/cygdrive/d/net-snmp-5.2.1/perl/default_store'
make[1]: Entering directory `/cygdrive/d/net-snmp-5.2.1/perl/ASN'
gcc -c   -g -O2 -Dcygwin -I. -I/usr/local/include -DPERL_USE_SAFE_PUTENV -fn
o-st
rict-aliasing -pipe -I/usr/local/include -DUSEIMPORTLIB -O3   -DVERSION=\"5.
2.1\
" -DXS_VERSION=\"5.2.1\"  "-I/usr/lib/perl5/5.8/cygwin/CORE"   ASN.c
Running Mkbootstrap for NetSNMP::ASN ()
chmod 644 ASN.bs
rm -f ../blib/arch/auto/NetSNMP/ASN/ASN.dll
LD_RUN_PATH="" ld2  -s -L/usr/local/lib ASN.o  -o
../blib/arch/auto/NetSNMP/ASN/
ASN.dll
 /usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a -L/usr/local/lib -lnetsnmp
 -lm
gcc -shared -o
 ASN.dll -Wl,--out-implib=libASN.dll.a -Wl,--export-all-symbols -
Wl,--enable-auto-import -Wl,--stack,8388608 \
-s -L/usr/local/lib ASN.o
 /usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a -L/usr/l
ocal/lib -lnetsnmp -lm
Creating library file: libASN.dll.a
mv ASN.dll libASN.dll.a ../blib/arch/auto/NetSNMP/ASN/
chmod 755 ../blib/arch/auto/NetSNMP/ASN/ASN.dll
cp ASN.bs ../blib/arch/auto/NetSNMP/ASN/ASN.bs
chmod 644 ../blib/arch/auto/NetSNMP/ASN/ASN.bs
make[1]: Leaving directory `/cygdrive/d/net-snmp-5.2.1/perl/ASN'
make[1]: Entering directory `/cygdrive/d/net-snmp-5.2.1/perl/OID'
gcc -c   -g -O2 -Dcygwin -I. -I/usr/local/include -DPERL_USE_SAFE_PUTENV -fn
o-st
rict-aliasing -pipe -I/usr/local/include -DUSEIMPORTLIB -O3   -DVERSION=\"5.
2.1\
" -DXS_VERSION=\"5.2.1\"  "-I/usr/lib/perl5/5.8/cygwin/CORE"   OID.c
Running Mkbootstrap for NetSNMP::OID ()
chmod 644 OID.bs
rm -f ../blib/arch/auto/NetSNMP/OID/OID.dll
LD_RUN_PATH="" ld2  -s -L/usr/local/lib OID.o  -o
../blib/arch/auto/NetSNMP/OID/
OID.dll
 /usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a -L/usr/local/lib -lnetsnmp
 -lm
gcc -shared -o
 OID.dll -Wl,--out-implib=libOID.dll.a -Wl,--export-all-symbols -
Wl,--enable-auto-import -Wl,--stack,8388608 \
-s -L/usr/local/lib OID.o
 /usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a -L/usr/l
ocal/lib -lnetsnmp -lm
Creating library file: libOID.dll.a
mv OID.dll libOID.dll.a ../blib/arch/auto/NetSNMP/OID/
chmod 755 ../blib/arch/auto/NetSNMP/OID/OID.dll
cp OID.bs ../blib/arch/auto/NetSNMP/OID/OID.bs
chmod 644 ../blib/arch/auto/NetSNMP/OID/OID.bs
make[1]: Leaving directory `/cygdrive/d/net-snmp-5.2.1/perl/OID'
make[1]: Entering directory `/cygdrive/d/net-snmp-5.2.1/perl/agent'
make[2]: Entering directory
`/cygdrive/d/net-snmp-5.2.1/perl/agent/default_store
'
gcc -c   -g -O2 -Dcygwin -I. -I/usr/local/include -DPERL_USE_SAFE_PUTENV -fn
o-st
rict-aliasing -pipe -I/usr/local/include -DUSEIMPORTLIB -O3   -DVERSION=\"5.
2.1\
" -DXS_VERSION=\"5.2.1\"  "-I/usr/lib/perl5/5.8/cygwin/CORE"
default_store.c
Running Mkbootstrap for NetSNMP::agent::default_store ()
chmod 644 default_store.bs
rm -f ../../blib/arch/auto/NetSNMP/agent/default_store/default_store.dll
LD_RUN_PATH="" ld2  -s -L/usr/local/lib default_store.o  -o
../../blib/arch/auto
/NetSNMP/agent/default_store/defaul

Re: ctime: creation or change time?

[Eric Melski]

Christopher Faylor wrote:
Your arguments would be a little more persuasive if you did more than
postulate the surety of breakage and actually pointed to real breakage
or, at least, demonstrated how a windows application would be harmed by
cygwin's handling of ctime.
The motivating example for my original query is my own 
application, which includes a file access monitoring and 
reporting component.  "Incidental" modifications to file 
attributes, such as the change to modification time that occurs 
as a side-effect of writing to a file, are exluded from the 
reports because they are not interesting for my purposes. 
Logically, setting the ctime as Cygwin now does is such an 
"incidental" modification, in that it is not explicitly requested 
by the user.  However, there is no way for me to distinguish 
those changes from actual explicit modifications to ctime by the 
user.  My application is not "broken" per se, but this change in 
behavior leads to a large volume of noise in my file operation 
logs, significantly reducing their utility.  I can likely code 
around this, but because it seemed to me a clear incompatibility 
with the defined semantics of NTFS, I thought it worth the time 
to inquire.

Another application that may be affected by this change is 
native-Win32 gmake, which uses file ctimes in some fashion when 
constructing hash tables of directory contents.  I readily admit 
that I do not understand that code well enough at the moment to 
say with absolute certainty that the change in Cygwin behavior 
will adversely affect that program.

Thanks,
Eric Melski
--
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 a Shared Library using Makefile

[Pradip Jadav]

And ya "Dllexport and Dllimport"  are required in source code I
mean should include in my own header files?
I read that 

""The main problems are caused by the fact that Windows DynamicLinked
Libraries (DLL s) assume some specific information to be introduced in
the source code directly, while the UNIX DynamicLinked share Libraries
don t need any "special information" in the source""

so i have to change source code ???I mean have to add "special
information" like  Dllexport and Dllimport ???

waiting for reply...


On Thu, 27 Jan 2005 09:57:46 -0500 (EST), Igor Pechtchanski
<[EMAIL PROTECTED]> wrote:
> On Thu, 27 Jan 2005, Igor Pechtchanski wrote:
> 
> > On Thu, 27 Jan 2005, Brian Dessent wrote:
> >
> > > Pradip Jadav wrote:
> > >
> > > > example.dll : example.c
> > > > ${CXX} $< ${CXXFLAGS} -shared -fPIC -L. -lexample
> -Wl,-soname,$@ -o $@
> > >
> > > You shouldn't use "-fPIC" or "-Wl,soname" as far as I know.
> >
> > -fPIC is ignored (and there's a warning about it), and -Wl,soname is
> > redundant but harmless, AFAIK.  Another option that might help is
> > -Wl,-out-implib,[EMAIL PROTECTED], so that the DLL can be linked with via 
> > an import
>   
> Make that -Wl,--out-implib,[EMAIL PROTECTED] (I thought I'd checked it before 
> sending
> off the e-mail, but apparently not).
> 
> > library later.
> > Igor
> 
> -- 
>   http://cs.nyu.edu/~pechtcha/
>   |\  _,,,---,,_  [EMAIL PROTECTED]
> ZZZzz /,`.-'`'-.  ;-;;,_  [EMAIL PROTECTED]
>  |,4-  ) )-,_. ,\ (  `'-' Igor Pechtchanski, Ph.D.
> '---''(_/--'  `-'\_) fL   a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
> 
> "The Sun will pass between the Earth and the Moon tonight for a total
> Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
> 
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:   http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/
> 
> 

-- 
With Best Regards
Pradip K. Jadav

--
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 a Shared Library using Makefile

[Brian Dessent]

Pradip Jadav wrote:

> And ya "Dllexport and Dllimport"  are required in source code I
> mean should include in my own header files?
> I read that 
> 
> ""The main problems are caused by the fact that Windows DynamicLinked
> Libraries (DLL s) assume some specific information to be introduced in
> the source code directly, while the UNIX DynamicLinked share Libraries
> don t need any "special information" in the source""
> 
> so i have to change source code ???I mean have to add "special
> information" like  Dllexport and Dllimport ???

Did you actually read the replies the first time you posted this or are
you just hoping that somehow magically someone will be able to help you?

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: Keeping cygwin updated on remote systems

[DePriest, Jason R.]

Remote Desktop is not available on them.

I can already use VNC tunneled through SSH to manually run setup.exe.

What I really need is a way to update the files that have changed and
run the install scripts without running setup.exe.

-Jason


On Wed, 2 Mar 2005 22:24:50 -0600 (CST), Satish Balay  wrote:
> > On Wed, 2 Mar 2005, DePriest, Jason R. wrote:
> >
> > > I also tunnel VNC through SSH to get a remote desktop when necessary.
> > >
> > > My problem is: how do I keep these systems updated since my only
> > > access is through the components I need to update?
> 
> is 'remote desktop' also disabled on these machines? I tunnel it
> through ssh [via a different box] - and update cygwin via setup.exe
> 
> Satish
> 
> --

--
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: Keeping cygwin updated on remote systems

[Brian Dessent]

"DePriest, Jason R." wrote:
> 
> Remote Desktop is not available on them.
> 
> I can already use VNC tunneled through SSH to manually run setup.exe.
> 
> What I really need is a way to update the files that have changed and
> run the install scripts without running setup.exe.

You can google/search archives for "cygupdate" which is a set of tools
written by cgf that more or less performs the setup.exe tasks using a
set of sequestered utils (cygwin1.dll, gzip, bzip2, tar, perl, cygz.dll)
to perform the same tasks.  However, it's unsupported and you're likely
to encounter issues getting it to work seeing as the "upset" CVS dir
(containing the Setup.pm module) was removed from general availabilty. 
If you ask on the list for help in getting it to work you're likely to
invoke the "he's just mean" ire of Christopher. :-)

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: ctime: creation or change time? & "cannot set time" error

[Jacek Piskozub]

The problem described in the following post to this mailing list 
earlier today sounds like it is caused by Cygwin's new treatment 
of ctime:

   http://cygwin.com/ml/cygwin/2005-03/msg00165.html
Since the CVS in question is a cygwin version, if this really is a
problem with ctime then it seems rather strange that cygwin's attempts
to behave more like POSIX would break a utility which relies on that
very behavior.
In any event, this isn't the postulated problem with a native windows
application.
cgf
Well, whatever it is, this "non problem" of yours makes it impossible to 
build Mozilla with win32.

At least on FAT32 which I use. I mention as everyone is talking only 
about NTFS.

Jacek
--
Linux is still considered risky by the uneducated.
 Groklaw, February 20 2004
--
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: "cannot set time" on FAT32 - after installing cygwin-1.5.13-1

[Jacek Piskozub]

After installing cygwin-1.5.13-1 I cannot build Mozilla anymore. 
During updating the mozilla tree using cvs I receive "cannot set time" 
errors. The updated files have (wrongly) the current time, instead of 
the expected original timestamp when they were checked into the cvs 
tree. That would not be critical if the same error did not happen 
while building the build dependencies. This kills the compilation.

All this happens on Windows ME. The CVS I use is 1.11.17 (cygwin 
supplied).

The problem stopped after downgrading to cygwin-1.5.12-1.

I'll add that obviously Windows ME I use implies FAT32. I believe this 
is a ctime <-> FAT problem.

Jacek
--
Linux is still considered risky by the uneducated.
 Groklaw, February 20 2004
--
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/