Re: Did anyone download the Windows 7 beta?

[Martin]

Dave Korn writes:

> S. Cowles wrote:
...
> completely.  (It's also, at least in win7, trivial for viruses etc. to bypass
> programmatically, because MS left a wide-open back door in it for the benefit
> of their own software.  Duh!)

in win7 or vista or both ?

from where did you get that information ?

Thanks

Martin
--
parozusa at web dot de


--
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: Not a cygport problem [Was: Re: Problem with 575 man pages -- cygport problem?]

[Chris Sutcliffe]

> It depends on which version of 'file' you are using. On cygwin-1.7, the
> current version of file:
>
> $ file -version
> file-5.00
>
> reports ASCII text.
>
> On cygwin-1.5, the current version of file
>
> $ file -version
> file-4.21
>
> reports ASCII troff.

Ahh... my bad, I tested on Cygwin 1.7 with file-5.00 only.

Cheers!

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org

--
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: [ANNOUNCEMENT] [1.7] Updated: {libtool/libltdl7}-2.2.7a-10

[Dave Korn]

Marco Atzeri wrote:

> I found also a further problem. 
> In one case (hdf5) I found no way to build shared libs 
> as the libtool always had "build_libtool_libs=no"
> 
> as "extrema ratio" I added a
> sed -e "1,100s/^build_libtool_libs=no/build_libtool_libs=yes/" -i libtool
> 
> between cygconf and cygmake, and the build completed fine.
> 
> Reverting to libtool-2.2.6 solved this issue.

  I noticed that the output from 'file' has changed recently, e.g.:

/bin $ file -L /bin/ls.exe
/bin/ls.exe: MS-DOS executable PE  for MS Windows (console) Intel 80386 32-bit

  Maybe this will help?  Or perhaps something similar elsewhere.  Libtool uses
file in several ways to help it decide what it's going to build.


/bin $ diff -pu libtool.orig libtool
--- libtool.orig2009-03-15 23:19:29.5 +
+++ libtool 2009-03-15 23:21:14.90625 +
@@ -3273,6 +3273,7 @@ func_win32_libid ()
   *executable*) # but shell scripts are "executable" too...
 case $win32_fileres in
 *MS\ Windows\ PE\ Intel*)
+*PE*\ *MS\ Windows\ *Intel*)
   win32_libid_type="x86 DLL"
   ;;
 esac
@___. .
(   /"\
 ||--||(___)
 '"  '"'---'
/bin $

cheers,
  DaveK



--
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: Did anyone download the Windows 7 beta?

[Tim McDaniel]

Dave Corn wrote:

A lot of complaints have been addressed at how UAC is so intrusive,
users just end up turning it off completely.


By chance, I recently ran across this Kevin and Kell cartoon
(work-safe), titled "Allow":


--
Tim McDaniel, t...@panix.com

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

Re: [ANNOUNCEMENT] [1.7] Updated: {libtool/libltdl7}-2.2.7a-10

[Corinna Vinschen]

On Mar 17 14:03, Dave Korn wrote:
>   I noticed that the output from 'file' has changed recently, e.g.:
> 
> /bin $ file -L /bin/ls.exe
> /bin/ls.exe: MS-DOS executable PE  for MS Windows (console) Intel 80386 32-bit
> 
>   Maybe this will help?  Or perhaps something similar elsewhere.  Libtool uses
> file in several ways to help it decide what it's going to build.
> 
> 
> /bin $ diff -pu libtool.orig libtool
> --- libtool.orig2009-03-15 23:19:29.5 +
> +++ libtool 2009-03-15 23:21:14.90625 +
> @@ -3273,6 +3273,7 @@ func_win32_libid ()
>*executable*) # but shell scripts are "executable" too...
>  case $win32_fileres in
>  *MS\ Windows\ PE\ Intel*)
> +*PE*\ *MS\ Windows\ *Intel*)
>win32_libid_type="x86 DLL"

I'm wondering how the original expression was supposed to work even
with older file(1) versions:

  $ file-4.21 /bin/bash
  /bin/bash: MS-DOS executable PE  for MS Windows (console) Intel 80386 32-bit

That doesn't match "*MS\ Windows\ PE\ Intel*" as far as I can see.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: [ANNOUNCEMENT] [1.7] Updated: {libtool/libltdl7}-2.2.7a-10

[Corinna Vinschen]

