Re: Windows Update hosed Cygwin

[Teun Burgers]

Hugh D. Hyatt wrote:
Yesterday I installed several Win98 updates from the microsoft.com web
site.  After re-booting (gr!) Cygwin, Firefox and Thunderbird all
gave fatal exception 0D at :0001.  After uninstalling those I was
able to, everything was back to normal.  Here are the updates I installed
and then uninstalled:
Mapped Drives Shutdown Update
Root Certificates Update
Windows Critical Update Notification 4.0
Security Update for Windows 98 (KB891781)
Security Update for Windows 98 (KB891711)
Security Update for Windows 98 (KB888113)
Cumulative Security Update for Internet Explorer 6 Service Pack 1 
(KB867282)
If I go back and trying applying them one at a time until I discover
which one caused the trouble, I'll post a follow-up.
I had the same problem. The culprit is KB891711.
Googling for kb891711 and windows 98 will give more information.
Has nothing to do with cygwin.
Teun
--
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 including float.h with gcc -mno-cygwin

[Paul Stodghill]

Argh. I didn't proofread my post. Sorry about that. Here is how it 
should have read.

[The fact that the cygwin compiler path appears on the search path] is a 
different and unrelated problem, I think.

barney-xp$ md5sum /usr/lib/gcc-lib/*/3.3.3/include/float.h
248cb979b88c788e88100b913eea6ce9 
*/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/include/float.h
248cb979b88c788e88100b913eea6ce9 
*/usr/lib/gcc-lib/i686-pc-mingw32/3.3.3/include/float.h
barney-xp$

The bug that I am observing is that /usr/i686-pc-mingw32/include needs 
to appear on the search path before any of the /usr/lib/gcc-lib include 
files.

Thanks.
Christopher Faylor wrote:
Uh.  Huh?  There is not supposed to be any cygwin include directory in
the search path when -mno-cygwin is used.  Hence the name.
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/
 

--
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 including float.h with gcc -mno-cygwin (Danny can you comment?)

[Christopher Faylor]

On Sat, Mar 19, 2005 at 11:14:04AM -0500, Paul Stodghill wrote:
>Argh. I didn't proofread my post. Sorry about that. Here is how it 
>should have read.
>
>[The fact that the cygwin compiler path appears on the search path] is a 
>different and unrelated problem, I think.
>
>barney-xp$ md5sum /usr/lib/gcc-lib/*/3.3.3/include/float.h
>248cb979b88c788e88100b913eea6ce9 
>*/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/include/float.h
>248cb979b88c788e88100b913eea6ce9 
>*/usr/lib/gcc-lib/i686-pc-mingw32/3.3.3/include/float.h
>barney-xp$
>
>The bug that I am observing is that /usr/i686-pc-mingw32/include needs 
>to appear on the search path before any of the /usr/lib/gcc-lib include 
>files.

That would make mingw unlike every other compiler out there.  Try it on
linux and you can see that the gcc library includes are supposed to be
first.  Putting them second would screw up other things.

Danny, are you reading 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/

Re: 1.5.13-1 rsync data corruption

[Wayne Davison]

[Please CC me on any replies -- thanks.]

On Mon, Mar 14, 2005 at 08:20:57PM -0600, Keith Moore wrote:
> subsequent incremental backups fail on certain large files when
> compression (-z) is enabled.  So far, the problem only appears when
> making incremental backups of VMware virtual disk images. Note that
> these images are large (exactly 4G each)

There is a fix in the upcoming 2.6.4 for the -z option of rsync when
transferring large files (those whose blocksize go past 64K).  If you
can, build either the 2.6.4pre3 release (listed on the web site) or the
latest nightly tar file (which has a couple extra minor fixes in it):

http://rsync.samba.org/ftp/rsync/nightly/rsync-HEAD-20050319-1628GMT.tar.gz

It is the sending side that needs to have this fixed version (if you
can't apply it to both sides).  I would appreciate knowing if that
fixes the problem for you.

..wayne..

--
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 including float.h with gcc -mno-cygwin (Danny can you comment?)

[Paul Stodghill]

CYGWIN != LINUX Oh, wait, this isn't cygwin-talk. Sorry...
There appears to be a conflicting contraints between mingw and 
gcc-mingw. The float.h provided by mingw definitely assumes that it will 
be included before the compiler provided float.h.

I am able to compile my app successfully by hardcoding the #include 
directive so that it picks up the mingw version of float.h first.

There may be some problems with some other files, but I do not know,
barney-xp$ /bin/ls /usr/lib/gcc-lib/i686-pc-mingw32/3.3.3/include > gcc.lst
barney-xp$ /bin/ls /usr/include/mingw > mingw.lst
barney-xp$ comm -12 gcc.lst mingw.lst
float.h
limits.h
stdarg.h
stddef.h
varargs.h
barney-xp$
Christopher Faylor wrote:
On Sat, Mar 19, 2005 at 11:14:04AM -0500, Paul Stodghill wrote:
 

Argh. I didn't proofread my post. Sorry about that. Here is how it 
should have read.

[The fact that the cygwin compiler path appears on the search path] is a 
different and unrelated problem, I think.

barney-xp$ md5sum /usr/lib/gcc-lib/*/3.3.3/include/float.h
248cb979b88c788e88100b913eea6ce9 
*/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/include/float.h
248cb979b88c788e88100b913eea6ce9 
*/usr/lib/gcc-lib/i686-pc-mingw32/3.3.3/include/float.h
barney-xp$

The bug that I am observing is that /usr/i686-pc-mingw32/include needs 
to appear on the search path before any of the /usr/lib/gcc-lib include 
files.
   

That would make mingw unlike every other compiler out there.  Try it on
linux and you can see that the gcc library includes are supposed to be
first.  Putting them second would screw up other things.
Danny, are you reading 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/
 

--
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: linking WXVTK with CYGWIN (Attn: stale FAQ entry)

[Joshua Daniel Franklin]

On Fri, 18 Mar 2005 10:33:22 -0500 (EST), Igor Pechtchanski wrote:
> Does  help (actually, the part
> about libm is out of date[*], but the missing main() still applies). 

So it no longer matters where you put the -lm?

--
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: linking WXVTK with CYGWIN (Attn: stale FAQ entry)

[Christopher Faylor]

On Sat, Mar 19, 2005 at 10:31:33AM -0800, Joshua Daniel Franklin wrote:
>On Fri, 18 Mar 2005 10:33:22 -0500 (EST), Igor Pechtchanski wrote:
>> Does  help (actually, the part
>> about libm is out of date[*], but the missing main() still applies). 
>
>So it no longer matters where you put the -lm?

libm.a hasn't been a symlink for quite a while.  It still matters where
you put it, though.

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/

bug in /etc/profile?

[Steven Boothe]

Hello all:
I'm not sure if this is a bug or not, but I have managed to determine that 
/etc/profile generates a rather curious environment variable:

typing set from a command prompt:
[EMAIL PROTECTED] ~
$ set
...
USERPROFILE='C:\Documents and Settings\noone'
VERSION=3.0.1
WINDIR='C:\WINDOWS'
_=/home/noone/.bashrc
f=
[EMAIL PROTECTED] ~
$
I was able to narrow down the cause to this code here in /etc/profile:

# Run all of the profile.d scripts
# Note that these are supplied by separate packages
# Ascending alphanumerical order enforced
if [ -d "/etc/profile.d" ]; then
while read f; do
if [ -f "${f}" ]; then
. "${f}"
fi
done <<- EOF
`/bin/find /etc/profile.d -iname '*.sh' -type f | sort`
EOF
fi

Now just so all my steps are known, to test this I emptied the /etc/profile.d 
directory and started cygwin and the environment variable was still there on 
start. However if I commented out this section it would go away.

Now as far as I can tell from the code in /etc/profile I couldn't see any 
glaring syntax errors so I'm not sure this is a bug or a feature? :) Maybe I 
should just enter what I've written here in the bug database and let it 
become checked and closed if that is indeed just a feature or something.

I am still trying to track down what is causing the other variable:
_=/home/noone/.bashrc
--
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: bug in /etc/profile?

[Christopher Faylor]

On Sat, Mar 19, 2005 at 11:03:03AM -0800, Steven Boothe wrote:
>I'm not sure if this is a bug or not, but I have managed to determine
>that /etc/profile generates a rather curious environment variable:
>
>typing set from a command prompt:
>
>[EMAIL PROTECTED] ~ $ set

'set' does not display environment variables.  Use 'env' for that.

>I am still trying to track down what is causing the other variable:
>_=/home/noone/.bashrc

Typing "man bash" and then /_ followed by a bunch of 'n's will
enlighten you about where the '_' comes from.
--
Christopher Faylor  spammer? -> [EMAIL PROTECTED]
Cygwin Co-Project Leader[EMAIL PROTECTED]
TimeSys, 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: bug in /etc/profile?

[Steven Boothe]

Christopher Faylor wrote:
On Sat, Mar 19, 2005 at 11:03:03AM -0800, Steven Boothe wrote:
I'm not sure if this is a bug or not, but I have managed to determine
that /etc/profile generates a rather curious environment variable:
typing set from a command prompt:
[EMAIL PROTECTED] ~ $ set
'set' does not display environment variables.  Use 'env' for that.
Maybe you mean it doesn't 'only' display environment variables, because it 
sure prints out a great amount of the same stuff env does (PATH, etc). But, 
it does not print out the dreaded 'f=' that using 'set' does. So that is a 
happy revelation. However, it is curious that this little value only shows up 
using 'set' while cygwin is running...

Anyway, having been enlightened I will look forward to using 'env' to check 
what environment variables are in memory now.

I am still trying to track down what is causing the other variable:
_=/home/noone/.bashrc

Typing "man bash" and then /_ followed by a bunch of 'n's will
enlighten you about where the '_' comes from.
Thanks. I feel much better now. :)
Cheers!
--
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/