On Mar 17 15:55, Corinna Vinschen wrote:
> On Mar 17 14:03, Dave Korn wrote:
> >   I noticed that the output from 'file' has changed recently, e.g.:
> > 
> > /bin $ file -L /bin/ls.exe
> > /bin/ls.exe: MS-DOS executable PE  for MS Windows (console) Intel 80386 
> > 32-bit
> > 
> >   Maybe this will help?  Or perhaps something similar elsewhere.  Libtool 
> > uses
> > file in several ways to help it decide what it's going to build.
> > 
> > 
> > /bin $ diff -pu libtool.orig libtool
> > --- libtool.orig2009-03-15 23:19:29.5 +
> > +++ libtool 2009-03-15 23:21:14.90625 +
> > @@ -3273,6 +3273,7 @@ func_win32_libid ()
> >*executable*) # but shell scripts are "executable" too...
> >  case $win32_fileres in
> >  *MS\ Windows\ PE\ Intel*)
> > +*PE*\ *MS\ Windows\ *Intel*)
> >win32_libid_type="x86 DLL"
> 
> I'm wondering how the original expression was supposed to work even
> with older file(1) versions:
> 
>   $ file-4.21 /bin/bash
>   /bin/bash: MS-DOS executable PE  for MS Windows (console) Intel 80386 32-bit
> 
> That doesn't match "*MS\ Windows\ PE\ Intel*" as far as I can see.

Either way, do you want me to take this upstream?  I'm already writing
a mail to the upstream maintainer about the apparent inability to
recognize troff files.  While I'm at it, I could ask if the string for
Win32 executables could be reverted to the old style.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: Did anyone download the Windows 7 beta?

[Andy Koppe]

>> completely.  (It's also, at least in win7, trivial for viruses etc. to bypass
>> programmatically, because MS left a wide-open back door in it for the benefit
>> of their own software.  Duh!)
>
> in win7 or vista or both ?

7 only.

http://arstechnica.com/microsoft/news/2009/03/opinion-ms-should-kill-win7-uac.ars
http://www.pretentiousname.com/misc/win7_uac_whitelist2.html

--
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: [ANNOUNCEMENT] [1.7] Updated: {libtool/libltdl7}-2.2.7a-10

[Dave Korn]

Corinna Vinschen wrote:
> On Mar 17 15:55, Corinna Vinschen wrote:
>> On Mar 17 14:03, Dave Korn wrote:
>>>   I noticed that the output from 'file' has changed recently, e.g.:
>>>
>>> /bin $ file -L /bin/ls.exe
>>> /bin/ls.exe: MS-DOS executable PE  for MS Windows (console) Intel 80386 
>>> 32-bit
>>>
>>>   Maybe this will help?  Or perhaps something similar elsewhere.  Libtool 
>>> uses
>>> file in several ways to help it decide what it's going to build.
>>>
>>>
>>> /bin $ diff -pu libtool.orig libtool
>>> --- libtool.orig2009-03-15 23:19:29.5 +
>>> +++ libtool 2009-03-15 23:21:14.90625 +
>>> @@ -3273,6 +3273,7 @@ func_win32_libid ()
>>>*executable*) # but shell scripts are "executable" too...
>>>  case $win32_fileres in
>>>  *MS\ Windows\ PE\ Intel*)
>>> +*PE*\ *MS\ Windows\ *Intel*)
>>>win32_libid_type="x86 DLL"
>> I'm wondering how the original expression was supposed to work even
>> with older file(1) versions:
>>
>>   $ file-4.21 /bin/bash
>>   /bin/bash: MS-DOS executable PE  for MS Windows (console) Intel 80386 
>> 32-bit
>>
>> That doesn't match "*MS\ Windows\ PE\ Intel*" as far as I can see.

  Hang on, maybe I've thrown out a red herring here and this is dead code.  I
have a memory of having had to extend some pattern somewhere in libtool to
match new output from 'file' for executables recently but I can't find my notes.

> Either way, do you want me to take this upstream?  I'm already writing
> a mail to the upstream maintainer about the apparent inability to
> recognize troff files.  While I'm at it, I could ask if the string for
> Win32 executables could be reverted to the old style.

  Dunno if it's worth reverting or not, the damage is done now and everyone
just has to fix their scripts (or have them fail on some systems and not
others according to the installed version of file).  *sigh* Maybe you could
just remind them that it would be nice to keep the churn to a minimum.  I
understand there are bound to be issues when you split a detection into two
different subtypes as with dividing ASCII text into ASCII text and ASCII
troff'd text, but the above change seems to just contain the exact same
information in a different order, which seems unnecessary.

cheers,
  DaveK


--
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] Updated: {subversion,subversion-apache2,subversion-devel,subversion-perl,subversion-python,subversion-ruby}-1.5.6-1

[David Rothenberger]

A new version of subversion is now available for download.

NEWS:
=
This is a new upstream release. See CHANGES (URL below) for more
information.

IMPORTANT: This release will silently upgrade your Subversion
working copies to the 1.5 format, rendering them unusable with
previous major versions of Subversion.

Please see the release notes

  http://subversion.tigris.org/svn_1.5_releasenotes.html

for more details about the changes in Subversion.

See

  http://svn.collab.net/viewvc/svn/tags/1.5.6/CHANGES

for more details about the changes in 1.5.6.

DESCRIPTION:

Subversion is a version control system designed to be a compelling
successor to CVS.

Please see

  http://svnbook.red-bean.com/en/1.5/index.html

for more details about using SVN.

DOWNLOAD:
=
Note that downloads from sources.redhat.com (aka cygwin.com) aren't
allowed due to bandwidth limitations.  This means that you will need to
find a mirror which has this update, please choose the one nearest to
you: http://cygwin.com/mirrors.html

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=
To unsubscribe to 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:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

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 this URL.

-- 
David Rothenberger    daver...@acm.org

Bathquake, n.:
The violent quake that rattles the entire house when the water
faucet is turned on to a certain point.
-- Rich Hall, "Sniglets"


--
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] [1.7] Updated: {subversion,subversion-apache2,subversion-devel,subversion-perl,subversion-python,subversion-ruby}-1.5.6-2

[David Rothenberger]

A new version of subversion is now available for download. This
version is build for Cygwin 1.7.

NEWS:
=
This is a new upstream release. See CHANGES (URL below) for more
information.

IMPORTANT: This release will silently upgrade your Subversion
working copies to the 1.5 format, rendering them unusable with
previous major versions of Subversion.

Please see the release notes

  http://subversion.tigris.org/svn_1.5_releasenotes.html

for more details about the changes in Subversion.

See

  http://svn.collab.net/viewvc/svn/tags/1.5.6/CHANGES

for more details about the changes in 1.5.6.

DESCRIPTION:

Subversion is a version control system designed to be a compelling
successor to CVS.

Please see

  http://svnbook.red-bean.com/en/1.5/index.html

for more details about using SVN.

DOWNLOAD:
=
Note that downloads from sources.redhat.com (aka cygwin.com) aren't
allowed due to bandwidth limitations.  This means that you will need to
find a mirror which has this update, please choose the one nearest to
you: http://cygwin.com/mirrors.html

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=
To unsubscribe to 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:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

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 this URL.

-- 
David Rothenberger    daver...@acm.org

Bathquake, n.:
The violent quake that rattles the entire house when the water
faucet is turned on to a certain point.
-- Rich Hall, "Sniglets"


--
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: under cygwin, zsh cannot run when built against ncurses9-5.7-13

[Dave Korn]

Dave Korn wrote:

>   Anyway, I found that removing "-lm -lc" from the options fixes the build
> problem, and that it makes no difference what version of ld you use.  

  Have looked at this a little further.

  First off: the Cygwin C runtime library is basically the Cygwin DLL, and
what we want in normal use is to link against the Cygwin DLL's import library,
(which is /usr/lib/libcygwin.a).

  The libraries /usr/lib/libm.a and /usr/lib/libc.a are helper libraries, used
to bundle up objects as part of the winsup build.  They are passed to the
final link that builds the Cygwin DLL.  They appear to be some kind of import
library that has been processed by a perl script called speclib that does some
kind of low-level binary munging on them to change symbol names:

-libcygwin/d78.o: file format pe-i386
+libc/d78.o: file format pe-i386
-[  7](sec  0)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x __head_cygwin1_dll
+[  7](sec  0)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x __head_libc

  I don't know what it's all about yet, but as far as I can tell, they aren't
suitable for use outside the actual build system itself and should probably
not need to be installed.  It would probably be better if they were replaced
by symlinks to libcygwin.a, as is done for libg.a.


cheers,
  DaveK



--
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: under cygwin, zsh cannot run when built against ncurses9-5.7-13

[Christopher Faylor]