ifconfig

[Auteria Wally Winzer Jr.]

Where can I find the pre-existing/bundled Cygwin
package that has the tool "ifconfig"?
 
Regards,
Auteria W. Winzer Jr.

--
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: 1.5.13-1 rsync data corruption

[Keith Moore]

Wayne Davison wrote:

> There is a fix in the upcoming 2.6.4 for the -z option of rsync when
> transferring large files (those whose blocksize go past 64K).  If you
> can, build either the 2.6.4pre3 release (listed on the web site) or the
> latest nightly tar file (which has a couple extra minor fixes in it):
> 
> http://rsync.samba.org/ftp/rsync/nightly/rsync-HEAD-20050319-1628GMT.tar.gz
> 
> It is the sending side that needs to have this fixed version (if you
> can't apply it to both sides).  I would appreciate knowing if that
> fixes the problem for you.

I'll give it a shot tonight.

Thanks,
KM


--
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 including float.h with gcc -mno-cygwin (Danny can you comment?)

[Danny Smith]

cgf wrote:
>On Sat, Mar 19, 2005 at 11:14:04AM -0500, Paul Stodghill wrote:
>>
>>[The fact that the cygwin compiler path appears on the search path] is a
>>different and unrelated problem, I think.
>>
>>barney-xp$ md5sum /usr/lib/gcc-lib/*/3.3.3/include/float.h
>>248cb979b88c788e88100b913eea6ce9
>>*/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/include/float.h
>>248cb979b88c788e88100b913eea6ce9
>>*/usr/lib/gcc-lib/i686-pc-mingw32/3.3.3/include/float.h
>>barney-xp$
>>
>>The bug that I am observing is that /usr/i686-pc-mingw32/include needs
>>to appear on the search path before any of the /usr/lib/gcc-lib include
>>files.
>
>That would make mingw unlike every other compiler out there.  Try it on
>linux and you can see that the gcc library includes are supposed to be
>first.  Putting them second would screw up other things.
>
>Danny, are you reading this?

On native mingw build I get this:

#include "..." search starts here:
#include <...> search starts here:
 D:/MINGW/BIN/../lib/gcc/mingw32/3.4.3/../../../../include
 D:/MINGW/BIN/../lib/gcc/mingw32/3.4.3/include
 D:/MINGW/BIN/../lib/gcc/mingw32/3.4.3/../../../../mingw32/include
 /mingw/lib/gcc/mingw32/3.4.3/../../../../include
 /mingw/include
 /mingw/lib/gcc/mingw32/3.4.3/include
 /mingw/lib/gcc/mingw32/3.4.3/../../../../mingw32/include
 /mingw/include
End of search list.


As far as I can remember  (gcc 2.95.3)  the mingw include dir has preceded the
gcc include dir.
Danny

>
>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: Problem including float.h with gcc -mno-cygwin (Danny can you comment?)

[Christopher Faylor]

On Sun, Mar 20, 2005 at 09:21:42AM +1200, Danny Smith wrote:
>On native mingw build I get this:
>
>#include "..." search starts here:
>#include <...> search starts here:
> D:/MINGW/BIN/../lib/gcc/mingw32/3.4.3/../../../../include
> D:/MINGW/BIN/../lib/gcc/mingw32/3.4.3/include
> D:/MINGW/BIN/../lib/gcc/mingw32/3.4.3/../../../../mingw32/include
> /mingw/lib/gcc/mingw32/3.4.3/../../../../include
> /mingw/include
> /mingw/lib/gcc/mingw32/3.4.3/include
> /mingw/lib/gcc/mingw32/3.4.3/../../../../mingw32/include
> /mingw/include
>End of search list.
>
>As far as I can remember  (gcc 2.95.3)  the mingw include dir has preceded the
>gcc include dir.

In the above, the mingw directory is intermixed multiple times with the
gcc include directory.  Unless I'm missing something, if cygwin and
linux are any indication, that's sort of unusual.

So, anyway, since I don't see Gerrit chiming in to vow to fix this bug, it
seems like the answer to the bug report is to use the mingw compiler.

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: linking WXVTK with CYGWIN (Attn: stale FAQ entry)

[Joshua Daniel Franklin]

On Sat, 19 Mar 2005 13:58:27 -0500, Christopher Faylor wrote:
> On Sat, Mar 19, 2005 at 10:31:33AM -0800, Joshua Daniel Franklin wrote:
> >On Fri, 18 Mar 2005 10:33:22 -0500 (EST), Igor Pechtchanski wrote:
> >> Does  help (actually, the part
> >> about libm is out of date[*], but the missing main() still applies).
> >
> >So it no longer matters where you put the -lm?
> 
> libm.a hasn't been a symlink for quite a while.  It still matters where
> you put it, though.

OK, I just deleted the line about libm.a being a symlink.

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

somewhat handy search page

[Joshua Daniel Franklin]

I've seen a few posts mention the using Google's advanced search features
to search the Cygwin website. I do this all the time and got a little tired of
typing the same things a lot, so I made the attached HTML page. 

It also includes some JavaScript code I've messed around with to use Google's
"daterange:" function which is occasionally useful but often not. The
main problem
is that daterange only takes account of the date Google indexed pages, not when 
they were created. If you don't use JavaScript the rest of the search
form still works.

See http://cygwin.com/ml/cygwin/2005-03/msg00763.html


cygwin-search.html.gz
Description: GNU Zip compressed data
--
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: ifconfig

[Joshua Daniel Franklin]

On Sat, 19 Mar 2005 12:38:05 -0800 (PST), Auteria Wally Winzer Jr.  wrote:
> Where can I find the pre-existing/bundled Cygwin
> package that has the tool "ifconfig"?

Since ifconfig is specific to linux, you won't find it in Cygwin. Use
Windows tools like ipconfig instead.

--
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: somewhat handy search page

[Brian Dessent]

Joshua Daniel Franklin wrote:
> 
> I've seen a few posts mention the using Google's advanced search features
> to search the Cygwin website. I do this all the time and got a little tired of
> typing the same things a lot, so I made the attached HTML page.
> 
> It also includes some JavaScript code I've messed around with to use Google's
> "daterange:" function which is occasionally useful but often not. The
> main problem
> is that daterange only takes account of the date Google indexed pages, not 
> when
> they were created. If you don't use JavaScript the rest of the search
> form still works.

For whatever reason, I have found that recently Google has indexed the
Cygwin ML archives under the sources.redhat.com domain and not under the
cygwin.com domain.  Compare the two following search results:

http://www.google.com/search?q=inurl%3Acygwin.com%2Fml%2F+ifconfig+site%3Acygwin.com
http://www.google.com/search?q=inurl%3Acygwin.com%2Fml%2F+ifconfig+site%3Asources.redhat.com

(I just picked ifconfig as a recent keyword.)  On the first one you only
get hits that happened to match text in attachments, on the second you
get mailing list posts.

Also, you can use e.g. "inurl:2004" for more effective date searches
compared to "date:", since the URL of the ML archives contains
"-mm", although I am not sure if "-" is allowed as a valid character
in an "inurl:".  But, you can use more than one "inurl:" in a search, so
"inurl:2004 inurl:10" should help to limit to october 2004.

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/

FTP Problems --- Can't type password

[Auteria Wally Winzer Jr.]

Everytime I try to ftp to a server when I attempt to
type any password a new line magically happens the
moment I touch any key on the keypad.  Can someone
assist in fixing this problem? (Cygwin 1.5.13.1).
 
Thanks.
 
Regards,
Auteria W. Winzer Jr.

--
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 including float.h with gcc -mno-cygwin (Danny can you comment?)

[Danny Smith]

cgf wrote:
>On Sun, Mar 20, 2005 at 09:21:42AM +1200, Danny Smith wrote:
>>On native mingw build I get this:
>>
>>#include "..." search starts here:
>>#include <...> search starts here:
>> D:/MINGW/BIN/../lib/gcc/mingw32/3.4.3/../../../../include
>> D:/MINGW/BIN/../lib/gcc/mingw32/3.4.3/include
>> D:/MINGW/BIN/../lib/gcc/mingw32/3.4.3/../../../../mingw32/include
>> /mingw/lib/gcc/mingw32/3.4.3/../../../../include
>> /mingw/include
>> /mingw/lib/gcc/mingw32/3.4.3/include
>> /mingw/lib/gcc/mingw32/3.4.3/../../../../mingw32/include
>> /mingw/include
>>End of search list.
>>
>>As far as I can remember  (gcc 2.95.3)  the mingw include dir has preceded the
>>gcc include dir.
>
>In the above, the mingw directory is intermixed multiple times with the
>gcc include directory.  Unless I'm missing something, if cygwin and
>linux are any indication, that's sort of unusual.
>

Duplicate entries do not get removed because the code that does that depends on
working inode numbers.  mingw has an unusual file system

Some of the duplicates are there because they derive from the prefix as set
during build, while others (the once that start with D:/MINGW/BIN derive from
the make-relative-prefix relocations

The first include of /mingw/include
(D:/MINGW/BIN/../lib/gcc/mingw32/3.4.3/../../../../include)
is actually the LOCAL_INCLUDE_DIR, which on mingw is constructed by sed to be
relative to EXEC_PREFIX.

Danny

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