On Tue, Mar 17, 2009 at 08:43:47PM +, Dave Korn wrote:
>Dave Korn wrote:
>
>>   Anyway, I found that removing "-lm -lc" from the options fixes the build
>> problem, and that it makes no difference what version of ld you use.  
>
>  Have looked at this a little further.
>
>  First off: the Cygwin C runtime library is basically the Cygwin DLL, and
>what we want in normal use is to link against the Cygwin DLL's import library,
>(which is /usr/lib/libcygwin.a).
>
>  The libraries /usr/lib/libm.a and /usr/lib/libc.a are helper libraries, used
>to bundle up objects as part of the winsup build.  They are passed to the
>final link that builds the Cygwin DLL.  They appear to be some kind of import
>library that has been processed by a perl script called speclib that does some
>kind of low-level binary munging on them to change symbol names:
>
>-libcygwin/d78.o: file format pe-i386
>+libc/d78.o: file format pe-i386
>-[  7](sec  0)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x __head_cygwin1_dll
>+[  7](sec  0)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x __head_libc
>
>  I don't know what it's all about yet, but as far as I can tell, they aren't
>suitable for use outside the actual build system itself and should probably
>not need to be installed.  It would probably be better if they were replaced
>by symlinks to libcygwin.a, as is done for libg.a.

Sheesh.  Do you honestly think I would have gone to the effort of
creating these libraries when a simple symlink would suffice?  Do you
really think I don't know about symlinks?

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/

gcc4: cc

[Yaakov (Cygwin/X)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dave,

gcc4 does not provide cc-4, nor does the alternatives script provide cc.
 It probably goes without saying that this breaks some (obviously
non-autotoolized) packages that assume cc's presence.


Yaakov
Cygwin/X
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAknARnkACgkQpiWmPGlmQSMJ3wCcDSjMydp7BLdIEmY3gj9eXtRs
3kwAn01CJXQZtRV9e5ARMOXI66n1hEJN
=k9xQ
-END PGP SIGNATURE-

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

_set_fmode?

[Charles Wilson]

Is there a cygwin analogue to the msvc _set_fmode()? That is, a function
that sets the default mode of fopen, even if you don't explicitly
specify it "rb" or whatever.

Obviously, there's "use binary (or text) mounts".  Less obviously, you
can link against /usr/lib/binary.o (or -lbinmode), or text.o (or
automode.o or textreadmode.o and the similar .a's).  But I'm looking for
an actual function call to replace the following code in libarchive:

+#if defined(_WIN32) && !defined(__CYGWIN__)
   /* Make sure open() function will be used with a binary mode. */
   /* on cygwin, we need something similar, but instead link against */
   /* a special startup object, binmode.o */
   _set_fmode(_O_BINARY);
 #endif

I'm using binmode.o at present, but I'd prefer to just make a func call
at the same place the WIN32-specific code does.  (FWIW, you can't call
the w32api _set_fmode() function and expect it to work; the msvc runtime
and cygwin maintain different default _fmode variables).

--
Chuck

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

Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13

[Dave Korn]

Christopher Faylor wrote:
>>  I don't know what it's all about yet, but as far as I can tell, they aren't
>> suitable for use outside the actual build system itself and should probably
>> not need to be installed.  It would probably be better if they were replaced
>> by symlinks to libcygwin.a, as is done for libg.a.
> 
> Sheesh.  Do you honestly think I would have gone to the effort of
> creating these libraries when a simple symlink would suffice?  Do you
> really think I don't know about symlinks?

  Uh, why do you think I have any idea who wrote what code or how much
historical cruft there might or might not be in the makefile?  When I'm
looking at stuff with a lot of legacy behind it I try not to make assumptions
about what is deliberate and what accidental except in the most blindingly
obvious cases.  I assume it's deliberate that the Makefile builds libc and
libm and uses them in linking the DLL.  I don't assume it's necessarily
deliberate that they get installed.  I have seen examples in the past of auto*
based makefiles that installed more than they should have done solely by
accident of history and evolution.

  So what are libc.a and libm.a for?

cheers,
  DaveK


--
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: gcc4: cc

[Dave Korn]

Yaakov (Cygwin/X) wrote:

> gcc4 does not provide cc-4, nor does the alternatives script provide cc.
>  It probably goes without saying that this breaks some (obviously
> non-autotoolized) packages that assume cc's presence.

  Ah, thanks for pointing this out.  (The packages are of course broken as far
as portability is concerned, as upstream GCC does not anywhere provide a 'cc'
executable; it's presence in the gcc-3 package is caused by the build script
creating a symlink as a convenience, so it's wrong in general to assume that
there "must be" an executable called 'cc' in the PATH.)  I'll add it back into
the next release.

cheers,
  DaveK


--
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: gcc4: cc

[Yaakov (Cygwin/X)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dave Korn wrote:
>   Ah, thanks for pointing this out.  (The packages are of course broken as far
> as portability is concerned, as upstream GCC does not anywhere provide a 'cc'
> executable; it's presence in the gcc-3 package is caused by the build script
> creating a symlink as a convenience, so it's wrong in general to assume that
> there "must be" an executable called 'cc' in the PATH.)  I'll add it back into
> the next release.

Actually, SUSv2 requires a cc and c89; SUSv3 mentions only a c99.


Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAknAfgkACgkQpiWmPGlmQSO12wCg9/imuhKp04k+1sQnwFmphH5P
tVwAoJyvYKElmJbOQeNzkCzKmpkZ1CQG
=Opy3
-END PGP SIGNATURE-

--
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: under cygwin, zsh cannot run when built against ncurses9-5.7-13

[Christopher Faylor]

On Wed, Mar 18, 2009 at 04:24:33AM +, Dave Korn wrote:
>Christopher Faylor wrote:
>>>I don't know what it's all about yet, but as far as I can tell, they
>>>aren't suitable for use outside the actual build system itself and
>>>should probably not need to be installed.  It would probably be better
>>>if they were replaced by symlinks to libcygwin.a, as is done for
>>>libg.a.
>>
>>Sheesh.  Do you honestly think I would have gone to the effort of
>>creating these libraries when a simple symlink would suffice?  Do you
>>really think I don't know about symlinks?
>
>Uh, why do you think I have any idea who wrote what code or how much
>historical cruft there might or might not be in the makefile?

I did think that you understood how to use CVS to research things like
this, but, ok, so there was some historical ignoramus who worked on the
cygwin project and didn't understand how symlinks worked.

>When I'm looking at stuff with a lot of legacy behind it I try not to
>make assumptions about what is deliberate and what accidental except in
>the most blindingly obvious cases.

You made assumptions with your "it sould probably be better" suggestion.
The point is that it isn't usually profitable to automatically assume
that a problem would be trivially solved by an obvious solution.

>I assume it's deliberate that the Makefile builds libc and libm and
>uses them in linking the DLL.  I don't assume it's necessarily
>deliberate that they get installed.  I have seen examples in the past
>of auto* based makefiles that installed more than they should have done
>solely by accident of history and evolution.

Your reading of the Makefile is not right.  libc.a and libm.a from
newlib do get used in creating cygwin1.dll (obviously?).  There are
different libc.a, libm.a, libpthread.a, libutil.a, libdl.a, and
libresolv.a libraries which are all produced intentionally and have
nothing to do with the creation of the dll itself.

The initial discussion of the reason for these libraries started here:

http://cygwin.com/ml/cygwin/2001-12/msg00705.html

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/

Subject: Re: Connecting to cygwin ssh is slow

[Shaun Broadbent]

I came across the very same thing this morning, ironically for the same
reasons. After deciding ssh was too slow and seeing some dns errors show 
up in the log i went to edit sshd_config to remove dns and found

as you did that I couldn't.

It would seem this was because sshd was running (not that, that makes 
sense). Trying to vi sshd_config would open the file then after a few

seconds stack dump.

Running as administrator I could not take ownership or change ownership 
or permissions of the file via any means (cacls/icacls/right 
click/chmod/chown), also couldn't delete the file (tried unlocker, no 
locks on the file).


It couldn't have been a permissions issue in the true sense as both
the user and Administrator had full permissions on the file.

This all took place after running ssh-host-config for the first time on 
a new box (Windows 7 Beta, cygwin 1.7)


I rebooted the box and sshd_config was gone, I wrote a new one and it
has been fine since.

(and yes it connects a lot faster).

perhaps a reboot is required after creating a new user?



> Well, I'm still stuck. I tried to change UseDNS to 'no', but editing the
> sshd_config file was impossible. The file is owned by cyg_server and even
> the Administrator user can't write to it. I tried to change the file
> permissions and ssh crashed and the service wouldn't start. I changed the
> settings back and still the service couldn't be started. I had to 
reinstall

> the openssh package and now I am back to square 1 again.
>
> How can I edit the sshd_config file? I can't even log in to Windows as
> cyg_server and the su command doesn't let me su to any user (I know 
all the

> passwords).
>
> And what is ident, please? We don't have firewalls on our machines. 
Sniffing

> packets like someone suggested is difficult (for me) but I guess I'll try
> that too.
>
> I really appreciate all of your help so far.
> Thanks.
> Udi.


--
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 [1.7]: link /bin/lzma -> xz

[Fergus]

Following the most recent update in [1.7] which was subversion*, there 
is a problem with a link

 /bin/lzma -> xz
co-existing with both files
 /bin/xz.exe and /bin/lzma.exe
Fergus



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