Plans to update meson version?

[Dave Trombley via Cygwin]

Meson appears to be two majore versions behind in cygwin (1.2.3 is latest
available, 1.4.0 was released mid-March this year).

Major projects are starting to not be compilable on Cygwin, consequently,
short of manually building a custom meson that is up to date (for example,
libcairo requires 1.3).

Are there plans to update this at some point?


Thanks,
-David

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

Signature files missing

[dave--- via Cygwin]

.sig files seem to have gone missing from (at least some) mirrors.

e.g. https://mirrors.kernel.org/sourceware/cygwin/x86_64/

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

Re: newlib-cygwin.git repository: Switching "master" to "main"

[Dave McGuire via Cygwin]

On 1/13/23 14:57, Adam Dinwoodie wrote:

On Fri, Jan 13, 2023 at 02:23:44PM -0500, Mike Frysinger via Cygwin wrote:

thanks for doing this!
-mike


Seconded!  This clearly isn't going to solve racism in a single step,
but making our community that bit more welcoming -- particularly when
the cost of the change is essentially zero -- has to be a positive move.


  You guys have GOT to be kidding me.

--
Dave McGuire, AK4HZ
New Kensington, PA


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

Possible cygwin scp bug

[Knight, Dave]

I am running cygwin virtualbox running a WinDev2206Eval "appliance" (.ova
from microsoft).  Everything else I've tested so far in cygwin runs as
expected except scp when the  file path is an absolute path, e.g.
/tmp/foo.  Scp  references to that file using a relative path, e.g.
../../tmp/foo, work fine.  For example:

$ ls > /tmp/foo   # create a /tmp/file
$ ls -l /tmp/foo
$ scp /tmp/foo bcserver:foobar  # fails with /tmp/foo "file not found"
$ pwd# (CWD is /Users/dmk)
$ scp ../../tmp/foo bcserver:foobar   # this works
$ cd /tmp
$ scp foo bcserver:foobar   # this also works

Please see the attached (script) log file scp.log for the actual results
using these commands.
See also the attached cygcheck.out file.

Note that:

  1 -  absolute paths work OK for an scp  pathname

  2 - the "scp /tmp/foo bcserver:foobar" command works OK in win11's
PowerShell

  3 - the scp target host (bcserver) is a FreeBSD 12 OS running in a
TrueNAS "jail".
Script started on 2022-07-16 05:37:23-07:00 [TERM="xterm" TTY="/dev/pty0" COLUMNS="80" LINES="24"]
[?2004h]0;~

dmk@WinDev2206Eval ~

$ which scp
[?2004l
/cygdrive/c/Windows/System32/OpenSSH/scp
[?2004h]0;~

dmk@WinDev2206Eval ~

$ ls
[?2004l
cygcheck.out   scp.log		   tst_ctlm	 tst_rep   tst_tag%bar
dailyPrayers%  test_DOSfmt	   tst_info	 tst_rep%  tst_tag%foo
foo	   testing		   tst_info%xxx  tst_rep%foo
foo11138   testing.standalone  tst_misc	 tst_rep%foo%
foo3162tst_bug		   tst_ncoAll	 tst_tag
[?2004h]0;~

dmk@WinDev2206Eval ~

$ ls > /tmp/foo
[?2004l
[?2004h]0;~

dmk@WinDev2206Eval ~

$ ls -l /tmp/foo
[?2004l
-rw-r--r-- 1 dmk None 228 Jul 16 05:37 /tmp/foo
[?2004h]0;~

dmk@WinDev2206Eval ~

$ scp /tmp/foo bcserver:foobar
[?2004l
[?25h/tmp/foo: No such file or directory
[?2004h]0;~

dmk@WinDev2206Eval ~

$ pwd
[?2004l
/home/dmk
[?2004h]0;~

dmk@WinDev2206Eval ~

$ scp ../../tmp/foo bcserver:foobar
[?2004l
[?25hfoo 0%0 0.0KB/s   --:-- ETA
foo   100%  228 7.2KB/s   00:00
[?2004h]0;~

dmk@WinDev2206Eval ~

$ cd /tmp
[?2004l
[?2004h]0;/tmp

dmk@WinDev2206Eval /tmp

$ scp foo bcserver:foobar
[?2004l
[?25hfoo 0%0 0.0KB/s   --:-- ETA
foo   100%  22814.2KB/s   00:00
[?2004h]0;/tmp

dmk@WinDev2206Eval /tmp

$ ssh bcserverer ls -l foobar
[?2004l
[?25h-rw-r--r--  1 dmk  dmk  228 Jul 16 08:39 foobar
[?2004h]0;/tmp

dmk@WinDev2206Eval /tmp

$ [?2004l

exit

Script done on 2022-07-16 05:40:24-07:00 [COMMAND_EXIT_CODE="0"]


cygcheck.out
Description: Binary data

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

RE: EXT: Re: cygpath -u converts quoted UNC paths to local

[Garber, Dave (BHGE, Non-GE)]

Not completely the shell.

From a Windows command prompt:
c:\Apps\cygwin64\bin\cygpath.exe  -u 
\\123.456.789.321\wwwroot\ccenter\bin\online.sh
//123.456.789.321/wwwroot/ccenter/bin/online.sh

c:\Apps\cygwin64\bin\cygpath.exe  -u 
"\\123.456.789.321\wwwroot\ccenter\bin\online.sh"
/cygdrive/c/123.456.789.321/wwwroot/ccenter/bin/online.sh

c:\Apps\cygwin64\bin\cygpath.exe  -u 
"\\\123.456.789.321\wwwroot\ccenter\bin\online.sh"
//123.456.789.321/wwwroot/ccenter/bin/online.sh

c:\Apps\cygwin64\bin\cygpath.exe  -u 
"123.456.789.321\wwwroot\ccenter\bin\online.sh"
//123.456.789.321/wwwroot/ccenter/bin/online.sh

Looks like cygpath is doing something different when the argument is enclosed 
in quotes (same behavior if single-quote ' is used).
 
> -Original Message-
> From: cygwin-ow...@cygwin.com  On Behalf
> Of Achim Gratz
> Sent: Wednesday, April 03, 2019 1:12 PM
> To: cygwin@cygwin.com
> Subject: EXT: Re: cygpath -u converts quoted UNC paths to local
> 
> Andrey Repin writes:
> > This can be considered "working by design", but it really imposes some
> > serious restrictions on interoperability with Cygwin, that I think can be
> avoided.
> 
> But cygpath never sees the quotes, so whatever is done to the path that it
> gets is actually the work of your shell.  In other words, you need to shell-
> quote the backslashes as appropriate for your shell.
> 
> 
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk
> Blofeld]>+
> 
> DIY Stuff:
> http://Synth.Stromeko.net/DIY.html
> 
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple


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

RE: EXT: Re: ps -W now showing STIME Dec 31

[Garber, Dave (BHGE, Non-GE)]

> -Original Message-
> From: cygwin-ow...@cygwin.com  On Behalf
> Of Corinna Vinschen
> Sent: Thursday, March 21, 2019 10:53 AM
> To: cygwin@cygwin.com
> Subject: EXT: Re: ps -W now showing STIME Dec 31
> 
> On Mar 21 08:07, Brian Inglis wrote:
> > With latest Cygwin ps -W is now showing STIME Dec 31 for Windows
> > startup processes - these should be limited to actual start or uptime if
> possible.
> 
> It's not possible.  Starttime requires ability to open process.


Run from an elevated shell it shows correctly.

But Windows command 'wmic process get name, creationdate' in a non-elevated 
command prompt also works.  So it looks like it should be possible.

> 
> 
> Corinna
> 
> --
> Corinna Vinschen
> Cygwin Maintainer

RE: 2 [main] bash 13792 find_fast_cwd: WARNING

[Dave Barker]

Thank you, an unbelievably quick response excellent English

Regards

Dave

-Original Message-
From: Andrey Repin [mailto:anrdae...@yandex.ru] 
Sent: 23 December 2018 22:51
To: Dave Barker; cygwin@cygwin.com
Subject: Re: 2 [main] bash 13792 find_fast_cwd: WARNING

Greetings, Dave Barker!

>   Hi, I'm trying to unbrick a Samsung Galaxy Ace S5830I and received
> this message

>  

> 2 [main] bash 13792 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
> pointer.  Please report this problem to

> the public mailing list cygwin@cygwin.com

>  

> Any help would be appreciated

This is merely a warning, which is also an indication that your Cygwin
installation is very old.
The problem was resolved over a decade ago.
For details, see
https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings


-- 
With best regards,
Andrey Repin
Monday, December 24, 2018 1:50:00

Sorry for my terrible english...


---
This email has been checked for viruses by AVG.
https://www.avg.com


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

2 [main] bash 13792 find_fast_cwd: WARNING

[Dave Barker]

  Hi, I'm trying to unbrick a Samsung Galaxy Ace S5830I and received
this message

 

2 [main] bash 13792 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
pointer.  Please report this problem to

the public mailing list cygwin@cygwin.com

 

Any help would be appreciated

 

Dave



---
This email has been checked for viruses by AVG.
https://www.avg.com

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

Re: update batch file

[Dave Caswell]

On Mon, Apr 30, 2018 at 2:33 AM, Vlado <...@gmail.com> wrote:
> On 30.4.2018 3:57, Dave Caswell wrote:
>>
>> Has anyone created a batch file that stops the cygwin services, runs
>> setup to get updates in the background, and then restarts the
>> services??
>
>
> Hi Dave.
>
> I created similar script:
> https://gist.github.com/Vlado-99/1d59bf05b70481377ff90bb53e13bb2d
>
> Add more services as You wish.
> Add --quiet-mode and (probably) --upgrade-also to %SETUP%.exe (line 289).

Thank You!   That's just the sort of script I was hoping to find.

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

update batch file

[Dave Caswell]

Has anyone created a batch file that stops the cygwin services, runs
setup to get updates in the background, and then restarts the
services??

Doing it manually, I occasionally forget to restart the services and
things stop working until I remember to start them up  again.

Thanks

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

Re: Bug in Python3 ('tempfile', 'subprocess', '_hashlib')

[Dave Caswell]

On Thu, Apr 5, 2018 at 7:14 PM, Giuseppe Scelsi
 wrote:
> Hi,
>
> Using freshly-updated Cygwin 64-bit under Windows 7 Enterprise Ver 6.1
> and Python 3 version 3.6.4.
>
> The execution of the following script:
>
> import subprocess
> import _hashlib
> import _sha3
> subprocess.run('pwd')
>
> always results in 'BlockingIOError: [Errno 11] Resource temporarily
> unavailable'.
>
> I saw this error first in a script that imported 'tempfile' together
> with 'subprocess' (in any order):
>
> import subprocess
> import tempfile
> subprocess.run('pwd')
>
> I then managed to narrow down the problem to the '_sha3' module.
> Notice that you need to import both '_hashlib' and '_sha3' *in that
> order*.  If I swap the order and import '_sha3' before '_hashlib', the
> error becomes sporadic, sometimes it happens and sometimes not.
>
> This problem makes it impossible to use 'tempfile' and 'subprocess' in
> the same script.  My workaround is currently to disable '_sha3' in
> '/lib/python3.6/hashlib.py' by adding at line 62:
>
> __always_supported = __always_supported[0:8]
>
> This problem only happens in Cygwin 64, 32-bit Cygwin works ok.
>
> Can anyone reproduce this problem?
>
> Best regards,
>
> Giuseppe
>

Tried to reproduce:

davec@SodiumWin ~/tmp
$ cat py3t.py
#!/usr/bin/python3

import subprocess
import _hashlib
import _sha3
subprocess.run('pwd')

davec@SodiumWin ~/tmp
$ ./py3t.py
/home/davec/tmp

Everything seems to work OK for me.  This is with a recently updated Cygwin 64.

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

Re: Run command in new window

[Dave Caswell]

> and for some reason any spaces must be quoted - not escaped - these work:
>
>cygstart bash -c '"echo 1;read"'
>cygstart bash -c "'echo 1;read'"
>
> these fail:
>
>cygstart bash -c 'echo\ 1;read'
>cygstart bash -c "echo\ 1;read"


The '-v' option to cygstart gives the key to understanding this by
showing what actually gets passed along by cygstart.
WORKS:
davec@SodiumWin ~
$ cygstart -v bash -c " ' echo  TT; sleep 5 ' "
ShellExecute(NULL, "(null)", "bash", "-c  ' echo  TT; sleep 5 ' ", "(null)", 1)
The quotes surrounding the argument to -c get passed along to the executed bash.

WORKS:
davec@SodiumWin ~
$  cygstart -v bash -c '"echo 1;read"'
ShellExecute(NULL, "(null)", "bash", "-c "echo 1;read"", "(null)", 1)
Same here, the echo and read are both contained in one argument to -c.

DOES NOT WORK
davec@SodiumWin ~
$ cygstart -v bash -c 'echo\ 1;read'
ShellExecute(NULL, "(null)", "bash", "-c echo\ 1;read", "(null)", 1)
Without the quotes to group the echo and read together, when the
executed bash breaks the line up into words, the -c only sees echo\ as
its command.

WORKS:
davec@SodiumWin ~
$ cygstart -v bash -c \'echo 1\;read \'
ShellExecute(NULL, "(null)", "bash", "-c 'echo 1;read '", "(null)", 1)
By escaping the quotes and semicolon so they get passed along intact,
the executed bash also gets an intact command string.

Does this help at all?

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

Re: Run command in new window

[Dave Caswell]

On Sun, Dec 24, 2017 at 9:34 PM, Steven Penny  wrote:
>
> yes, that is good if you want to use a script - but a command does not work:
>
>cygstart bash -c 'echo hello; sleep 5'
>
Ah, OK.  Here you go:

davec@SodiumWin ~
$ cygstart /usr/bin/bash '-c "echo hello; sleep 5"'

I wish I could explain just why this quotation pattern works here.  A
long time ago I found that dicking around with the quotes could often
get things working faster than trying to understand it in detail.

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

Re: Run command in new window

[Dave Caswell]

On Sun, Dec 24, 2017 at 8:50 PM, Steven Penny  wrote:
> On Mon, 25 Dec 2017 06:28:50, Andrey Repin wrote:
>>
>> The usual way - prevent the closing of the new window.
>> I.e. by adding a sleep.
>
>
> no, that doesnt work
>
> have you tried it?
>
> if so provide sample command

Here's an example:

davec@SodiumWin ~
$ cygstart bash -e TT

davec@SodiumWin ~
$ cat TT
#! /usr/bin/bash

echo TEST
sleep 240

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

problem with gnupg2 not prompting for passphrase

[Garber, Dave (GE Oil & Gas, Non-GE)]

> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of jeff
> Sent: Tuesday, July 11, 2017 1:56 PM
> To: cygwin@cygwin.com
> Subject: EXT: Re: problem with gnupg2 not prompting for passphrase
> 
> On 7/11/2017 10:51 AM, Brian Inglis wrote:
> > On 2017-07-10 23:07, Thomas Wolff wrote:
> >> Am 11.07.2017 um 00:38 schrieb jeff:
> >>> On 7/10/2017 1:21 PM, Achim Gratz wrote:
>  jeff writes:
> > jeff_xeon:/cygdrive/u:503: gpg2 --output fred.good --decrypt
> > fred.gpg
> > gpg: encrypted with 4096-bit RSA key, ID A3791E7DD935A424, created
> > 2013-03-21
> >"Jeff Deifik "
> > gpg: public key decryption failed: No such device or address
> > gpg: decryption failed: No secret key
> >
> > I have uninstalled the standalone version of gnupg2 before I did this.
> > It seems most likely that the version of gpg2 being invoked is a
> > cygwin version.
>  It fails to find your private key, so it is quite obviously not in
>  a place where gpg2 expects to find it.
> >>> I have my keys stored in $HOME/.gnupg which is where gnupg v1
> expects them.
> >
> > gnupg2 uses the same --homedir paths, $GNUPGHOME env var, native
> > Windows reg key, and native Windows portable apps homedir as gnupg1.
> >
> >> Just guessing: Some software does not look in $HOME for config files (e.g.
> >> openssh) but expects them in /home/...
> >
> > OpenSSH expects user config files in ~/.ssh/ where ~ is $HOME, or the
> > home directory from "getent passwd $LOGNAME", which defaults to /.
> >
> > They'd better expect $HOME, not /home/$LOGNAME, as $HOME could
> also be
> > /u/$LOGNAME, /mnt/nfs/OrkeyDorkey, or /mnt/Network\ Users/Orkey\
> > Dorkey! ;^>
> >
> 
> The problem almost certainly lies with pinentry. It seems to be a new feature

See https://sourceware.org/ml/cygwin/2017-07/msg00100.html for the solution.

> of gnupg2. As I demonstrated, there is no problem finding my public key, nor
> my private key, which are located in the default place.
> The problem is the method used to get the passphrase is very broken.
> After reading some stuff via google, I added
> 
> GPG_TTY=$(tty)
> export GPG_TTY
> 
> to my .bashrc file, with no observable changes.
> 
> jeff
> 
> 
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: fstab /tmp usertemp error after Windows Update

[Garber, Dave (GE Oil & Gas, Non-GE)]

Your TMP or TEMP environment variable is probably set to that value.  Exit 
Cygwin, fix the environment variable and then go into Cygwin and check it.

Dave

> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Jeff Howard
> Sent: Tuesday, June 27, 2017 2:43 PM
> To: cygwin@cygwin.com
> Subject: EXT: fstab /tmp usertemp error after Windows Update
> 
> Hello -
> 
> After a recent Windows Update (and reboot) the following fstab entry we
> used directly from the Cygwin documentation (https://cygwin.com/cygwin-
> ug-net/using.html) is no longer working.  After digging a little deeper, it
> appears to be attempting to mount /tmp to a directory that doesn't exist on
> my local filesystem.
> 
> I can of course create the directory in my temp folder, but that would defeat
> the purpose in our multi-user environment.  Since we're in a multi-user
> environment, our intention is for each user to seamlessly mount /tmp to
> their own temporary folder to prevent permissions issues.  I also updated
> the Cygwin binaries for good measure, and the issue still persists.
> 
> Examples of my fstab and output from "mount" are in-line below.  Note that
> the directory "/3" does not exist in my local temp folder -
> "C:/Users/Jeff/AppData/Local/Temp" does not exist in my local temp folder:
> 
> $ cat fstab
> # /etc/fstab
> #
> #This file is read once by the first process in a Cygwin process tree.
> #To pick up changes, restart all Cygwin processes.  For a description
> #see https://cygwin.com/cygwin-ug-net/using.html#mount-table
> 
> # This is default anyway:
> none /cygdrive cygdrive binary,posix=0,user 0 0
> none /tmp usertemp binary,posix=0 0 0
> 
> Jeff@CM /etc
> $ mount
> C:/Users/Jeff/AppData/Local/Temp/3 on /tmp type ntfs
> (binary,posix=0,usertemp)
> C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
> C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
> C:/cygwin on / type ntfs (binary,auto)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
> E: on /cygdrive/e type ntfs (binary,posix=0,user,noumount,auto)
> 
> 
> - Jeff
> 
> 
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple


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

RE: setup 2.880 release candidate - please test

[Garber, Dave (GE Oil & Gas, Non-GE)]

Looks good.  I did fond one other behavior that I believe should be changed.  
When you are typing in the search box, if you press the enter key, it's the 
same as pressing the Next button and starts the install.  My $.02 is that Enter 
should be ignored when focus is in the search box.

Thanks,
Dave

> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Jon Turney
> Sent: Wednesday, June 07, 2017 1:08 PM
> To: The Cygwin Mailing List <cygwin@cygwin.com>
> Subject: EXT: setup 2.880 release candidate - please test
> 
> 
> A new setup release candidate is available at:
> 
>https://cygwin.com/setup/setup-2.880.x86.exe(32 bit version)
>https://cygwin.com/setup/setup-2.880.x86_64.exe (64 bit version)
> 
> Please test and report problems to cygwin@cygwin.com. If no regressions
> are discovered in the next week or so, it will be promoted to release.
> 
> Changes compared to 2.879:
> 
> - "Internet Explorer Proxy Settings" is renamed to "System Proxy Settings".
> 
> - Remove support for the syntax "requires: A | B" in setup.ini, which
> calm/upset/genini never generated, and was just treated as "requires:
> A", anyhow.
> 
> - Fix a bug where installing a version other than the current version the 
> first
> time a package is installed might lead to it's dependencies not being 
> installed.
> 
> - Add some progress reporting during preremove and uninstall operations.
> 
> - Fix a bug which caused orphaned packages to be omitted from the picker.
> (A regression introduced in 2.878)
> 
> - Correctly account for source packages to be installed due to the --include-
> source option in the total amount of data to checksum.
> 
> - Rename the category "Misc" to "Orphaned".
> 
> - Fix an infinite recursion in the setup.ini parser for "depends:"
> 
> - Error recovery in setup.ini parsing is now slightly improved, so the same
> parse error isn't reported multiple times.
> 
> - Add the option "--user-agent" to override the user-agent string sent in
> HTTP requests.
> (Addresses: https://cygwin.com/ml/cygwin/2012-02/msg00857.html etc.)
> 
> - The default user-agent string now contains the setup version.
> 
> - Fix that clicking on any column can change "Keep" to "Uninstall".
> (Addresses: https://cygwin.com/ml/cygwin/2017-05/msg00525.html)
> 
> - Allow click-to-activate in the package list control.
> 
> - Improve the unhelpful error message "Can't open (null) for reading: No
> such file".
> 
> - Remove some messagebox spam when using file:// protocol URLs for a
> package repository without a compressed setup.ini.
> 
> - Some source code cleanups and cruft removal.
> 
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: setup release candidate - please test

[Dave Caswell via cygwin]

Execution blocked by Windows 10 anti-virus.(Microsoft Security Essentials.)

On Mon, May 8, 2017 at 5:10 AM, Dave Caswell <dave.casw...@gmail.com> wrote:
> Execution blocked by Windows 10 anti-virus.(Microsoft Security
> Essentials.)
>
> On Mon, May 8, 2017 at 5:06 AM, Jon Turney <jon.tur...@dronecode.org.uk>
> wrote:
>>
>>
>> A setup release candidate is available at:
>>
>>   https://cygwin.com/setup/setup-2.878.x86.exe
>>   https://cygwin.com/setup/setup-2.878.x86_64.exe
>>
>> Since this changes the way we download files, I think this can use some
>> wider testing before release.
>>
>> Please test and give feedback to cygwin@cygwin.com. If no regressions are
>> discovered in the next few days, it will be promoted to release.
>>
>>
>> Changes compared to 2.877:
>>
>> - "Direct Connection" now uses the WinINet API to fetch URLs.
>>
>> This enables HTTPS and FTPS protocol support, and caching of mirrors.lst
>> and setup.ini.
>>
>> The existing, hand-built URL fetching, which only supports HTTP and FTP,
>> is still available by choosing "Direct (legacy)".
>>
>> - Fixes to "Use Internet Explorer Proxy Settings" mode
>>
>> Progress is now reported for downloads.
>>
>> Unwanted caching in "Temporary Internet Files" of package archives has
>> been fixed.
>> (Addresses: https://cygwin.com/ml/cygwin/2016-09/msg00403.html)
>>
>> A bug causing a long delay before downloading setup.ini from package
>> repositories without a compressed setup.ini has been fixed.
>>
>> - Add --allow-unsupported-windows option
>>
>> Don't check the windows version.
>>
>> The Cygwin mirror list is not read, so a URL (e.g. a Cygwin time machine
>> circa) should be given with --site or via the GUI.
>>
>> - Remove support for some long-obsolete setup.ini syntax (omitted
>> version:, omitted size and checksum, various undocumented tokens)
>>
>> - Remove cruft
>>
>> --
>> Problem reports:   http://cygwin.com/problems.html
>> FAQ:   http://cygwin.com/faq/
>> Documentation: http://cygwin.com/docs.html
>> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>>
>

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

Python 3.5.2

[Dave Caswell]

Does anyone know when we can expect python3 to be upgraded to 3.5??

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

Can't use install-path longer than 15 chars after 2.875 update

[Garber, Dave (GE Oil & Gas, Non-GE)]

> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Corinna Vinschen
> Sent: Wednesday, August 31, 2016 3:26 PM
> To: cygwin@cygwin.com
> Subject: EXT: Re: Can't use install-path longer than 15 chars after 2.875
> update
> 
> On Aug 31 18:59, Garber, Dave (GE Oil & Gas, Non-GE) wrote:
> > > -Original Message-
> > > From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com]
> On
> > > Behalf Of Corinna Vinschen
> > > Sent: Wednesday, August 31, 2016 2:39 PM
> > > To: cygwin@cygwin.com
> > > Subject: EXT: Re: Can't use install-path longer than 15 chars after
> > > 2.875 update
> > >
> > > On Aug 31 20:22, Jacek Sowiński wrote:
> > > > After updating to setup-x86_64.exe version 2.875 I can't use
> > > > install paths longer than 15 chars and error is throwed:
> > > >
> > > > > The install directory must be absolute, with both a drive letter
> > > > > and leading slash, like C:\Cygwin
> > >
> > > So what was your actual install path?
> > >
> > > FYI, I just used setup-2.875 to installed Cygwin into
> > > C:\cygwin-test-blubber- test\test\test and it just worked.
> >
> > I can confirm that C:\apps\Cygwin64 does NOT work but C:\apps\Cygwin6
> > does.  I also get the error with C:\cygwin-test-blubber-test\test\test.
> 
> On what OS?  You're not running it on XP by any chance?  Is that on
> 32 or 64 bit?
> 
> [...time passes...]
> 
> I could reproduce it on W7 32 bit for some reaosn, while it works fine all the
> time on W10 64 bit.
> 

Fails on Win7 64 bit also.

> FWIW, I reverted setup to version 2.874 for the time being.
> 
> 
> Corinna
> 
> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat

Can't use install-path longer than 15 chars after 2.875 update

[Garber, Dave (GE Oil & Gas, Non-GE)]

> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Corinna Vinschen
> Sent: Wednesday, August 31, 2016 2:39 PM
> To: cygwin@cygwin.com
> Subject: EXT: Re: Can't use install-path longer than 15 chars after 2.875
> update
> 
> On Aug 31 20:22, Jacek Sowiński wrote:
> > After updating to setup-x86_64.exe version 2.875 I can't use install
> > paths longer than 15 chars and error is throwed:
> >
> > > The install directory must be absolute, with both a drive letter and
> > > leading slash, like C:\Cygwin
> 
> So what was your actual install path?
> 
> FYI, I just used setup-2.875 to installed Cygwin into C:\cygwin-test-blubber-
> test\test\test and it just worked.

I can confirm that C:\apps\Cygwin64 does NOT work but C:\apps\Cygwin6 does.  I 
also get the error with C:\cygwin-test-blubber-test\test\test.

> 
> 
> Corinna
> 
> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat

Re: Permission Problems

[Dave Caswell]

On Mon, Apr 25, 2016 at 12:09 AM, Marco Atzeri <marco.atz...@gmail.com> wrote:
> On 25/04/2016 02:29, Dave Caswell wrote:
>>
>> This is a followup to: https://cygwin.com/ml/cygwin/2016-03/msg00345.html
>>
>> To recap, making three nested directories  on a non-C drive produces a
>> third level which is unusable.
>>
>> davec@MERCURYWIN ~/python
>> $ rm -rf g1
>> davec@MERCURYWIN ~/python
>> $ mkdir g1 g1/g2 g1/g2/g3
>> davec@MERCURYWIN ~/python
>> $ ls -la g1 g1/g2 g1/g2/g3
>> g1:
>> total 12
>> drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ./
>> drwxrwx---+ 1 davec Users 0 Mar 16 20:23 ../
>> drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 g2/
>> g1/g2:
>> total 0
>> drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 ./
>> drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ../
>> d--Srws--T+ 1 davec None 0 Mar 16 20:23 g3/
>> ls: cannot open directory 'g1/g2/g3': Permission denied
>>
>> The problem went away with Cygwin 2.5.0-0.7 but is back with 2.5.1-1,
>> and goes away when I downgrade back to 2.5.0-1
>>
>> More info:  I tested on a couple of external drives and things worked
>> properly there.   Can I have screwed up the permissions on my D drive
>> so that cygwin gets confused but Windows still works?
>>
>> thanks
>
>
> It works fine for me.
> "E:" is an external NTFS USB disk
>
> $ mount
> E:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
> E:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
> E:/cygwin64 on / type ntfs (binary,auto)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> E: on /cygdrive/e type ntfs (binary,posix=0,user,noumount,auto)
>
>  $ cd /cygdrive/e/temp
>
>  $ mkdir g1 g1/g2 g1/g2/g3
>
>  $ ls -la g1 g1/g2 g1/g2/g3
> g1:
> total 4.0K
> drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 .
> drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 ..
> drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 g2
>
> g1/g2:
> total 0
> drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 .
> drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 ..
> drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 g3
>
> g1/g2/g3:
> total 0
> drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 .
> drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 ..
>
>  $ icacls .
> . GE-MATZERI-EU\0356EU:(F)
>   BUILTIN\Administrators:(RX)
>   Everyone:(RX)
>   NT AUTHORITY\SYSTEM:(OI)(CI)(F)
>   CREATOR OWNER:(OI)(CI)(IO)(F)
>   CREATOR GROUP:(OI)(CI)(IO)(RX)
>   Everyone:(OI)(CI)(IO)(RX)
>
> $ icacls g1/g2/g3
> g1/g2/g3 NULL SID:(DENY)(Rc,S,REA,X,DC)
>  GE-MATZERI-EU\0356EU:(F)
>  BUILTIN\Administrators:(RX)
>  NT AUTHORITY\SYSTEM:(RX,W,DC)
>  Everyone:(RX)
>  NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,X,DC)
>  CREATOR OWNER:(OI)(CI)(IO)(F)
>  CREATOR GROUP:(OI)(CI)(IO)(RX)
>  NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC)
>  Everyone:(OI)(CI)(IO)(RX)
>
> I suggest to use icacls and eventually "setfacl -b"
> for permission cleaning if needed.

What wound up doing was backing up all the files from my documents
disk to a scratch disk, reformatting the documents disk, and restoring
the backup, and finally running icacls /reset on the whole drive.
This seems to have my system working ok now.

But there is still something different about 2.5.0-1 that prevented it
from writing a confused ACL.

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

Re: Permission Problems

[Dave Caswell]

On Mon, Apr 25, 2016 at 4:30 AM, Tatsuro MATSUOKA
<tmaccha...@yahoo.co.jp> wrote:
>> From: Dave Caswell
>> To: cygwin
>> Cc:
>> Date: 2016/4/25, Mon 09:29
>> Subject: Permission Problems
>>
>>T his is a followup to: https://cygwin.com/ml/cygwin/2016-03/msg00345.html
>>
>> To recap, making three nested directories  on a non-C drive produces a
>> third level which is unusable.
>>
>> davec@MERCURYWIN ~/python
>> $ rm -rf g1
>> davec@MERCURYWIN ~/python
>> $ mkdir g1 g1/g2 g1/g2/g3
>> davec@MERCURYWIN ~/python
>> $ ls -la g1 g1/g2 g1/g2/g3
>> g1:
>> total 12
>> drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ./
>> drwxrwx---+ 1 davec Users 0 Mar 16 20:23 ../
>> drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 g2/
>> g1/g2:
>> total 0
>> drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 ./
>> drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ../
>> d--Srws--T+ 1 davec None 0 Mar 16 20:23 g3/
>> ls: cannot open directory 'g1/g2/g3': Permission denied
>>
>> The problem went away with Cygwin 2.5.0-0.7 but is back with 2.5.1-1,
>> and goes away when I downgrade back to 2.5.0-1
>>
>> More info:  I tested on a couple of external drives and things worked
>> properly there.   Can I have screwed up the permissions on my D drive
>> so that cygwin gets confused but Windows still works?
>>
>> thanks
>>
> Perhaps workaround is to use the beloe
> $ cygstart --action=runas (cygwin command)
>
> In your case,
> $ cygstart --action=runas ls -la g1 g1/g2 g1/g2/g3
> Tatsuro

The problem is the creation of a directory (or file) with a mangled
ACL..  at least windows isn't capable of dealing with the directory
either.

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

Permission Problems

[Dave Caswell]

This is a followup to: https://cygwin.com/ml/cygwin/2016-03/msg00345.html

To recap, making three nested directories  on a non-C drive produces a
third level which is unusable.

davec@MERCURYWIN ~/python
$ rm -rf g1
davec@MERCURYWIN ~/python
$ mkdir g1 g1/g2 g1/g2/g3
davec@MERCURYWIN ~/python
$ ls -la g1 g1/g2 g1/g2/g3
g1:
total 12
drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ./
drwxrwx---+ 1 davec Users 0 Mar 16 20:23 ../
drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 g2/
g1/g2:
total 0
drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 ./
drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ../
d--Srws--T+ 1 davec None 0 Mar 16 20:23 g3/
ls: cannot open directory 'g1/g2/g3': Permission denied

The problem went away with Cygwin 2.5.0-0.7 but is back with 2.5.1-1,
and goes away when I downgrade back to 2.5.0-1

More info:  I tested on a couple of external drives and things worked
properly there.   Can I have screwed up the permissions on my D drive
so that cygwin gets confused but Windows still works?

thanks

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

RE: Seg Fault from strace

[Garber, Dave (GE Oil & Gas, Non-GE)]

$ cygcheck  /usr/bin/strace.exe
C:\Apps\cygwin64\bin\strace.exe
  C:\Windows\system32\ADVAPI32.dll
C:\Windows\system32\msvcrt.dll
  C:\Windows\system32\KERNELBASE.dll
C:\Windows\system32\ntdll.dll
  C:\Windows\system32\API-MS-Win-Core-Console-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-DateTime-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll
C:\Windows\system32\API-MS-WIN-Service-Core-L1-1-0.dll
C:\Windows\system32\API-MS-WIN-Service-winsvc-L1-1-0.dll
C:\Windows\system32\API-MS-WIN-Service-Management-L1-1-0.dll
C:\Windows\system32\API-MS-WIN-Service-Management-L2-1-0.dll
C:\Windows\system32\API-MS-Win-Core-LocalRegistry-L1-1-0.dll
C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll
C:\Windows\system32\KERNEL32.dll
  C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll
C:\Windows\system32\RPCRT4.dll
  C:\Windows\system32\API-MS-Win-Core-Interlocked-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-DelayLoad-L1-1-0.dll


-Original Message-
From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
Marco Atzeri
Sent: Monday, April 11, 2016 3:38 PM
To: cygwin@cygwin.com
Subject: Re: Seg Fault from strace

On 11/04/2016 21:27, Garber, Dave (GE Oil & Gas, Non-GE) wrote:
> Strace always seg faults.  Tried reverting back to 2.4.1 and had the same 
> issue.
>
> $ uname -a
> CYGWIN_NT-6.1 G7TD3H72E 2.5.0(0.297/5/3) 2016-04-11 09:58 x86_64 Cygwin
>
> $ strace echo foo
> Segmentation fault
>
> $ strace -o foo.strace echo foo
> Segmentation fault
>

what is the output of

cygcheck  /usr/bin/strace.exe

Regards
Marco

--
Problem reports:   
https://urldefense.proofpoint.com/v2/url?u=http-3A__cygwin.com_problems.html=CwIC-g=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=zKv0lhngryQuti7TIhTXmU0cAjgLim0Fyr3Kz3GnA-Y=jk_SH9X7F8MLqaGkBLK9G5Av654QuI2cV-fGTmtH-xI=xWHXEBPd6owmgonvE-e6uGM_tu94KD77XmkutT3QNWM=
 
FAQ:   
https://urldefense.proofpoint.com/v2/url?u=http-3A__cygwin.com_faq_=CwIC-g=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=zKv0lhngryQuti7TIhTXmU0cAjgLim0Fyr3Kz3GnA-Y=jk_SH9X7F8MLqaGkBLK9G5Av654QuI2cV-fGTmtH-xI=SPqzLM63IgRhnrQe3neiokXxtxfNZIM-XtLYnHehOj0=
 
Documentation: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__cygwin.com_docs.html=CwIC-g=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=zKv0lhngryQuti7TIhTXmU0cAjgLim0Fyr3Kz3GnA-Y=jk_SH9X7F8MLqaGkBLK9G5Av654QuI2cV-fGTmtH-xI=Vv2bTBb8SZVT0YTnQzxHE1okOrNCl7iUZ_7-CP-IC-M=
 
Unsubscribe info:  
https://urldefense.proofpoint.com/v2/url?u=http-3A__cygwin.com_ml_-23unsubscribe-2Dsimple=CwIC-g=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=zKv0lhngryQuti7TIhTXmU0cAjgLim0Fyr3Kz3GnA-Y=jk_SH9X7F8MLqaGkBLK9G5Av654QuI2cV-fGTmtH-xI=5tas5aST6H_TW7qRtEY74ky_6j4cUVj0yOvjwj8F884=
 


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

Seg Fault from strace

[Garber, Dave (GE Oil & Gas, Non-GE)]

Strace always seg faults.  Tried reverting back to 2.4.1 and had the same issue.

$ uname -a
CYGWIN_NT-6.1 G7TD3H72E 2.5.0(0.297/5/3) 2016-04-11 09:58 x86_64 Cygwin

$ strace echo foo
Segmentation fault

$ strace -o foo.strace echo foo
Segmentation fault

$ gdb --args strace echo foo
GNU gdb (GDB) (Cygwin 7.10.1-1) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from strace...Reading symbols from 
/usr/lib/debug//usr/bin/strace.exe.dbg...done.
done.
(gdb) run
Starting program: /usr/bin/strace echo foo
[New Thread 13744.0x22ac]
warning: dll path for "c:\windows\system32\dgapi64.dll" can not be evaluated
warning: Could not load shared library symbols for 
c:\windows\system32\dgapi64.dll.
Do you need "set solib-search-path" or "set sysroot"?
[New Thread 13744.0x3438]
warning: dll path for "C:\Program 
Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\AE_MailSensor_Plugin64.dll"
 can not be evaluated
warning: Could not load shared library symbols for C:\Program 
Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\AE_MailSensor_Plugin64.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: dll path for "C:\Program 
Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\ame_outlooksensor64.dll"
 can not be evaluated
warning: Could not load shared library symbols for C:\Program 
Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\ame_outlooksensor64.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: dll path for "C:\Program 
Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\ame_smtpsensor64.dll"
 can not be evaluated
warning: Could not load shared library symbols for C:\Program 
Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\ame_smtpsensor64.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: dll path for "C:\Program 
Files\DGAgent\plugins\8E4EA70A-6128-4B57-BD3F-8E9E0F0DA6BB\OS_Plugin64.dll" can 
not be evaluated
warning: Could not load shared library symbols for C:\Program 
Files\DGAgent\plugins\8E4EA70A-6128-4B57-BD3F-8E9E0F0DA6BB\OS_Plugin64.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: dll path for "C:\Program 
Files\DGAgent\plugins\8E4EA70A-6128-4B57-BD3F-8E9E0F0DA6BB\COM_Sensor64.dll" 
can not be evaluated
warning: Could not load shared library symbols for C:\Program 
Files\DGAgent\plugins\8E4EA70A-6128-4B57-BD3F-8E9E0F0DA6BB\COM_Sensor64.dll.
Do you need "set solib-search-path" or "set sysroot"?

Program received signal SIGSEGV, Segmentation fault.
0x7728c52c in KERNEL32!GetVolumePathNamesForVolumeNameW () from 
/cygdrive/c/Windows/system32/kernel32.dll


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

Bug report, but already fixed in TEST RELEASE: Cygwin 2.5.0-0.7

[Dave Caswell]

I delete all cygwin directories and do a
Fresh minimal install of cygwin (2.4.1-1) on a windows 7 ultimate 64 bit box


davec@MERCURYWIN ~
$ cd python

davec@MERCURYWIN ~/python
$ rm -rf g1

davec@MERCURYWIN ~/python
$ mkdir g1 g1/g2 g1/g2/g3

davec@MERCURYWIN ~/python
$ ls -la g1 g1/g2 g1/g2/g3
g1:
total 12
drwxrwxr-x+ 1 davec None  0 Mar 16 20:23 ./
drwxrwx---+ 1 davec Users 0 Mar 16 20:23 ../
drwsrwsr-t+ 1 davec None  0 Mar 16 20:23 g2/

g1/g2:
total 0
drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 ./
drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ../
d--Srws--T+ 1 davec None 0 Mar 16 20:23 g3/
ls: cannot open directory 'g1/g2/g3': Permission denied

Now a strange thing is that if I make myself a home directory in /home
everything works fine.

davec@MERCURYWIN ~/python
$ cd /home

davec@MERCURYWIN /home
$ ls

davec@MERCURYWIN /home
$ mkdir davec

davec@MERCURYWIN /home
$ cd davec

davec@MERCURYWIN /home/davec
$ mkdir g1 g1/g2 g1/g2/g3

davec@MERCURYWIN /home/davec
$ ls -la . g1 g1/g2 g1/g2/g3
.:
total 0
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 ./
drwxrwxrwt+ 1 davec None 0 Mar 16 20:28 ../
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 g1/

g1:
total 0
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 ./
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 ../
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 g2/

g1/g2:
total 0
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 ./
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 ../
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 g3/

g1/g2/g3:
total 0
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 ./
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 ../

davec@MERCURYWIN /home/davec

Now I install cygwin package version 2.5.0-7 and everything starts to
work as expected.

davec@MERCURYWIN /cygdrive/d
$ cd python

davec@MERCURYWIN /cygdrive/d/python
$ rm -rf g1

davec@MERCURYWIN /cygdrive/d/python
$ mkdir g1 g1/g2 g1/g2/g3

davec@MERCURYWIN /cygdrive/d/python
$ ls -la  g1 g1/g2 g1/g2/g3

g1:
total 12
drwxr-xr-x+ 1 davec None  0 Mar 16 20:32 ./
drwxrwx---+ 1 davec Users 0 Mar 16 20:32 ../
drwxr-xr-x+ 1 davec None  0 Mar 16 20:32 g2/

g1/g2:
total 0
drwxr-xr-x+ 1 davec None 0 Mar 16 20:32 ./
drwxr-xr-x+ 1 davec None 0 Mar 16 20:32 ../
drwxr-xr-x+ 1 davec None 0 Mar 16 20:32 g3/

g1/g2/g3:
total 0
drwxr-xr-x+ 1 davec None 0 Mar 16 20:32 ./
drwxr-xr-x+ 1 davec None 0 Mar 16 20:32 ../

davec@MERCURYWIN /cygdrive/d/python
$

So Thank You to whoever fixed this!!

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

Re: chere Bash Prompt Here window closes immediately

[Dave Kilroy]

On 23/10/2015 16:16, Matt Seitz (matseitz) wrote:
> When I right click a folder in Windows Explorer and select
> "Bash Prompt Here", a window opens briefly and then closes
> immediately.  If I select "Applications -> Xterm" from the
> Cygwin/X Server tray icon, XTerm opens fine.
> 
> Cygcheck and Xwin logs attached.  Chere -lr output below.
> 
> matseitz@MATSEITZ-WS02 ~
> $ chere -lr
> --- bash keys ---
> Directory menu item (all users)
>  Prompt Here
> 
> Drive command (all users)
> C:\cygwin64\bin\run.exe -p /usr/X11R6/bin C:\cygwin64\bin\xterm.exe -display 
> %DISPLAY% -e /bin/xhere /bin/bash.exe "%L"

I suspect this may be due to the use of %DISPLAY% (which I don't
recall). I see that in your environment this is set to ":1.0"

What happens if you run the following from cmd:

cd c:\cygwin64\usr\x11r6\bin
c:\cygwin64\bin\xterm.exe -display %DISPLAY% -e /bin/xhere /bin/bash.exe c:

Is it any different if you run
c:\cygwin64\bin\xterm.exe -display :1 -e /bin/xhere /bin/bash.exe c:

or
c:\cygwin64\bin\xterm.exe -display :0 -e /bin/xhere /bin/bash.exe c:

Also, I presume the X server is already running?


Dave.

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

Re: linux libertine mono in mintty ?

[Dave Laub]

On Mon, 28 Sep 2015 08:53:17 +0200, Thomas Wolff  wrote:
> Am 27.09.2015 um 19:29 schrieb J.D. Laub:
>> In windows7 I've installed the Linux Libertine Mono O Mono font, and
use
>> it for putty.  Wanting to use the same in cygwin, I've installed the
>> latest
>> linux-libertine-fonts, xorg-server, & xfs, but I can't get latest
mintty
>> to
>> offer it as a font, from either the console or X.  (It does offer
>> Liberation Mono.)  Suggestions on things I can try besides the reboot
>> I've
>> already done?
> Mintty is not an X windows program. To make fonts available for mintty, 
> you have to install them with Windows, not X11 (I'll add a note to the 
> Tips wiki page).
> Even if you do that, Linux Libertine Mono is not listed in the mintty 
> font menu. The reason for that is probably that the font file is missing

> an explicit flag to identify it as a monospace font. I suggest to file a

> bug with Linux Libertine about that.
> You can still use it, though, with this invocation:
>  mintty -o Font="Linux Libertine Mono"

Thank you very much.  I bumped
https://sourceforge.net/p/linuxlibertine/bugs/229/ , but in the meantime,
the "-o Font" force works.

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

RE: FW: [cygwin] Cygwin's git says error: failed to read delta-pack base object

[Dave L]

Jason Pyeron has patched Cygwin's git so that it works for me (cloning
to Windows network shares).

He says:

TLDR = Cygwin remote filesystem sometimes has strange failures -
workaround is to use rename, not link/unlink

but:

The fix as is, is a sledge hammer with many side effects. A better
way to include this work around will be discussed on the git list. The
real issues may lay in both cygwin and git, caused by BLODA.

See thread below for details. (Some irrelevant stuff omitted for brevity.)

My deep thanks to Jason - I'm up and running now.

--Dave

-- Forwarded message --
From: Jason Pyeron jpye...@pdinc.us
Date: Sun, Dec 7, 2014 at 12:21 PM
Subject: RE: FW: [cygwin] Cygwin's git says error: failed to read
delta-pack base object
To: Dave L d...@nerdfever.com

...

The fix as is, is a sledge hammer with many side effects. A better way
to include this work around will be discussed on the git list. The
real issues may lay in both cygwin and git, caused by BLODA.

On Sat, Dec 6, 2014 at 8:33 PM, Jason Pyeron
 jpye...@pdinc.us wrote:
   
   
  TLDR = Cygwin remote filesystem sometimes has strange
failures - workaround is to use rename, not link/unlink;
  see
https://github.com/pdinc-oss/git/commit/5a36824ed01d4335148ca3
   846e75cc99c11650e2
   -Original Message-
   From: Jason Pyeron
   Sent: Friday, December 05, 2014 10:30
  
-Original Message-
From: Jason Pyeron
Sent: Thursday, December 04, 2014 16:34
   
 -Original Message-
 From: brian m. carlson
 Sent: Wednesday, December 03, 2014 19:55

 On Wed, Dec 03, 2014 at 06:31:18PM -0500, Jason
Pyeron wrote:
  I remember hitting this a while ago,
 but just gave up.
 
  It seems to be a problem for others too.
 
  Any ideas on how to debug this so it
 can be patched?
 
  -Original Message-
  From: Dave Lindbergh
  Sent: Wednesday, December 03, 2014 18:07
  To: cygwin
 
  Aha - you're right.
 
  It works fine on a local NTFS volume.
 
  I get the error when I do it on Z:,
 which is mapped to a
 network drive
  (on another Windows box).
 
  Is there a workaround? Why does this happen?
   
  I have a really hacky workaround, commit
5a36824ed01d4335148ca3846e75cc99c11650e2 comments out the
logic and forces a rename instead of link and unlink.
   
   
   
 https://github.com/pdinc-oss/git/tree/cygwin-issue-remoteCIFS-rename
   
  snip/
   
   Pseudo code and observations
   ./sha1_file.c:write_loose_object(sha1)
   {
filename=sha1_file_name(sha1)
(fd,tmp_file)=create_tmpfile(filename)
write_buffer(fd)
close_sha1_file(fd)
return move_temp_to_file(tmp_file, filename)
   }
  
   move_temp_to_file(tmpfile, filename)
   {
// I am thinking about forcing renames to
 see if the problem
   exists then as well
// if that works then a per repo config
 option allowing
   for forced renames
if (OBJECT_CREATION_USES_RENAMES) goto try_rename
else if link(tmpfile,filename)
  
   
  Dave has tested a build I made for him on 64 bit Cygwin
and it works. I no longer have access to the environment I
was having this problem in last February. I will try to
investigate this further, but I am not hopeful, maybe Corinna
will have luck on the issue. But I was in a secure corporate
environment and I thought the host based security system
(AV), coupled with the remote file system was causing the
problem, namely files created are not available instantly.
   
  I do think that we should have a config option for
this, as most users who could encounter such a problem are
not likely to be able (or allowed) to rebuild the git
executable themselves.
   
  snip/
   
-Original Message-
From: Corinna Vinschen
Sent: Friday, December 05, 2014 6:35
To: cygwin@cygwin.com
   snip/
What I found in the strace is this:
   
- Create file
 Z:\pic32mx-bmf\.git\objects\30\tmp_obj_YljwNZ

Re: [cygwin] Cygwin's git says error: failed to read delta-pack base object

[Dave L]

On Fri, Dec 5, 2014 at 6:35 AM, Corinna Vinschen
corinna-cyg...@cygwin.com wrote:

 ...

 This looks suspiciously like a bug in the remote filesystem.  Link
 succeeded, so there are two links to the same file in the directory.
 Unlinking link 1 succeeds, so there's still one link to the file in the
 directory, but link 2 is inaccessible as if the file has been deleted
 completely.  Thus, a full POSIX git on this drive is broken.

 Can you please run

   /usr/lib/csih/getVolInfo /cygdrive/z

 and paste the output here?  Maybe I can workaround this in the next
 Cygwin version.

 Here you go:

$ /usr/lib/csih/getVolInfo /cygdrive/Z
Device Type: 7
Characteristics: 10
Volume Name: 
Serial Number  : 1646121781
Max Filenamelength : 255
Filesystemname : NTFS
Flags  : c700ff
  FILE_CASE_SENSITIVE_SEARCH  : TRUE
  FILE_CASE_PRESERVED_NAMES   : TRUE
  FILE_UNICODE_ON_DISK: TRUE
  FILE_PERSISTENT_ACLS: TRUE
  FILE_FILE_COMPRESSION   : TRUE
  FILE_VOLUME_QUOTAS  : TRUE
  FILE_SUPPORTS_SPARSE_FILES  : TRUE
  FILE_SUPPORTS_REPARSE_POINTS: TRUE
  FILE_SUPPORTS_REMOTE_STORAGE: FALSE
  FILE_VOLUME_IS_COMPRESSED   : FALSE
  FILE_SUPPORTS_OBJECT_IDS: TRUE
  FILE_SUPPORTS_ENCRYPTION: TRUE
  FILE_NAMED_STREAMS  : TRUE
  FILE_READ_ONLY_VOLUME   : FALSE
  FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
  FILE_SUPPORTS_TRANSACTIONS  : FALSE

Thanks for looking into this.  FWIW, @Kai on StackExchange has been
able to reproduce the problem. See last comment here:

http://stackoverflow.com/questions/27156413/how-to-configure-cygwin-git-for-two-factor-authentication-at-github-com/27176547?noredirect=1#comment43088817_27176547

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

Re: [cygwin] Cygwin's git says error: failed to read delta-pack base object

[Dave Lindbergh]

 It works fine on a local NTFS volume.

 I get the error when I do it on Z:, which is mapped to a network drive
 (on another Windows box).

It works fine for me on a network drive mounted from another Windows
machine used via the cygdrive prefix:
[..]
I tried with two different mount points, one to a Cygwin-created remote
dir, one to a Windows-created remote dir.

 Is there a workaround? Why does this happen?

No idea.  How do you mount the drive, e.g., what does `mount' print for
the drive?  Or could this be a permission problem?  If all else fails
you could try to find out what happens via strace.

Mount gives:

   Z: on /cygdrive/z type ntfs (binary,posix=0,user,noumount,auto)

It's an ordinary LAN share on another local Windows box, mapped to
drive Z: via Map network drive in Explorer (Win7). I have full
permissions.

You are more than welcome to read the strace output if that'll give
you a clue (it doesn't give me one). All 1.7 MBytes of it are at
http://nerdfever.com/files/strace.txt

(That comes from strace git clone
https://github.com/nerdfever/pic32mx-bmf strace.txt)

I'm still stumped.

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

Cygwin's git says error: failed to read delta-pack base object

[Dave L]

...but the git from github.com works fine.

I installed Cygwin's version of git, and get this:

$ git clone https://github.com/nerdfever/pic32mx-bmf
Cloning into 'pic32mx-bmf'...
remote: Counting objects: 12, done.
remote: Total 12 (delta 0), reused 0 (delta 0)
error: failed to read delta-pack base object
300bdeb2fd209d24afb865584da10b78aa8fefc4
fatal: unpack-objects failed

When I run the git that came from github (the MINGW32 version), it works
fine.

I'm pretty sure this is operator error, but I'm stumped. What am I doing
wrong?

(that repository is public - you can try it yourself)

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

Re: [cygwin] Cygwin's git says error: failed to read delta-pack base object

[Dave Lindbergh]

On Wed, Dec 3, 2014 at 3:42 PM, Jason Pyeron jpye...@pdinc.us wrote:
 [copy off list, because the sourceware system admins throws temper tantrums]
 -Original Message-
 From: Dave L
 Sent: Wednesday, December 03, 2014 15:30

 ...but the git from github.com works fine.

 I installed Cygwin's version of git, and get this:

 $ git clone https://github.com/nerdfever/pic32mx-bmf
 Cloning into 'pic32mx-bmf'...
 remote: Counting objects: 12, done.
 remote: Total 12 (delta 0), reused 0 (delta 0)
 error: failed to read delta-pack base object
 300bdeb2fd209d24afb865584da10b78aa8fefc4
 fatal: unpack-objects failed

 What file system are you on? Local NTFS or remote?

Aha - you're right.

It works fine on a local NTFS volume.

I get the error when I do it on Z:, which is mapped to a network drive
(on another Windows box).

Is there a workaround? Why does this happen?

--Dave

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

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.4

[Habermann, Dave (DA)]

On Oct 29 19:27, Habermann, Dave (DA) wrote:
 issue to a line in the /bin/ssh-user-config file:
 
   pwdhome=$(awk -F: '{ if ( $3 == '${uid}' ) print $6; }'  
 ${SYSCONFDIR}/passwd)

 Ouch.  I missed that when scanning the ssh scripts.

 Sorry, but I'm pretty sure this isn't the only place in the distro
 still checking the passwd and group files :(

No worries...I've got my keys rebuilt and working.  My Dad always told me that
beggars can't be choosers, and I'm clearly the beggar here.  I use your 
stuff routinely every day and am so grateful for the power it brings into my
forced-to-be-on-windows environment.  Hopefully I can be of more service some 
day.

Dave

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.4

[Habermann, Dave (DA)]

On Oct 29 19:06, Habermann, Dave (DA) wrote:
 does NOT work, because my user ID is defaulting to U012345 (upper case
 U).  In this case, however, I can STILL log in if I enter my password.
 
This has been discussed a few months back, but there was no majority
for always lower-case the Cygwin user name.

Must have missed that discussion, but I don't have any problem with it as
you've developed it, just was hoping to flag it to help others as they 
make the transition.

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.4

[Habermann, Dave (DA)]

Found one interesting observation today after switching to the new AD 
authentication.  My ability to use password-less login via SSH suddenly went 
missing.  Although I haven't fully resolved it yet (which I suspect may take 
regeneration/proliferation of keys), it would appear that I've been the victim 
of case sensitivity.  In my old passwd file I had my user ID present in all 
lower case, but apparently in Active Directory my user ID is present as upper 
case.  I am still able to make it log password-less using

ssh u012356@cr

but

ssh cr

does NOT work, because my user ID is defaulting to U012345 (upper case U).  In 
this case, however, I can STILL log in if I enter my password.

I don't really think there is anything to correct here, but just wanted to 
point out the oddity in case anyone else suffers from a similar issue.

Dave

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.4

[Habermann, Dave (DA)]

Using the new AD system, and trying to regenerate ssh keys using 
ssh-user-config I find that I'm getting an error.  I've traced the issue to a 
line in the /bin/ssh-user-config file:

  pwdhome=$(awk -F: '{ if ( $3 == '${uid}' ) print $6; }'  
${SYSCONFDIR}/passwd)

where we are apparently trying to parse the old passwd file (which I've renamed 
off to the side for testing quality).  I can make this work for me right now 
with an ugly hack, but wanted to point it.

$ ssh -V
OpenSSH_6.7p1, OpenSSL 1.0.1j 15 Oct 2014

Dave
 

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Habermann, Dave (DA)]

-Original Message-
From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
Corinna Vinschen
Sent: Monday, October 27, 2014 5:27 PM
To: cygwin@cygwin.com
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

On Oct 27 18:35, Habermann, Dave (DA) wrote:

 Question:  In the documentation you indicate that If cygserver is
 running it will provide passwd and group entry caching for all
 processes in every Cygwin process tree started after cygserver.
 Normally I have several processes (specifically sshd, cygserver, cron
 and httpd2) automatically start up as services when my system boots
 up, and I have not specified the order.  Would it now be desirable to
 have cygserver starting up first, followed by the others?  If so, what
 would be the preferred way to create such a dependency/startup timing?
 Would a service dependency be sufficient?

Now that you mention it... yes, a service dependency might be helpful.
Unfortunately it's tricky to automate this.  Is it possible to add
service deps after having installed a service?

According to 
http://serverfault.com/questions/24821/how-to-add-dependency-on-a-windows-service-after-the-service-is-installed
 it is possible to add a dependency to an already existing service.  I agree it 
would be hard to automate in the install scripts, as one would have to either 
ask the user about their intent to run other services or rely that they 
configured cygserver first and then check to see if it has been already 
configured to determine if a dependency should be created.  I would think that 
some instructions in the docs near the statement mentioned above would be more 
than sufficient, since this is a fine tuning sort of thing.

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Habermann, Dave (DA)]

 should be created.  I would think that some instructions in the docs
 near the statement mentioned above would be more than sufficient,
 since this is a fine tuning sort of thing.

 Agreed.  Do you have some idea how to phrase this?  I'd be grateful
 for a nice two or three paragraphs discussing this.

Will do, but it will take me a bit as I'd like to make sure I've got 
it right, plus I've got some day job interference for the next day
or so.

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Habermann, Dave (DA)]

 should be created.  I would think that some instructions in the docs
 near the statement mentioned above would be more than sufficient,
 since this is a fine tuning sort of thing.

 Agreed.  Do you have some idea how to phrase this?  I'd be grateful
 for a nice two or three paragraphs discussing this.

Have a look...don't hesitate to re-work if my phrasing doesn't fit

!--context section--
The advantage of cygserver caching is that it's system-wide and, as long as 
cygserver is running, unforgetful. Every Cygwin process on the system will have 
the cygserver cache at its service. Additionally, all information requested 
from cygserver once, will be cached inside the process itself and, again, 
propagated to child processes.

!--insertion starts here-
If you automatically start cygwin processes as windows services at system 
startup, you may wish to consider starting cygserver first in order to take 
advantage of this system-wide caching.  To assure that cygserver has started 
prior to starting sshd or other cygwin processes, you may wish to create 
service startup dependencies.  Cygserver should probably wait for Windows TCPIP 
and AFD services before it starts, and then other cygwin process should start 
after cygserver.  Example windows commands to accomplish this (after the 
services already exist) are shown below.  You will need an administrative 
prompt to run the sc config commands.

# Delay Cygserver until TCPIP and AFD have started
# Note the (odd) required space character after depend=

sc config cygserver depend= tcp/afd

# Delay sshd until after Cygserver has started
# Again note the (odd) required space character after depend=

sc config sshd depend= cygserver

# View the Cygserver service details

sc qc cygserver

Note that this sc config command REPLACES any existing dependencies.  The 
above changes will not impact the running instance, only future instances.

# To remove all dependencies from the cygserver service

sc config cygserver depend= /

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Habermann, Dave (DA)]

Loaded the test release here today and found that it seems to work as expected, 
both without the /etc/nsswitch.conf file (operates as before) and with both 
passwd and group set to db in the file.  Only two slightly negative 
observations I've made so far are 1) ps -ef only allows for 8 character UIDs, 
and thus longer UIDs (for example MyMachine+cyg_server) don't show up well and 
2) the very first cygwin process I start seems to take a bit longer to start up 
now (in either mode) than before (7-10 seconds depending on the contents of 
nsswitch).  Perhaps this is possibly due to the fact that I'm accessing AD at 
some distance over a VPN?  However, the SECOND process and all subsequent ones 
seem to start significantly faster than before (THANKS FOR THAT!).

Question:  In the documentation you indicate that If cygserver is running it 
will provide passwd and group entry caching for all processes in every Cygwin 
process tree started after cygserver.  Normally I have several processes 
(specifically sshd, cygserver, cron and httpd2) automatically start up as 
services when my system boots up, and I have not specified the order.  Would it 
now be desirable to have cygserver starting up first, followed by the others?  
If so, what would be the preferred way to create such a dependency/startup 
timing?  Would a service dependency be sufficient?

Thanks again for your efforts on this!

Dave

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Habermann, Dave (DA)]

Read through https://cygwin.com/preliminary-ntsec.html and in general found it 
to be quite useful.  I'm hoping to do some testing perhaps later this week or 
early next.  I have a couple of questions:

1) Any thoughts about the rough timing of this going live?

2) The documentation says (as I read it): Well-known/builtin accounts named as 
in Windows, then (for domain member) Local machine accounts of a domain member 
machine get a Cygwin user name the same way as accounts from another domain: 
The local machine name gets prepended.  As I read this, cyg_serv account 
(under which I currently run SSHD) would now have a new name 
MYMACHINE+cyg_serv.  Am I reading this correctly?  Is there some 
reconfiguration I'll need to do to get SSHD to run properly?

3) I also read Cygwin implements the Solaris API to access Windows ACLs in a 
Unixy way (although your email says Revamp Solaris ACL implementation to more 
closely work like POSIX ACLs are supposed to work).  So is it Solaris or is it 
POSIX, and if Solaris then I wonder why since it seems that everywhere else 
you've tried to be as POSIX as possible.

Thanks for all your hard work on this, I will certainly be one of the 
benefactors (12 Mb group file, takes hours to refresh so not done since this 
time last year).

Dave

Re: [ITA] fish

[Dave Kilroy]

On 13/10/2014 09:33, Andrew Schulman wrote:

I'd like to adopt the fish package.  The package seems to be abandoned.  A
new release is out upstream with multiple security fixes, but the Cygwin
package hasn't been updated.  Emails to the maintainer have bounced, and he
hasn't answered recent discussions on the cygwin list about the need to
update the package and fix some problems in it.

I took the existing cygport script, revised it a bit, added fixes for all
of the known problems, and rolled a new release (below).  If it seems okay,
I'll upload it.

Andrew

x86:
http://home.comcast.net/~andrex2/cygwin/x86/setup.hint
http://home.comcast.net/~andrex2/cygwin/x86/fish-2.1.1-2.tar.xz
http://home.comcast.net/~andrex2/cygwin/x86/fish-2.1.1-2-src.tar.xz

x86_64:
http://home.comcast.net/~andrex2/cygwin/x86_64/setup.hint
http://home.comcast.net/~andrex2/cygwin/x86_64/fish-2.1.1-2.tar.xz
http://home.comcast.net/~andrex2/cygwin/x86_64/fish-2.1.1-2-src.tar.xz

I verified that the problem identified on the list is addressed.

One comment regarding the new config.fish file - can you make the cd 
$HOME dependent upon the CHERE_INVOKING variable being unset? That way 
chere will work for those who set it up for fish. See /etc/profile for 
the bash equivalent.


Thanks,

Dave.

Re: fish PATH problem

[Dave Kilroy]

On 10/10/2014 14:46, Andrew Schulman wrote:


OK, I rolled a new release of fish 2.1.1:

x86:
http://home.comcast.net/~andrex2/cygwin/x86/fish-2.1.1-1.tar.xz
http://home.comcast.net/~andrex2/cygwin/x86/fish-2.1.1-1-src.tar.xz

x86_64:
http://home.comcast.net/~andrex2/cygwin/x86_64/fish-2.1.1-1.tar.xz
http://home.comcast.net/~andrex2/cygwin/x86_64/fish-2.1.1-1-src.tar.xz

Please try it out, and let me know how it works for you.  If it's okay and if 
Konrad
doesn't answer, then I'll adopt the package and put out the new release.  I've
switched to using fish as my default shell now, so I want to see it maintained.

I downloaded both versions and verified that `fish -l` didn't show the 
path issue. Success.



Thanks,

Dave.

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

Re: fish PATH problem

[Dave Kilroy]

On 08/10/2014 18:36, Alive4Ever wrote:

On Wednesday, October 08, 2014 11:08:43 AM you wrote:

Does that work. It seemed to have the same issue as noted in the
following thread https://cygwin.com/ml/cygwin/2014-04/msg00111.html

Dave.

It should work, although I don't recommend running cygwin apps directly
via wincmd, unless the underlying shell is invoked as interactive login
shell.
So I just re-tested starting a fish login shell after updating cygwin64. 
As I suspected, fish has not been updated since the thread I quoted (Apr 
2014), and the issue remains (with my install). Google doesn't show the 
maintainer on list since the announcement (Oct 2013), and his e-mail 
bounces. Cc'ing anyway, just in case.

You can find the example of how to invoke cygwin correctly by looking at
Cygwin.bat file on cygwin root directory.

I'm aware of how to invoke login shells and start cygwin, thanks.

Andrew: appreciated if you can confirm whether simply invoking as a 
login shell works for you.



Regards,

Dave.

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

Re: fish PATH problem

[Dave Kilroy]

On 09/10/2014 18:26, Andrey Repin wrote:

Greetings, Andrew Schulman!


Bad news: the PATH problem is back.  When I run
C:\cygwin64\bin\fish.exe -l
I get the same error messages as before on startup, and PATH doesn't
include /bin /usr/bin /sbin /usr/sbin.
How are /bin /usr/bin etc. normally added to the PATH?  I don't see any
logic to do it in /usr/share/fish/config.fish.

That logic probably should be included.
At least, bash does that in login files.



That was my conclusion as well*. Question is, should fish provide the 
configuration, or should base-files cover all shells?


Andrew: thanks for confirming. If you're still looking for the logic and 
where to put it, I suggested something in * as well.



Regards,

Dave.

* https://cygwin.com/ml/cygwin/2014-04/msg00175.html

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

Re: fish PATH problem

[Dave Kilroy]

On 08/10/2014 10:57, Andrew Schulman wrote:

On Wednesday, October 08, 2014 05:13:54 AM Andrew Schulman wrote:

When I try to start fish directly from the Windows shell instead of from
bash, I get a boatload of errors, like this:

I suggest you to read fish manual page, and find how to invoke fish as login
shell. On bash and zsh, there is '-l' flag so that they behave with fresh
environment variables.

Doh! Right. Thanks.


Does that work. It seemed to have the same issue as noted in the 
following thread https://cygwin.com/ml/cygwin/2014-04/msg00111.html


Dave.

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

Re: Deafult to bash so $chere will work (possibly?)

[Dave Kilroy]

On 24/08/2014 11:02, Michelle Pace wrote:

HOORAY! Thanks Andrey, this command worked for me:

$ chere -i -t mintty -s bash


I'm glad you got it to work. chere is attempting to use the shell 
defined in your passwd (as retrieved by getent). The shell being 
returned is '/bin/sh'.


It looks like I forget to add an entry handle to handle sh... I'll try 
to fix this up for the next version.


Thanks for the report,

Dave.


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

Missing enscript dependency

[Dave Kilroy]

Hi all,

Just tried to use enscript for the first time in a while, and noticed 
that I no longer have an lpr...


Given that `enscript foo.txt` prints to the default printer, it seems 
that enscript is missing a dependency on cygutils-extra.



Thanks,

Dave.

Re: Possible bug with chere 1.4 when configuring for fish

[Dave Kilroy]

On 10/04/2014 11:06, Ronald Fischer wrote:

I've had more time to look around. If you add the following to the file
~/.config/fish/config.fish (create it if you haven't already got one),
then things should work as intended:

if status --is-login
set PATH /usr/local/bin /usr/bin $PATH
end

Alternatively drop it in the fish global startup file,
/usr/share/fish/config.fish.

I tried the variant of putting it into the global startup file, it
doesn't resolve the problem for me. I'll play around a bit with it as
soon as I have time (I'm a first-time user of fish and am busy with
other things right now, so this might take some time).

You're right, when using the default -2. If you switch to -1, things get 
better, but then the chere functionality of cd'ing to a directory fails. 
Fun.


-2 mode fails because fish recognizes a login shell by $0 being exactly 
-fish, but chere is using -/bin/fish. There's a trivial patch* to 
fish.cpp which could make this work better for us.


-1 mode fails because fish would prefer cygpath was run on the argument 
first. I'm not sure why this works in bash.


I'll try put together a fix for the latter issue, but it may be a while 
before I can upload*.


Konrad, are you able to chase the former issue? NB Konrad's email 
provider is out of action.


Ronald, your choices as the moment:
- Add cygwin\bin to your windows path
- Use the above snippet without the check for a login shell, and method 
-2. If you don't start too many subshells you're probably OK. If you do 
need subshells, you could change the check to test if /bin is already in 
the path.




Dave.

* New employer, need to clarify status of open source contributions etc.

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

Re: Possible bug with chere 1.4 when configuring for fish

[Dave Kilroy]

On 07/04/2014 23:35, Dave Kilroy wrote:

On 07/04/2014 13:02, Ronald Fischer wrote:

I have installed fish 2.1.0. Works fine, when invoking a new fish shell
manually.

However, when doing a

chere -ifcm -t mintty -s fish

and invoke the new fish shell from the Windows Explorer context menu, I
get plenty of error messages, like this:

snip

(more of this kind follow).

This looks like there is a problem the PATH, but this happens even when
I use the -2 on chere when installing the shell. Note that bash or zsh
shells installed via cygwin work fine.


Thanks for the report.

I've just checked my x86_64 and x86 installation. Things are working 
on my installation as I have c:\cygwin\bin on my standard windows 
path. When I remove it and invoke fish, I get the errors that you 
highlight. Similarly when echo'ing $PATH under the broken fish, 
/usr/bin is not one of the entries.


I need to have a play around to see how I can fix this, but I thought 
cygwin prepended /usr/bin to the path...


I've had more time to look around. If you add the following to the file 
~/.config/fish/config.fish (create it if you haven't already got one), 
then things should work as intended:


if status --is-login
set PATH /usr/local/bin /usr/bin $PATH
end

Alternatively drop it in the fish global startup file, 
/usr/share/fish/config.fish. Konrad, would you consider adding the above 
fragment to config.fish in the next release? That should bring fish into 
line with the other shells*. You might also consider adding some of the 
other environment variables like PRINTER etc etc.



Thanks,

Dave.
---
* FYI
Bash gets /usr/local/bin and /usr/bin prefixed to its path by 
/etc/profile (supplied by base-files)

mksh and posh also use /etc/profile
tcsh gets these prefixed by /etc/csh.login (supplied by tcsh)
zsh uses /etc/zprofile (supplied by zsh)




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

Re: Possible bug with chere 1.4 when configuring for fish

[Dave Kilroy]

On 07/04/2014 13:02, Ronald Fischer wrote:

I have installed fish 2.1.0. Works fine, when invoking a new fish shell
manually.

However, when doing a

chere -ifcm -t mintty -s fish

and invoke the new fish shell from the Windows Explorer context menu, I
get plenty of error messages, like this:

snip

(more of this kind follow).

This looks like there is a problem the PATH, but this happens even when
I use the -2 on chere when installing the shell. Note that bash or zsh
shells installed via cygwin work fine.

In this 'broken' fish shell, I enter

 echo $PATH; uname

and get the following output:

snip
/cygdrive/c/windows/system32 /cygdrive/c/windows
/cygdrive/c/windows/System32/Wbem
/cygdrive/c/windows/System32/WindowsPowerShell/v1.0
/cygdrive/c/windows/System32/WindowsPowerShell/v1.0 /cygdrive/c/Program
Files (x86)/Common Files/Citrix/System32 /cygdrive/c/Program Files
(x86)/Citrix/ICAService /cygdrive/c/Program Files (x86)/Citrix/System32
snip
To compare with, when I output the PATH from a normal fish shell (i.e.
one which I have invoked from, say, a bash shell), I get:

 echo $PATH
.:/home/ronald.fischer/bin:/usr/local/bin:/usr/bin:/cygdrive/c/windows/system32:/cygdrive/c/windows:/cygdrive/c/windows/System32/Wbem:/cygdrive/c/windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program
Files (x86)/Common Files/Citrix/System32:/cygdrive/c/Program Files
(x86)/Citrix/ICAService:/cygdrive/c/Program Files
(x86)/Citrix/System32:/usr/lib/lapack

We see that in fish, /usr/bin is missing from the PATH. This is strange,
in particular if I install chere fish with option -2, because in this
case, fish will be invoked via bash.

Ronald


Thanks for the report.

I've just checked my x86_64 and x86 installation. Things are working on 
my installation as I have c:\cygwin\bin on my standard windows path. 
When I remove it and invoke fish, I get the errors that you highlight. 
Similarly when echo'ing $PATH under the broken fish, /usr/bin is not one 
of the entries.


I need to have a play around to see how I can fix this, but I thought 
cygwin prepended /usr/bin to the path...



Regards,

Dave.

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

[ANNOUNCEMENT] Updated: chere-1.4-1 (x86 and x86_64)

[Dave Kilroy]

Version 1.4-1 of chere has been uploaded and should be available from 
mirrors shortly.


chere is a script allowing you to add Explorer context menus to start 
cygwin in the selected directory.


This script supports x86 and x86_64 simultaneously. If you have 32 and 
64 bit cygwin installed on the same machine, you can add separate 
context menu entries to start 32 or 64 bit terminals. The default menu 
text does not differentiate between 32 and 64 bit, so if you do this you 
should use the -e option.


Changes:
* Use getent to identify the user login shell when the shell is 
unspecified or set as passwd

* Support fish shell

Fixes:
* Allow cd'ing to directories containing single quotes when using 
registry one-liners (-1)


  *** 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:


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

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

http://sourceware.org/lists.html#unsubscribe-simple

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


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

Updated: chere-1.4-1 (x86 and x86_64)

[Dave Kilroy]

Version 1.4-1 of chere has been uploaded and should be available from 
mirrors shortly.


chere is a script allowing you to add Explorer context menus to start 
cygwin in the selected directory.


This script supports x86 and x86_64 simultaneously. If you have 32 and 
64 bit cygwin installed on the same machine, you can add separate 
context menu entries to start 32 or 64 bit terminals. The default menu 
text does not differentiate between 32 and 64 bit, so if you do this you 
should use the -e option.


Changes:
* Use getent to identify the user login shell when the shell is 
unspecified or set as passwd

* Support fish shell

Fixes:
* Allow cd'ing to directories containing single quotes when using 
registry one-liners (-1)


  *** 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:


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

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

http://sourceware.org/lists.html#unsubscribe-simple

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

Re: Testers needed: New passwd/group handling in Cygwin

[Dave Kilroy]

On 13/02/2014 21:48, David Stacey wrote:

On 13/02/2014 19:36, m0viefreak wrote:

Grepping through /bin I found at least one other package
that makes use of /etc/passwd as a file directly (cvsbug), but
since I don't have everything installed I can only assume there
are more cygwin-packages and other programs someone might build
from source.


My complete install is proving quite useful this week:

chere
xhere

All of these reference /etc/passwd; some of the above also use 
/etc/group.
chere (with the -s passwd) reads etc/passwd and starts the default shell 
of the current user from the explorer context menu. For now, I will 
expect users wanting this functionality to keep using/etc/passwd. If we 
grow a mechanism where the login shell can be queried easily, I'll 
update chere to use that.



Regards,

Dave.

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

[ANNOUNCEMENT] Updated: chere-1.3-1 (x86 and x86_64)

[Dave Kilroy]

Version 1.3-1 of chere has been uploaded and should be available from 
mirrors shortly.


chere is a script allowing you to add Explorer context menus to start 
cygwin in the selected directory.


This version of the script supports x86 and x86_64. If you have 32 and 
64 bit cygwin installed on the same machine, you can add separate 
context menu entries to start 32 or 64 bit terminals. The default menu 
text does not differentiate between 32 and 64 bit, so if you do this you 
should use the -e option.


Changes:
* Add background context menus on Windows 7 and later
* Support 64 bit cygwin

Fixes:
* Change to appropriate drive when shell is cmd
* Quote path for cmd correctly
* Uninstall correctly when cygwin not in path


  *** 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:


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

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

http://sourceware.org/lists.html#unsubscribe-simple

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


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

Re: Are there any plans to add chere in the x64 version?

[Dave Kilroy]

On 12/12/2013 17:01, klonos wrote:
Is there a feature request filed and any link to it so I can follow? 
Thanx in advance.



In case you missed it, I've just released an initial version of chere 
for x86_64



Dave.

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

SSH key for upload access

[Dave Kilroy]

Name: Dave Kilroy
Package: chere
 BEGIN SSH2 PUBLIC KEY 
Comment: 4096-bit RSA, converted by Dave@dalamar from OpenSSH
B3NzaC1yc2EDAQABAAACAQC8bLP25QYkZ9cFSRmKhNemR2DmLT5E5Vc2Aboc6+
2vz7ZIIKJ5JltcUq2Bag/OAry3eQdQI4wWBwDsYFssdm2EMXnCHIiD9h+q34Jamaz/MYfq
AKqVSiMPrXd90v9cx4uJUKGSQhIljVblpXm64W5hHrI/Hh45YVU+46wCa8iyOQ+nhtd1m/
nLpu77uODmNGu5QGETvY3sLRCMbxRJBo0YUiEAAQbNOl0aZmaWv4lPfclQ8ggYPtOaPnRi
F7JFjXyNznpJ6QR7BH44zG+2HPKLxVxoDYobhW66FeAj/bQlPtT0pSxgE9FtBxVt6klhBX
28jvi1igbtqPuqr9+DxPWRnMqDvmMVFFvybMXygFjT3Iyt9/nCPr8RHE1iDVyNMMdckU0I
uRt1qbDYDWnxTWjoRVEZXyLuvXsioPmTvveaOVIzh8qHsxZMMaW5tZCZ7MeBCevGP12zS8
xuOcf9cCV1ewmtwKs2nH9LGfySHTBlM3qV42cOHy9f0DhF/QYUwYpcp/roqzOJDblQ4Iiw
j/rbbRfbQynC8oHkm8TYXicdE7Zxu9tMmKI+1LNpS7RY/J1EU9UIp2FtQ1fBVv6bTPMNbL
NdjFiaXZICLoppVt6DgUqzNEsg0G/nYrHUSqoFEkEzodt6ydhLjA1eBr91UtA1qyKDCvdT
iWy+lExMLIh0rQ==
 END SSH2 PUBLIC KEY 

Re: Are there any plans to add chere in the x64 version?

[Dave Kilroy]

On 12/12/2013 17:01, klonos wrote:
Is there a feature request filed and any link to it so I can follow? 
Thanx in advance.


There's no feature request or link. I suspect the 32 bit package will 
work with x64 but haven't had time to check.



Dave.

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

Permissions Issue with Nested and/or local Groups

[Garber, Dave (GE Power Water, Non-GE)]

We have a file share on machine1.  Machine1 has a local group, share_read, that 
contains a domain group share_readers and share_readers has a list of 
individuals with access to the share.  From Windows access is fine.  In Cygwin, 
ls -l is showing no access to the files for the users.  Adding the domain group 
directly to the share solves the problem.  I'm even able to duplicate this 
behavior locally on my machine with a group and a folder local to the machine, 
so it's not the fact that it's a network share.  And adding my domain account 
directly to the local group does not work either.  So it appears the culprit 
might be the local group.  Any thoughts?

Thanks In Advance,
Dave


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

Re: chere + mintty doesn't work with mapped drives

[Dave Kilroy]

On 03/12/2013 10:21, Corinna Vinschen wrote:

On Dec  2 23:58, Charles Butterfield wrote:

Any suggestions on how to have a shortcut (or something similar) that
runs mintty as admin, but has no global effect on other mintty launches?

You seem to have gotten something else wrong here.  If the shortcut has
the run as admin flag, it only affects this shortcut.  I have two
shortcuts on the desktop, one called Cygwin64 Terminal, the other one
Cygwin64 Admin.
I think the difference is where you select the checkbox. There's one in 
Compatibility-Privilege Level-Run as admin, and another in 
Shortcut-Advanced-Run as admin. The compatibility one is telling 
windows that to execute mintty correctly it needs admin privileges, so 
it always runs mintty this way. The latter is the one that just affects 
the shortcut.


Glad you got to the bottom of this in the end.


Dave.

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

Re: chere + mintty doesn't work with mapped drives

[Dave Kilroy]

On 01/12/2013 21:09, Corinna Vinschen wrote:

On Dec  1 15:48, Charles Butterfield wrote:

-Original Message-
From: David Kilroy [mailto:kilr...@googlemail.com]
Can you run the following commands from mintty running bash vs cmd
running bash:

cygpath -u y:\apps
test -d /cygdrive/y/apps
echo $?

Result of the first command should be /cygdrive/y/apps 2nd command
shouldn't output anything Result of 3rd command should be 0 (true)

Dave.

Results from MINTTY+BASH:
--
$ cygpath -u y:\apps
/cygdrive/y/apps

$ test -d /cygdrive/y/apps

$ echo $?
1

Results from CMD+BASH
--
$ cygpath -u y:\apps
/cygdrive/y/apps

$ test -d /cygdrive/y/apps

$ echo $?
0

Are you starting mintty with run as administrator by any chance?
Corrina's right - check that the same user is being used in both cases. 
I don't think this would explain why it's not working from the context 
menus though. Finding out why bash under mintty doesn't think 
/cygdrive/y/apps is a directory is the key.


Workaround: if you change everything in the if [ ! -z $2 ] test in 
xhere to the snippet below, chere will attempt to change to the 
directory (but may fail)



Regards,

Dave.

if [ ! -z $2 ]; then
 CHERE_DIR=`$CYGPATH $2`
 NETWORK_PATH=/$CHERE_DIR
 if [ -d $CHERE_DIR ]; then
  cd $CHERE_DIR

 # If the full path doesn't exist, this is prob a network path
 elif [ -d $NETWORK_PATH ]; then
  cd $NETWORK_PATH

 # Not a directory? Take a guess...
 else
  cd $CHERE_DIR

 fi
fi


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

Re: chere + mintty doesn't work with mapped drives

[Dave Kilroy]

On 29/11/2013 22:11, Charles Butterfield wrote:

Dave wrote:

Can you clarify which isn't working:
a) a network share mapped to a drive letter, e.g N:\my\network\location

This is my situation.  I have my Y: drive mapped to a Linux Samba server.  See 
more details below


b) network share accessed via \\ e.g. \\server\path\my\network\location

Not doing this.


Are you right clicking on a directory and selecting the menu item, or right 
clicking a blank spot in the RH pane? The two result in different logic, with
the latter having to guess it's a network path.

I am right clicking on a directory name in either (tried both) the LH or RH 
pane of an explore.exe window.  In both cases what happens
Is that a new window is launched (good) with an initial title of the form 
/bin/xhere /bin/bash.exe Y:\apps.  After a brief pause, I see
Starting /bin/bash.exe, than another brief pause and the window title changes to 
/cygdrive/c/WINDOWS/system32 and I get a
Bash command prompt.  The PWD is just what the title indicates (i.e. 
.../system32)
The xhere script should pass y:\apps to cygpath to get the cygwin path, 
which should be /cygdrive/y/apps. IIRC /cygdrive/y may not be visible 
via ls, but it should be usable. I'm guessing the path is failing the 
directory test... in which case adding a trailing else to always cd 
$CHERE_DIR would fix things for you



Dave.

P.S. I'm also having trouble figuring out how to post replies to what I see on 
the web archive.  I did NOT get any email reply to my prior post, it just 
showed up on the web archive (that was good).  I carefully checked my spam 
quarantine areas several times to be sure.  Actually my first post on this 
topic was my second attempt to  post.  I had to add myself to the white-list 
which I didn't notice at first since the white-list suggestion was stuck in MY 
stupid stupid Outlook spam filter (Thanks so much Outlook).

In any event, I have cobbled together something that resembles a reply to an email that I 
have really scraped off the web archive.  That seems awfully complicated.  Surely I'm 
missing something.  But I just cannot see the Reply button on the archive.  
Is this like when my wife says, its right there and points to it and yep, its really 
right there?  :-(

I just replied to list on the last message. This time I've made sure 
you're in cc.


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

Re: chere + mintty doesn't work with mapped drives

[Dave Kilroy]

On 29/11/2013 17:29, Charles Butterfield wrote:

I've noticed that if I install a right-click shell entry via chere and use 
minty as the terminal that I cannot start a shell on a network share.  This is true 
regardless of which of the following two installation commands I execute:

chere -I -t mintty -s bash
chere -i -2 -t mintty -s bash

A related clue is that when using a mintty terminal I cannot see network shares 
in /cygdrive, but when using the default chere shell I can see the network 
shares mapped to drives (e.g. /cygdrive/y/...).

Any suggestions?

Can you clarify which isn't working:

a) a network share mapped to a drive letter, e.g N:\my\network\location
b) network share accessed via \\ e.g. \\server\path\my\network\location

I think a) should always work.

Are you right clicking on a directory and selecting the menu item, or 
right clicking a blank spot in the RH pane? The two result in different 
logic, with the latter having to guess it's a network path. You may be 
able to figure out what's going on by adding a few echos to /bin/xhere



Dave.

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

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 17/04/2013 19:59, Yaakov (Cygwin/X) wrote:
 On 2013-04-11 07:32, Dave Korn wrote:
 On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote:
 Your boehm-gc patch can replace my java-libgc-win32.patch, provided it
 works properly.

It appears to, libjava testsuite results are as good as they've
 ever been,
 although I don't know whether or not the testsuite checks the
 invocation API.
   It's certainly the more complete approach to take than just not
 supporting
 the register/unregister methods, as confirmed by the fact that upstream
 boehm-gc has implemented it for Cygwin.
 
 There is a mistake in that patch.  The DEBUG_CYGWIN_THREADS conditionals
 need to be if, not ifdef, as elsewhere in the same source file.

  Oops, that was a cut'n'paste error when I copied the skeleton of those
functions from pthread_support.c, where #ifdef DEBUG_THREADS is the form to
use.  Thanks for spotting it; fixed in my repo ready for next release.

cheers,
  DaveK

Re: [ANNOUNCEMENT] Updated: expat 2.1.0-1

[Dave Korn]

On 16/04/2013 14:25, Warren Young wrote:
 On 4/11/2013 14:38, Dave Korn wrote:
 
 The static archive /usr/lib/libexpat.a was present in 2.0.1-1(*) and is 
 missing in 2.1.0-1(**), was that intentional?
 
 I think I got that, um, feature for free when I converted to cygport for
 that package.  Someone is passing --disable-static to the configure script,
 and it isn't me.
 
 I've fixed this with CYGCONF_ARGS=--enable-static  The static library 
 does now appear in the -devel package.
 
 The .a is about 3x the size of the .dll.  Is that normal, or am I supposed
 to be stripping the .a before packaging it?

  Yes, totally normal, it's a whole set of individual object files with all
their overhead, rather than just the linked text/data content of those files.
 No, don't strip it, that decision should be left until linking a final
executable.

 Does someone actually want this static library?  I'm going to RFU it 
 anyway, since I've gone to the trouble of fixing it, but I was curious if
 it actually mattered to someone.

  GDB apparently prefers linking statically to libexpat.  Dunno why, but it
saves me adjusting my dependencies in a package I'm shipping to a customer, so
thanks :)

cheers,
  DaveK


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

Re: Debugging totally broken with latest everything?

[Dave Korn]

On 15/04/2013 18:14, Christopher Faylor wrote:
 On Mon, Apr 15, 2013 at 05:03:17PM +0100, Dave Korn wrote:
  Some notes on the above:

  The same happens with both the previous version and current snapshot of the
 cygwin dll.  It also happens with both current gdb and an old gdb
 6.8.0.20080328-cvs that I have lying around.

  The hw.exe in question is your bog-standard hello world, compiled with -g
 -O0 using gcc4-4.5.3-3.

  kill -9 won't kill gdb; I have to use Windows task manager.  If I've
 attached gdb to the hung gdb, I can kill it from there using the k 
 instruction.

  Anyone else having similar problems?
 
 You're probably seeing a known bug in gdb where it no longer works well
 when run from a console window.  There is a race where gdb tries to get
 tty information from a stopped cygwin process.  Although I didn't
 introduce the problem, I have tried to fix it from time to time without
 much luck.

  It must be an interaction between gdb and the cygwin dll, since my
old-and-previously-working-just-fine-in-a-console gdb-6 has also stopped 
working.

 Debugging from mintty will probably work better.

  It certainly does.  Thanks for the tip.

cheers,
  DaveK


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

Re: 64bit: cygstdc++-6.dll

[Dave Korn]

On 13/04/2013 11:07, Corinna Vinschen wrote:
 On Apr 12 21:31, Dave Korn wrote:

   Nope, just vague about input and output sections.  Enabling auto imports
 selects a linker script that causes all the .rdata in the input object files
 
 Out of curiosity, which linker script is that?  What's the difference
 to the normal one?

  Well, since auto import became the default, it is the normal one, but that
aside, they're both built-in scripts.  Compare the output from ld
--disable-auto-import --verbose and ld --verbose to see the difference.  Or
you can look at the copies that ld installs into
/usr/i686-pc-cygwin/lib/ldscripts/; the .x file is the plain one, the .xa is
the auto-import one.

 to be placed in the plain old .data section of the output executable, so that
 it will be RW-mapped when loaded.  Apparently the Windows runtime loader 
 can't
 deal with updating import references into RO-mapped pages.  The consequence 
 of
 that is that all the pages with import references get modified and COWed on
 load and so it reduces the amount of the mapped memory that can be shared
 between instances of the same executable.
 
 I'm a bit puzzled in terms of the additional R/W space this amounts to.
 When loading an executable, there is the entire IAT which has to be
 modified by the loader, anyway.  That includes all functions and data
 imported from other DLLs.  To what extent do the auto-import entries add
 to that?  If it's just another indirection, that would add 5 bytes
 (absolute jmp) on i686, and 8 bytes (an absolute address in a pseudo-GOT
 table) on x86_64 per auto-imported symbol.  That's not a lot, probably
 not even a 4K page per executable.  How significant is that?

  But it's not a separate contiguous list of pointers.  What's happening is
that there are various structures in the .rdata that contain imported
pointers.  They'll be scattered throughout the .rdata, along with all the
other const data that /doesn't/ have pointers that have to be auto-imported.
So depending on the percentages and how it happens to end up in the link
order, it could be any or all of the .rdata pages that get COWed on startup.

   I'm not sure how significant this is in general usage, and I'm generally in
 agreement that removing auto-import would be a significant hassle.
 
 That, too.

  Yeah.  So I guess we have to live with it.

  However it's probably still worth having the markers in libstdc headers,
because that at least makes it possible for people to write applications and
disable auto imports if they're only using libstdc (and/or other shared libs
that also have markers in their headers).  That would be desirable for
something that you're going to want to spawn many instances of (either
consecutively or concurrently).

cheers,
  DaveK

Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

[Dave Korn]

On 13/04/2013 15:49, Corinna Vinschen wrote:
 On Apr 13 12:39, Andy Koppe wrote:
 On 13 April 2013 10:03, Corinna Vinschen wrote:
 On Apr 13 06:55, Andy Koppe wrote:
 I'm struggling to get setup.hint generation to work. Is it supported
 with cygport 0.11.3 as currently in the distros? Below is the
 mintty.cygport I've got. Do I need to do anything else to trigger it?

 Cygport prints  mintty requires: at the end, which is correct as
 it doesn't require anything beyond the Cygwin DLL, but there's no
 setup.hint.
 Sure?  Did you look into the dist subdir in your builddir after
 the install stage?  It should contain a complete mintty dir for
 upload.
 You're right, there is, inside the working directory created by
 cygport, and it looks correct. I'd expected the setup.hint to appear
 next to the .cygport and the packaged .tar.bz2 files.
 
 IIU Yaakov C, the dist dir is the way to go in future.  The toplevel
 files is the old style, supposed to go away at one point.  I like the
 dist dir approach a lot.

  Glad to hear that.  I also much prefer the dist dir to plonking all the
files in the toplevel with no directory structure.  It's much simpler for
uploading.

cheers,
  DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 11/04/2013 21:42, Thomas Wolff wrote:
 Am 11.04.2013 14:34, schrieb Dave Korn:

 Also, I don't plan on doing it unless there's significant demand.
 I would appreciate to keep it as gcc-3.

  Fancy being the maintainer for it then? ;-)

 The reason is quite peculiar; gcc-4
 changed the order of variables in the stack frame of a function call, which
 led to one very specific interworking malfunction (between mintty and
 mined) which in turn unveiled a very subtle bug. This is material for very
 interesting debugging exercises for students... Not sure whether it's
 significant but the changed variable order might in fact affect other
 software as well. -- Thomas

  Only seriously buggy software.  Anything in a C program that attempts to
make inferences about the layout of the stack frame is invoking undefined
behaviour.

cheers,
  DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 12/04/2013 11:44, Yaakov (Cygwin/X) wrote:
 On 2013-04-11 23:24, Dave Korn wrote:

 Most of the discussed features are already in the latest release.  Right 
 now, the major difference between the release and git master is full 
 support for x86_64-pc-cygwin, but there are a number of other bugfixes and
 enhancements.  I hope to cut a release from master as early as next week.
 
 (Also, what is the unversioned file format?)
 
 Where the file is named foo.cygport and NAME/VERSION/RELEASE are defined 
 inside of the cygport(5) instead of deriving these from the filename as 
 before.  My gcc.cygport is an example of this, as well as the use of 
 setup.hint generation.

  Great, then I'll take full advantage of the new stuff.

 Huh?  Cygport doesn't own CC any more than autotools if it's not being
 used. CC is a user variable.  It belongs to make, and the make info page 
 in the section on Makefile Conventions says that the user can
 substitute alternatives.  Maintainers aren't the only people who use the
 compiler!
 
 *Within the scope of cygport*, cygport(1) is the user and it controls CC
 based on a number of factors.
[ ... ]
 Saying CC=gcc-4 obviously doesn't work in all those scenarios.

  Well, yes, but we're talking here about whether I should leave a symlink
called gcc-4.exe in /usr/bin for the benefit of any end users who might have
makefiles (or other scripts) that aren't in any way related to cygport at all,
so none of that is relevant.

 You still haven't explained exactly what the problem is.  You don't
 need libgcj on the system in order to build a native gcc with java.
 Why would the presence or lack of libgcj*.la make a difference?
 
 Ah, that's where our misunderstanding is.  It's the presence of 
 libstdc++.la that is required for libjava to build, not libgcj.la.
[ ... ]
 Oh, now I get it.  What *really* happened is that last time you tried this,
 you still had GNOME .la files on your system, some of which contained
 references to libstdc++.la because of the then-embedded copy of harfbuzz in
 the Pango libraries.  So when you installed an .la-less gcc then rebuilt
 gcc, the link failed because of the remaining libstdc++.la references in
 libgtkpeer's many (sub)deps; the same would have happened building *any*
 GTK+/GNOME package with libtool.
 
 This would have worked even then if you had run the 
 fix-libtool-scripts-for-latest-gcc-runtimes.sh script with my modifications
 thereto (Ports gcc commit 00c6f36) immediately after installing the
 .la-less gcc.  In any case, the current versions of the GNOME libraries do
 not include .la files, so you won't have this problem with rebuilding gcc.
 (You should still run the modified script in any case.)

  Ah, thanks for the explanation.  That makes sense to me.

 Don't get me wrong, libtool is still the best option for building libraries
 portably, but it does not need .la files on the system to do so with shared
 libraries.  Now that we've figured out what the problem really was, and
 that it doesn't exist anymore, could we drop them from the next release?

  Absolutely, assuming nothing goes wrong when I test it.

  I should still package the updated version of
fix-libtool-scripts-for-latest-gcc-runtimes.sh and invoke it postinstall for
the benefit of any other .la files that are still on the system, right?

cheers,
  DaveK

Re: 64bit: cygstdc++-6.dll

[Dave Korn]

On 12/04/2013 16:57, Corinna Vinschen wrote:
 Dave?  Ping?

  Heh, don't panic, I'm still here!  Just needed some sleep :)

 On Apr 11 15:37, Corinna Vinschen wrote:
 On Apr 11 12:16, Corinna Vinschen wrote:
 On Apr 10 18:16, Corinna Vinschen wrote:
 On Apr 10 16:49, Dave Korn wrote:
 On 10/04/2013 10:57, Yaakov (Cygwin/X) wrote:

 Could you explain the necessity of the dllimport's in the same patch?
   The idea is to one day be able to move away from having auto-import 
 enabled
 by default in binutils, so that .rdata can go back into the 
 read-only-mapped
 .rdata section and be shared between processes as it ought.
 Doesn't that affect applications which use something like

   extern int optind;

 in their code?  Kai did quite a job to get this working on x86_64 by
 implementing the medium/large code models for x86_64, and Cygwin's
 x86_64 gcc uses the medium code model by default.  Disabling this again
 would be rather counterproductive.
 What about this issue?  If the idea is to revert all automatism which
 allows to declare external variables in DLL s without dllimport, then
 I don't think that's a good idea for Cygwin.

 If I misunderstand the issue, please say so.
 Oh, and, btw., I don't quite understand

   so that .rdata can go back into the read-only-mapped .rdata section

 Typo?

  Nope, just vague about input and output sections.  Enabling auto imports
selects a linker script that causes all the .rdata in the input object files
to be placed in the plain old .data section of the output executable, so that
it will be RW-mapped when loaded.  Apparently the Windows runtime loader can't
deal with updating import references into RO-mapped pages.  The consequence of
that is that all the pages with import references get modified and COWed on
load and so it reduces the amount of the mapped memory that can be shared
between instances of the same executable.

  I'm not sure how significant this is in general usage, and I'm generally in
agreement that removing auto-import would be a significant hassle.

  I think it might explain why, when I'm running the GCC testsuite and have
been through a few tens of thousands of compiles, I frequently see a whole
bunch of gcc.exe instances just sitting there, doing nothing and using almost
no CPU for 20 to 30 seconds while their stack traces indicate they're stuck in
kernel paging-and-caching-related code.

  But overall, I guess we have to live with it.

cheers,
  DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 11/04/2013 03:23, Yaakov (Cygwin/X) wrote:
 On 2013-04-10 11:56, Dave Korn wrote:
It takes 11 hours on a triple-core machine at -j6 to build and
 package GCC.
   In order to guarantee consistent reproduction I always respin the built
 package from -src package through two generations.  It then takes
 three to
 five days to run enough of the testsuite to be confident that the
 packaged
 compiler works well.  So it'd be next week at the earliest.
 
 While your diligence is admirable, I think some common sense review can
 be used here, as only one of my patches actually affects the compiler
 itself, and even then only the specs.  I'm not exactly messing around
 with code generation here.

  Yes, I've looked at most of your patches already, I'm not saying there's any
complication in adding them, it's just that I didn't want to wait another
howevermany days before getting 4.7.2-2 out there.  I'll put them all into the
next release, which I'll get on with pronto.

 BTW, in your absence, it was agreed that gcc3 should go away and that
 gcc4 should be *the* gcc in the distro.  This will simplify the build
 and drop the dep on 'alternatives'.  Can this get into the next release?

  Yep, sure.  *sigh*, I'm sure we'll suddenly find out that someone was using
it and wants to know where it's gone.  (I suppose if that happens I could
always consider rolling a gcc3 package with all -3 suffixed executables.)

  I'll need to make sure not to lose the cc.exe - gcc.exe symlink, and it
might be useful for backward-compatibility to provide a bunch of -4 suffixed
links to the other executables for people who've written CC=gcc-4 in their
Makefiles, but that can be done with just ln rather than using alternatives.

 I don't understand why there's a libquadmath0-devel; like the other C
 libraries, this should just be part of gcc-core.  

  Hmm.  I got the impression that libquadmath could stand alone, i.e. be
useful in a non-GCC context, but I guess not or it would be installing its
include files into /usr/include rather than the GCC private include dir.  I'll
merge it into gcc-core in the next release as you suggest.

 This was only
 necessary for libstdc++, and only so long as .la files were included.
 IIRC we agreed to remove them, but your reason for not doing so in the
 .cygport isn't clear to me.

  Without the .la files, libjava doesn't build.  And in general I don't want
to second-guess the compiler: since the upstream makefiles think it's
important to install them, so do I.

 Also, could you please explain the reasons for the ehdebug, execstack,
 and shared-libgcc patches?

  ehdebug: When we first switched from sjlj to dw2 exceptions, there were so
many corner case bugs that kept cropping up across multiple releases that I
wanted to hang onto the debugging code.  During development the debugging
output was under control of a variable that I replaced by a #define 0 just
before the release.  It's obsolete now, I'll drop it, but it was incredibly
useful for the first few gcc4 releases.

  execstack: Trampolines need an executable stack.  DEP on recent Windows OSs
marks the stack non-executable; this option allows the stack to be set
executable during the runtime startup, without having to disable DEP for the
entire process.  Think I may have inherited it from Danny Smith.  Mingw has it
upstream, I'll get it committed there for Cygwin too.

  shared-libgcc: Makes linking against shared libgcc the default for all
executables; previously it was only on by default for DLLs.  Vital for
importing TLS variables from DLLs, upstream since 4.8.0.

cheers,
  DaveK

Re: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj

[Dave Korn]

On 11/04/2013 05:47, Christopher Faylor wrote:
 On Thu, Apr 11, 2013 at 02:21:00AM +0100, Dave Korn wrote:
 On 11/04/2013 02:05, Dave Korn wrote:
 On 11/04/2013 01:18, Christopher Faylor wrote:
 gcc won't be available until this is fixed.
   Oops.  I'll just edit it on the server.  Sorry for the inconvenience.
  Should be ok now I trust.  Apologies once more, I've updated my local hint
 file in svn to prevent it happening again.
 
 No problem.  Your fix is confirmed.  Thanks for the quick response.
 
 cgf

  Being a confirmed cynic^W^Wexperienced programmer, I always like to stay
online for a while after committing or releasing something, in case of any
aftermath.

cheers,
  DaveK

Re: [ITP] libffi (attn: Dave Korn)

[Dave Korn]

On 11/04/2013 03:44, Yaakov (Cygwin/X) wrote:
 On 2013-04-10 20:40, Dave Korn wrote:
Surely there'll be a problem if the curr: version of everything
 else goes to 4.7.3-1 but there's no matching version of libffi4?
 
 Not as long as 4.5.3-3-src remains.

  Well, there have been some bugfixes in gcc/libffi upstream, so as long as
anyone out there might conceivably have some homebrew app that they've linked
against libffi4, I'd like to do them the favour of giving them a final updated
version to live with until they get round to rebuilding against libffi6.  It's
no skin off my (or anyone else's) nose as far as I can see.

cheers,
  DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 11/04/2013 11:13, Corinna Vinschen wrote:
 On Apr 11 01:58, Yaakov (Cygwin/X) wrote:
 On 2013-04-11 01:02, Dave Korn wrote:
   Yep, sure.  *sigh*, I'm sure we'll suddenly find out that someone was 
 using
 it and wants to know where it's gone.  (I suppose if that happens I could
 always consider rolling a gcc3 package with all -3 suffixed executables.)
 3.4 is EOL and should have been dropped long ago; we simply don't
 have the resources to support it ourselves.  Just about any software
 that people are building today either works with recent 4.x or the
 distros have a patch for it.
 
 FWIW, I agree.
 
 
 AOL-Corinna

  I said I could consider it, I didn't say I was necessarily going to do it :)

  Still, you'd be surprised the number of questions I see on random websites
(stackoverflow, linuxquestions and similar) where someone's asking how to
install an old GCC to build some old software.

cheers,
  DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 11/04/2013 13:22, NightStrike wrote:

 Speaking of which..   4.8 is out...

  Point.  Anyone got any particular preference whether I go for a 4.7.3 or
4.8.0 release next?  Maybe do a 4.7.3 curr: and then a 4.8.0 test: package?

cheers,
  DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 12/04/2013 00:36, Yaakov (Cygwin/X) wrote:
 On 2013-04-11 07:35, Dave Korn wrote:
 On 11/04/2013 13:22, NightStrike wrote:
 Speaking of which..   4.8 is out...
 
 So is GNOME 3.8.0, but I tend to let others deal with the early bugs and 
 catch up by .1 or even .2.
 
 Point.  Anyone got any particular preference whether I go for a 4.7.3 or 
 4.8.0 release next?  Maybe do a 4.7.3 curr: and then a 4.8.0 test: 
 package?
 
 For the same reason, I'd go with 4.7.3 first.  But let's not wait until 4.9
 to update GCC again this time, okay? :-)

  Yeh, promise!

cheers,
  DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 12/04/2013 00:28, Yaakov (Cygwin/X) wrote:
 On 2013-04-11 07:32, Dave Korn wrote:
 On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote:
 Also in the 4.8 branch is a patch to unversion the LTO plugin; it 
 applies to 4.7 as well.
 
 I'll take a look for that.  Does it really matter?  I don't suppose we
 need support swapping LTO plugins between different versions of the 
 compiler, it's totally a for-internal-use-only thing.
 
 Does it really, *really* matter?  Perhaps not, but IMO it's the proper 
 thing to do for all arches, since the LTO plugin is just that, a plugin. 
 (If Apple were to still use GCC, it *would* matter, as there are 
 fundamental differences between Mach-O dylibs and bundles.)

  Well, maybe I'll just wait until I get to a 4.8 release naturally and let it
happen then.  Or maybe I'll backport the patch for 4.7.3.  I'll see how I feel
at the time, since it's not /critical/ and I'd like to prioritise.

 Something else you missed: cygport supports a new, unversioned file 
 format, and creates setup.hint files, including dependency detection.
 I suggest using git master right now.
 
 Wouldn't that mean that the -src package I ship won't rebuild with the 
 version from the standard distribution?
 
 I usually recommend using cygport git master, and a number of maintainers
 track it.

  I want to ship packages that the general public can rebuild using the
standard distro really.  Do you have any idea of a schedule for releasing
these features?  (Also, what is the unversioned file format?)

 That was never right, CC isn't supposed to be (ab)used like that.  I 
 don't mind not supporting that going forward.
 
 Well it's not exactly any trouble so I may as well do it.  If you're not 
 using autotools, CC is yours to do what you like with isn't it?
 
 No, it's not.  In the cygport manual, [Definitions] should be treated as 
 readonly, and [Variables] can be altered.

  Huh?  Cygport doesn't own CC any more than autotools if it's not being used.
 CC is a user variable.  It belongs to make, and the make info page in the
section on Makefile Conventions says that the user can substitute
alternatives.  Maintainers aren't the only people who use the compiler!

 How could removing the .la files during postinstall affect building 
 libjava beforehand?
 
 Heh, of course not, I'm not suggesting time travel!  I should have said 
 *re*build: without the .la files installed on the user's system, the -src
  package fails to rebuild.  I imagine (but didn't test) that applies to 
 building plain upstream SVN/tarball as well.
 
 You still haven't explained exactly what the problem is.  You don't need 
 libgcj on the system in order to build a native gcc with java.  Why would
 the presence or lack of libgcj*.la make a difference?

  Ah, that's where our misunderstanding is.  It's the presence of libstdc++.la
that is required for libjava to build, not libgcj.la.  That's because of a
failure during linking (the awt peer IIRC) when libtool can't locate libstdc
to link against.  That in turn happens because it uses gcc.exe to link, not
g++.exe, and that in turn happens because libtool is invoked with the CC tag,
not CXX, and that in turn happens because the module is composed entirely of
.c files and does not have any .cc files to trigger libtool's language
detection to know that C++ is required.

 As for the makefiles installing the .la files, upstream isn't 
 choosing to do so, that's just how libtool works.  Some Linux
 distros, including Fedora, have been removing them from all binary
 packages (except when they are needed by lt_dlopen() and friends), and
 for very good reason.
 
 What's the very good reason?
 
 Because they cause more trouble than they're worth, e.g. necessitating 
 hacks such as fix-libtool-scripts-for-latest-gcc-runtimes.sh.  This is a 
 good summary of some of the issues:
 
 https://lists.fedoraproject.org/pipermail/mingw/2012-January/004421.html

  Hmm.  I need to digest that some more.  I'm not entirely certain that it
applies to the compiler runtime libs, because people often do use static
linking against them when they want to make standalone executables.

 shared-libgcc: Makes linking against shared libgcc the default for
 all executables; previously it was only on by default for DLLs.
 Vital for importing TLS variables from DLLs, upstream since 4.8.0.
 
 Here we go again...
 
 Huh?
 
 We started with 4.3 using the static libgcc by default, then switched to 
 linking everything with -lgcc_s, then with 4.5 switched to doing so by 
 default only for DLLs (to minimize rebase errors iirc), and now we're going
 back to shared across-the-board.  I'm not complaining, and it seems like
 the right thing to do, but it does evoke a sense of deja vu.

  Ah, I didn't remember that we'd taken a step back at one point during the
process, I thought it had been a linear progression but that does ring a bell.
 Well, I'm sure now that it was the wrong way to try and solve the rebase
problems, it's seriously

Re: FIXED: GCC can't find its header directoriescy

[Dave Korn]

On 11/04/2013 07:08, Duncan Roe wrote:
 Thanks Dave - removing the old cygwin dlls from C:\WINDOWS fixed gcc 
 alternatives.

  Glad to hear it!

 I put them there because I like to have the odd cygwin utility available
 to CMD.EXE. 
 
 May put them back - but will take more care with them in future,

  The better way to do that is just to add your cygwin\bin dir to your PATH in
the Windows environment variables.  That way you get all your cygwin stuff
available in cmd.exe but it's always the up-to-date stuff from your main
installation.

  (The only problem I've ever run into in this approach is that both Cygwin
and MSVC have a link.exe command, so you can end up getting the wrong one.
You can avoid this by any combination of specifying full paths to the
particular one you want, choosing whether to put cygwin\bin at the start or
end of your Windows PATH, or customising your vcvars.bat to make sure the MSVC
version is earlier in the PATH when you launch it.  I've never found it to be
a big problem compared to the convenience of having a real grep available in
cmd.exe!)

cheers,
  DaveK


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

Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.7.2-2

[Dave Korn]

On 11/04/2013 00:58, Dave Korn wrote:

   I would like to express my gratitude to JonY for stepping into the breach
 caused by my absence from the Cygwin community and releasing the first test
 version of GCC 4.7 series.  He did a very difficult job and did it well and
 deserves the highest of praise for doing so.

  It was suggested to me off-list, and I concur, that this is worthy of a gold
star, if not two.  May it please the maintainer of the stars to consider my
request?

cheers,
  DaveK

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

Re: [ANNOUNCEMENT] Updated: expat 2.1.0-1

[Dave Korn]

On 12/06/2012 13:31, Warren Young wrote:
 PACKAGE DESCRIPTION
 ===
 
 Homepage: http://sourceforge.net/projects/expat/
 License : MIT-like
 
 Expat is a C library for parsing XML, originally created and maintained
 by James Clark, but since 2001 taken over by a loose group of contributors.
 
 
 CYGWIN-SPECIFIC CHANGES SINCE LAST RELEASE
 ==
 
 None.  This release simply tracks the 2.0.1 - 2.1.0 upstream release.

  The static archive /usr/lib/libexpat.a was present in 2.0.1-1(*) and is
missing in 2.1.0-1(**), was that intentional?

cheers,
  DaveK
--
*  - http://cygwin.com/packages/libexpat1-devel/libexpat1-devel-2.0.1-1
** - http://cygwin.com/packages/libexpat1-devel/libexpat1-devel-2.1.0-1


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

Re: 64bit: cygstdc++-6.dll

[Dave Korn]

On 10/04/2013 10:57, Yaakov (Cygwin/X) wrote:

 Could you explain the necessity of the dllimport's in the same patch?

  The idea is to one day be able to move away from having auto-import enabled
by default in binutils, so that .rdata can go back into the read-only-mapped
.rdata section and be shared between processes as it ought.

cheers,
  DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 10/04/2013 16:47, Christopher Faylor wrote:

 It isn't clear to me why we'd be spending days discussing this when
 presumably the patches apply without too much effort.  Some of the
 patches here:
 
 http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc
 
 look worthwhile to me.  If we're talking about only gcc 4.7 fixes then
 it looks like we're only talking about five patches, none of them are to
 source files, and none of them are very big.

  It takes 11 hours on a triple-core machine at -j6 to build and package GCC.
 In order to guarantee consistent reproduction I always respin the built
package from -src package through two generations.  It then takes three to
five days to run enough of the testsuite to be confident that the packaged
compiler works well.  So it'd be next week at the earliest.

  Hence I'm uploading 4.7.2-2 now.

cheers,
  DaveK

Re: [ITP] libffi (attn: Dave Korn)

[Dave Korn]

On 10/04/2013 10:50, Yaakov (Cygwin/X) wrote:
 On 2013-04-10 04:29, Corinna Vinschen wrote:
 On Apr 10 04:06, Yaakov (Cygwin/X) wrote:
 libffi development moved out of GCC into a separate project a long
 time ago; the copy included in GCC is used for libgcj, but only as a
 convenience (static) library, and it is usually a few point releases
 behind the standalone version.  Finally, last month, GCC was patched
 upstream to stop installing its copy (a similar patch for 4.7.2 and
 4.8.0 is in Ports git).

 Therefore I think the time has arrived to join Fedora and Debian and
 switch i686 to the standalone version.  (We are already using this
 for x86_64.)  This will also simplify building many of the ~20
 packages which use libffi and expect the .pc file provided only by
 the standalone version.

 http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/libffi

 ftp://ftp.cygwinports.org/pub/cygwinports/temp/libffi/

 Isn't that independent from what gcc itself does?  If so, feel free
 to upload.
 
 Only the man3 pages collide with gcc4-core.  But gcc's libffi.dll.a will
 take priority over the one in /usr/lib (see gcc -print-search-dirs), so
 manual intervention will be necessary until our gcc stops shipping libffi.

  Okeydokey.  Upstream libffi generates cygffi-6.dll, so what I'll do is
incorporate the patch (along with your others) into 4.7.3-1 (which will be a
full curr: version release), and ship one last version of libffi4 (marked
obsolete) with that but make sure the man pages, static import lib etc (-devel
stuff basically) is not packaged.  That'll probably be in ten days or so, at
which point you can upload the standalone libffi.  Makes sense?

cheers,
  DaveK

Re: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj

[Dave Korn]

On 11/04/2013 01:18, Christopher Faylor wrote:
 gcc won't be available until this is fixed.

  Oops.  I'll just edit it on the server.  Sorry for the inconvenience.

cheers,
  DaveK

Re: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj

[Dave Korn]

On 11/04/2013 02:05, Dave Korn wrote:
 On 11/04/2013 01:18, Christopher Faylor wrote:
 gcc won't be available until this is fixed.
 
   Oops.  I'll just edit it on the server.  Sorry for the inconvenience.

  Should be ok now I trust.  Apologies once more, I've updated my local hint
file in svn to prevent it happening again.

cheers,
  DaveK

Re: [ITP] libffi (attn: Dave Korn)

[Dave Korn]

On 11/04/2013 02:33, Yaakov (Cygwin/X) wrote:

 After applying my libffi-noinst.patch, all you really need to do is
 remove the libffi4-4.7.* test releases and leave 4.5.3-3 in the distro
 until all libffi-dependent packages are rebuilt (most of which are mine).

  Surely there'll be a problem if the curr: version of everything else goes to
4.7.3-1 but there's no matching version of libffi4?

cheers,
  DaveK

[ANNOUNCEMENT] Updated: experimental package: gcc4-4.7.2-2

[Dave Korn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


  I have just uploaded an updated GCC-4 package to cygwin.com.  It will be
arriving at your favourite mirror next time it synchronizes itself with the
official Cygwin repository.

  This is a test release of GCC 4.7.2 which replaces the earlier
test release.  It reverts the package dependencies in the Cygwin repository to
those that are correct for the current full version of GCC, 4.5.3-3, as
setup.exe can only support one set of dependencies for all versions of a
package.  This means you may need to select some of the new packages manually,
depending on the set of languages you are installing; see the important note
section in From the README below.

  In addition, this release restores libffi and java which were unavailable
from the previous test version.

  It also makes linking against shared libgcc the default for executables as
well as DLLs, which is necessary for correct sharing of thread-local variables
imported by executables from DLLs.

  I would like to express my gratitude to JonY for stepping into the breach
caused by my absence from the Cygwin community and releasing the first test
version of GCC 4.7 series.  He did a very difficult job and did it well and
deserves the highest of praise for doing so.


--ooOOOoo--
PLEASE SEND BUG REPORTS, PROBLEMS, ETC. TO THE CYGWIN MAILING LIST.
--ooOOOoo--


OBTAINING THE RELEASE
=

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.exe, fill in all of the options, and make appropriate choices on the
Select Packages screen. Because this is a test version release, you will
need to manually select any packages and dependent libraries you require: see
below for full details.


NEWS


  From the README:

IMPORTANT NOTE ABOUT DEPENDENCIES AND RUNTIME LIBRARIES
===

Cygwin's setup.exe does not handle a situation where an experimental package
version has different dependencies from the main current version.  For this
reason, the dependencies listed in the Cygwin package repository are those
required by the mainstream (4.5.3-3) release of Cygwin GCC, as those will be
correct for the majority of users.  Anyone wishing to install the test version
of GCC will need to ensure they select manually select the corresponding new
versions of the runtime libraries required.  These dependencies are:

gcc4-java: Requires libgcj13.
gcc4-objc: Requires libobjc4.
gcc4-ada: Requires libgnat4.7.
gcc4-fortran: Requires libquadmath0, libquadmath0-devel.
libgfortran3: Requires libquadmath0.

Cygwin port maintained by: Dave Korn
dave.korn.cygwin AT gmail.com.use.the.list.please
Please address all questions to the main Cygwin mailing list.

This is the key used for signing Cygwin GCC releases:

pub   1024D/6A388C3E 2008-05-31
uid  Dave Korn (release signing key)
 dave.korn.cygwin AT gmail.com
sub   4096g/D4E41590 2008-05-31

Also available at a key-server near you!

- -BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.4.9 (Cygwin)

mQGiBEhBdVwRBADGS7UWOR8lvHOcOs161cRjTw1Yp3Qj4Xy5JbaSQFZ6m+DTM7GD
y4tPrM1jr6uYGzikdNzYL6tWKUDvVYjs7bwYJXBQ7ryeLJ4LXs+8cmIFIl4uMc8P
BEpT67gs1+MchBemr1B/s4V8s9laX81mMYd73qqefuCnbUU8+iBKBzfDhwCg6xQU
yIORoWJz5qIHwO23N2uuuKUD/0AsLJOMV1Ig/NVK8ZMss4ozIsgOiBBJ7ZQ9bzzR
8D5EhahVTwPJ7dMXGKWfb21gJHtYjOtwDYJyc5HdIHBPWylI0u6vkiIDD4TZjSDA
fIMBgTKp9SjKBtr4ZJzYZUguTFGJFBDLyieyUDWTXBVQSaDASzEjwwdbbKo5/wzY
GzvYA/458txhAz1GoB3hnaEJgIK0HaOVjetvZif9QQ1L0x10EIjdwgxN8pMR3Gv8
d+pALJpivIe5eMrU2QLpSbiK5QRkndJBYdiEobLCY3Ca6elRB8/ioKUyOzngtAe9
ny0dUNEWDxwtk2yJSxMrcfRjSJMs+4efCqXrRIkfXr1ibE1JybQ8RGF2ZSBLb3Ju
IChyZWxlYXNlIHNpZ25pbmcga2V5KSA8ZGF2ZS5rb3JuLmN5Z3dpbkBnbWFpbC5j
b20+iGMEExECACMCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAUCSMUtrgIZAQAK
CRBN0oLlajiMPrQTAKCJhzyfI8MKSJjYNTXYCo/GITfvTQCgp2Jw70u5NQojF09f
uPhfnX+xed+IYwQTEQIAIwIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheABQJIVRdm
AhkBAAoJEE3SguVqOIw+l4QAoJSM49UfFNHx3jSTV3+o+TQF9Uo/AKDa5iFeDTuO
10t5Rpng0OWJPTR7N7kEDQRIQXVcEBAAnOffXRQSAPcJKW9z8OXwd0UmNFGZbjb5
CW53i2HYmqiYfMLL6XHyyB2o0e0jZuao/+PgxnoVaqpPh7DXYfjup/u5ll2kAK2I
VImGIFYifRLQAWCivQa4LXWR2EvIi1MURrmEjN+JKStBAySiED21QELetUGNzeYT
rsWBpHmAibcBAbwFPw0mhFPqvApcrpMJhALehCqPEu/rfeUnziqo8pdpeKkL0ENl
GsNONGYhDIjzexclRNFFYwzmK2cS5sxwyH94OxBABfgwxsVYB0+zsdjPk3JybK52
+MIcYQU4NBoCYo184pFJ4QhzKmt/8sAicaxLsU4DHqyy9SwFH1cV1Su5RN3DGG2S
0hFImqyTeCiSW2FDSgOtAF0ImEY3HNkfLgych5nFKRj0itPdFG/t6qCJKLf8JsZP
2QDaLQO+42jwn6Y47PaBEMJGttPaY6guATJqVefqayKI4j22w2le4PLxYJ3fIlqi
5rS5m6mJV2ZFRuqSgmGPDgb8+vnvTG/PCTCcK3j4jzUvJ3bX9FtyV9cFnlF+CfQc
ZMdx4qHrhKgoiqJt19Mk8rb19L6KqyLNgJyqvwOcsX8P2yM8t/FAuUeg1EgnYbMz
RywEHEa2+rj2R1FPJGtJdOQLgrPgd4m9t5Eq7zFPuJgKNlWHf1Y0M82A37iYnWna
DyqON5+pPQ8ABAsP/jOOvQjU79Pd8ph7c2LK+UUjGPQVYO5bwUOCDs9ctSIbQgPh

Re: 1.7.15: gcc fails to load: missing cygmpfr-4.dll

[Dave Korn]

On 11/04/2013 02:57, Duncan Roe wrote:
 I have just installed cygwin on this system.
 When I try to compile a small program, I get this error:
 
 /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe: error while loading shared
 libraries: cygmpfr-4.dll: cannot open shared object file: No such file
 or directory

  Sorry about that, I missed a dependency when I uploaded it.

  It's actually fixed as of a few hours ago, but the fix must not have reached
your mirror yet.

  Just use setup.exe to install libmpfr4.

cheers,
  DaveK


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

Re: GCC can't find its header directoriescy

[Dave Korn]

On 11/04/2013 06:12, Duncan Roe wrote:
 Thanks guys for the pointers to cygmpfr-4.dll. Got it.
 
 This problem with headers started happening on an old installation so I
 reinstalled but it still happens:

 ignoring nonexistent directory /usr/include

 strerror.c:2:19: error: no include path in which to search for stdio.h

 12:33:27$ ls /usr/include

 locale.hnetdb.h reent.h stdio.h  termios.h   wait.h

 /usr/include definitely exists but gcc / cpp claims it does not.
 Since this just started happening I wonder whether it is caused by
 some update to Windows. (Win XP SP3).
 
 Anyone else seen anything like it? I'm stuck,

  Bizarre.  I've never seen anything like it, nor your problem with altdir
invalid.  However I've got one guess about what might be interfering, from
your cygcheck.out:

45k 2010/08/15 C:\WINDOWS\cyggcc_s-1.dll - os=4.0 img=1.0 sys=4.0
   cyggcc_s-1.dll v0.0 ts=2010/8/15 8:57
   982k 2009/12/23 C:\WINDOWS\cygiconv-2.dll - os=4.0 img=1.0 sys=4.0
   cygiconv-2.dll v0.0 ts=2009/12/24 0:25
31k 2011/11/28 C:\WINDOWS\cygintl-1.dll - os=4.0 img=1.0 sys=4.0
   cygintl-8.dll v0.0 ts=2009/4/3 12:15
31k 2009/04/03 C:\WINDOWS\cygintl-2.dll - os=4.0 img=1.0 sys=4.0
   cygintl-8.dll v0.0 ts=2009/4/3 12:15
31k 2009/04/03 C:\WINDOWS\cygintl-8.dll - os=4.0 img=1.0 sys=4.0
   cygintl-8.dll v0.0 ts=2009/4/3 12:15
   224k 2010/06/15 C:\WINDOWS\cygpcre-0.dll - os=4.0 img=1.0 sys=4.0
   cygpcre-0.dll v0.0 ts=2010/6/15 14:10
10k 2009/12/14 C:\WINDOWS\cygsigsegv-2.dll - os=4.0 img=1.0 sys=4.0
   cygsigsegv-2.dll v0.0 ts=2009/12/14 23:56
  2586k 2010/08/31 C:\WINDOWS\cygwin1.dll - os=4.0 img=1.0 sys=4.0
   cygwin1.dll v0.0 ts=2010/8/31 17:58
 Cygwin DLL version info:
 DLL version: 1.7.7

  Those could well have been interfering.  Get rid of all Cygwin-related DLLs
from your C:\WINDOWS folder (maybe stash them away somewhere safe in case they
turn out to be needed by some Cygwin-dependent application you've got on your
system), then reinstall everything using setup.exe (click on Default next to
the All category in the Category view until it switches to Reinstall,
ignore the couple of warning boxes that pop up on the way there) and see if it
all works better once that's completed.

cheers,
  DaveK



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

Updated: experimental package: gcc4-4.7.2-2

[Dave Korn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


  I have just uploaded an updated GCC-4 package to cygwin.com.  It will be
arriving at your favourite mirror next time it synchronizes itself with the
official Cygwin repository.

  This is a test release of GCC 4.7.2 which replaces the earlier
test release.  It reverts the package dependencies in the Cygwin repository to
those that are correct for the current full version of GCC, 4.5.3-3, as
setup.exe can only support one set of dependencies for all versions of a
package.  This means you may need to select some of the new packages manually,
depending on the set of languages you are installing; see the important note
section in From the README below.

  In addition, this release restores libffi and java which were unavailable
from the previous test version.

  It also makes linking against shared libgcc the default for executables as
well as DLLs, which is necessary for correct sharing of thread-local variables
imported by executables from DLLs.

  I would like to express my gratitude to JonY for stepping into the breach
caused by my absence from the Cygwin community and releasing the first test
version of GCC 4.7 series.  He did a very difficult job and did it well and
deserves the highest of praise for doing so.


--ooOOOoo--
PLEASE SEND BUG REPORTS, PROBLEMS, ETC. TO THE CYGWIN MAILING LIST.
--ooOOOoo--


OBTAINING THE RELEASE
=

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.exe, fill in all of the options, and make appropriate choices on the
Select Packages screen. Because this is a test version release, you will
need to manually select any packages and dependent libraries you require: see
below for full details.


NEWS


  From the README:

IMPORTANT NOTE ABOUT DEPENDENCIES AND RUNTIME LIBRARIES
===

Cygwin's setup.exe does not handle a situation where an experimental package
version has different dependencies from the main current version.  For this
reason, the dependencies listed in the Cygwin package repository are those
required by the mainstream (4.5.3-3) release of Cygwin GCC, as those will be
correct for the majority of users.  Anyone wishing to install the test version
of GCC will need to ensure they select manually select the corresponding new
versions of the runtime libraries required.  These dependencies are:

gcc4-java: Requires libgcj13.
gcc4-objc: Requires libobjc4.
gcc4-ada: Requires libgnat4.7.
gcc4-fortran: Requires libquadmath0, libquadmath0-devel.
libgfortran3: Requires libquadmath0.

Cygwin port maintained by: Dave Korn
dave.korn.cygwin AT gmail.com.use.the.list.please
Please address all questions to the main Cygwin mailing list.

This is the key used for signing Cygwin GCC releases:

pub   1024D/6A388C3E 2008-05-31
uid  Dave Korn (release signing key)
 dave.korn.cygwin AT gmail.com
sub   4096g/D4E41590 2008-05-31

Also available at a key-server near you!

- -BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.4.9 (Cygwin)

mQGiBEhBdVwRBADGS7UWOR8lvHOcOs161cRjTw1Yp3Qj4Xy5JbaSQFZ6m+DTM7GD
y4tPrM1jr6uYGzikdNzYL6tWKUDvVYjs7bwYJXBQ7ryeLJ4LXs+8cmIFIl4uMc8P
BEpT67gs1+MchBemr1B/s4V8s9laX81mMYd73qqefuCnbUU8+iBKBzfDhwCg6xQU
yIORoWJz5qIHwO23N2uuuKUD/0AsLJOMV1Ig/NVK8ZMss4ozIsgOiBBJ7ZQ9bzzR
8D5EhahVTwPJ7dMXGKWfb21gJHtYjOtwDYJyc5HdIHBPWylI0u6vkiIDD4TZjSDA
fIMBgTKp9SjKBtr4ZJzYZUguTFGJFBDLyieyUDWTXBVQSaDASzEjwwdbbKo5/wzY
GzvYA/458txhAz1GoB3hnaEJgIK0HaOVjetvZif9QQ1L0x10EIjdwgxN8pMR3Gv8
d+pALJpivIe5eMrU2QLpSbiK5QRkndJBYdiEobLCY3Ca6elRB8/ioKUyOzngtAe9
ny0dUNEWDxwtk2yJSxMrcfRjSJMs+4efCqXrRIkfXr1ibE1JybQ8RGF2ZSBLb3Ju
IChyZWxlYXNlIHNpZ25pbmcga2V5KSA8ZGF2ZS5rb3JuLmN5Z3dpbkBnbWFpbC5j
b20+iGMEExECACMCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAUCSMUtrgIZAQAK
CRBN0oLlajiMPrQTAKCJhzyfI8MKSJjYNTXYCo/GITfvTQCgp2Jw70u5NQojF09f
uPhfnX+xed+IYwQTEQIAIwIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheABQJIVRdm
AhkBAAoJEE3SguVqOIw+l4QAoJSM49UfFNHx3jSTV3+o+TQF9Uo/AKDa5iFeDTuO
10t5Rpng0OWJPTR7N7kEDQRIQXVcEBAAnOffXRQSAPcJKW9z8OXwd0UmNFGZbjb5
CW53i2HYmqiYfMLL6XHyyB2o0e0jZuao/+PgxnoVaqpPh7DXYfjup/u5ll2kAK2I
VImGIFYifRLQAWCivQa4LXWR2EvIi1MURrmEjN+JKStBAySiED21QELetUGNzeYT
rsWBpHmAibcBAbwFPw0mhFPqvApcrpMJhALehCqPEu/rfeUnziqo8pdpeKkL0ENl
GsNONGYhDIjzexclRNFFYwzmK2cS5sxwyH94OxBABfgwxsVYB0+zsdjPk3JybK52
+MIcYQU4NBoCYo184pFJ4QhzKmt/8sAicaxLsU4DHqyy9SwFH1cV1Su5RN3DGG2S
0hFImqyTeCiSW2FDSgOtAF0ImEY3HNkfLgych5nFKRj0itPdFG/t6qCJKLf8JsZP
2QDaLQO+42jwn6Y47PaBEMJGttPaY6guATJqVefqayKI4j22w2le4PLxYJ3fIlqi
5rS5m6mJV2ZFRuqSgmGPDgb8+vnvTG/PCTCcK3j4jzUvJ3bX9FtyV9cFnlF+CfQc
ZMdx4qHrhKgoiqJt19Mk8rb19L6KqyLNgJyqvwOcsX8P2yM8t/FAuUeg1EgnYbMz
RywEHEa2+rj2R1FPJGtJdOQLgrPgd4m9t5Eq7zFPuJgKNlWHf1Y0M82A37iYnWna
DyqON5+pPQ8ABAsP/jOOvQjU79Pd8ph7c2LK+UUjGPQVYO5bwUOCDs9ctSIbQgPh

Re: 64bit: cygstdc++-6.dll

[Dave Korn]

On 25/03/2013 08:52, Corinna Vinschen wrote:
 On Mar 24 03:33, Yaakov (Cygwin/X) wrote:

 In any case, the error is a result of adding one of Dave Korn's patches:

 http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc;a=blob;f=4.7-libstdc-dllimport.patch;hb=refs/heads/4.8#l29

 I have omitted that patch in the new 4.8.0-1.  Hopefully Dave can
 explain the purpose and necessity of that patch, since it would seem
 that using (at least that hunk of) it would require rebuilding most
 C++ packages in 64bit/release; if it's really necessary, then we
 will want to do that sooner rather than later.

  I believe the patch is no longer necessary.  I added it originally after a
discussion about the implications of exporting typeinfo from DLLs with Danny
Smith in the GCC bugzilla; he was of opinion that there might be incomplete
typeinfos that could not be fully resolved until final link-time of an
application, so the purpose of this patch was to place typeinfo objects into
the cygstdc++.dll.a rather than in the DLL itself.  The idea being that every
app that linked against the DLL would get a copy of the still-relocatable
typeinfo object files from the import library during its own final link.

  I'm now convinced that Danny was needlessly worried.  The cxx-abi does refer
to this situation, in section 2.9.1:

 bNOTE/b: Note that the full structure described by an RTTI descriptor
 may include incomplete types not required by the Standard to be completed,
 although not in contexts where it would cause ambiguity. Therefore, any
 cross-references within the RTTI to types not known to be complete must be
 weak symbol references.

  But I don't think this applies to any of the built-in types in libstdc, so I
think it's safe to include their typeinfo in the DLL and export it.

 That I don't quite understand either.  If this is only about missing
 exported symbols and not about the name, how are the already built
 C++ packages affected?  They could be built, so they didn't use this
 symbols, apparently.

  Removing the patch should generate a backwardly-compatible DLL.  Existing
applications already linked against the DLLs will have their own copies of the
typeinfo objects pulled in from the import library, so it won't matter that
the newer DLL also exports such a name (note that we compare typeinfos by name
string under Cygwin, rather than by pointer equivalence.)  New applications
linking against the new DLL will simply pull in an import table reference
rather than the entire typeinfo object file.

  The backward incompatibility came from adding the patch after previously
having released a version of the DLL without the patch which therefore had all
the typeinfos exported, as the applications linked against the previous
version of the DLL would still expect the typeinfo imports to be available,
but now the typeinfos would only be available as objects in the import library.

  In short: it was a precautionary measure, it's now superfluous.  I'll remove
it from the next full release of 32-bit GCC as well.

cheers,
  DaveK

Re: 64bit: cygstdc++-6.dll

[Dave Korn]

On 09/04/2013 11:30, Yaakov (Cygwin/X) wrote:
 On 2013-04-09 02:08, Dave Korn wrote:
 On 25/03/2013 08:52, Corinna Vinschen wrote:
 On Mar 24 03:33, Yaakov (Cygwin/X) wrote:
 In any case, the error is a result of adding one of Dave Korn's
 patches:

 http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc;a=blob;f=4.7-libstdc-dllimport.patch;hb=refs/heads/4.8#l29


 I have omitted that patch in the new 4.8.0-1.  Hopefully Dave can
 explain the purpose and necessity of that patch, since it would seem
 that using (at least that hunk of) it would require rebuilding most
 C++ packages in 64bit/release; if it's really necessary, then we
 will want to do that sooner rather than later.

I believe the patch is no longer necessary.
 
 Does that apply to the entire dllimport patch or just that hunk?

  Just the hunk with the --exclude-modules-for-implib.

cheers,
  DaveK

GCC-4.7.2-2: Go/No-go?

[Dave Korn]

Hi all,

  I have a release of 4.7.2-2 ready to upload.  It fixes the dependencies back
to the 4.5.3-3 curr: version dependencies, makes TLS vars exported from DLLs
work and restores java and libffi.  I've also been running the testsuite over
the last few days and the results look quite reasonable.

  Yaakov thinks (http://cygwin.com/ml/cygwin-apps/2013-04/msg00032.html) that
I shouldn't release it until I've integrated all his patches.

  I think (http://cygwin.com/ml/cygwin-apps/2013-04/msg00057.html) that it's
worth uploading as a stop-gap to address the mentioned problems and
integrating Yaakov's patches for the next release.

  Could the list please help us make a decision?

cheers,
  DaveK

Re: starting cygwin shell

[Dave Korn]

On 07/04/2013 19:50, Christopher Faylor wrote:
 On Sun, Apr 07, 2013 at 06:16:17PM +, Gene wrote:

 save: fork_level=1 SetHandleInformation() failed: fd 0 handle 0x3 type
 2: Th e parameter is incorrect.
 
 That error message doesn't seem to be coming from Cygwin.  I have
 grepped the Cygwin DLL and *sh* and don't see it anywhere.
 
 Are you possibly using other binaries besides Cygwin ones?

  A quick google suggests it comes from MKS.  Trying to mix Cygwin tools and
MKS ones at the same time won't generally work well, and is probably the cause
of the shell problems too - MKS apparently is known to have problems under Win7.

  Gene, try removing MKS from your PATH setting.

cheers,
  DaveK


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

Re: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)

[Dave Korn]

On 04/04/2013 10:13, Yaakov (Cygwin/X) wrote:
 On Sun, 31 Mar 2013 19:57:09 +0100, Dave Korn wrote:
   And the reroll failed to build because of the problem JonY ran into with
 java.  Turns out that libjava keys off the presence of pthread_getattr_np
 (added to the DLL a few versions ago) to decide whether to invoke a couple of
 boehm-gc functions that only existed in pthread versions, so weren't
 implemented for win32 threads as used by the Cygwin port.  I've added a patch
 that implements them and am starting again.
 
 As mentioned previously, I already fixed that in Ports:
 
 http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc
 
 PLEASE use this as the basis for your packages; there are a number of
 important fixes in that patchset.

  Well, I was just going to do a quick update to 4.7.1-1, still as a test:
version, in order to a) fix the dependencies and b) get exported TLS vars
working, and then integrate all your extra patches before doing the first full
curr: release.  Is that not a good idea?  b) in particular was important for
getting new versions of mpfr to work without having to disable thread support.

cheers,
  DaveK

Re: [ITA] mpfr (libmpfr-devel / libmpfr4)

[Dave Korn]

On 02/04/2013 16:27, Achim Gratz wrote:
 I've added test packages compiled with gcc-4.7.2-1 (to be installed by
 manually selecting them, like the test version of gcc itself):
 
 wget=wget -xnH --cut-dirs=1 http://cygwin.stromeko.net/release;

  Is there some access permission I would need to take a look at those?

 $ wget -xnH --cut-dirs=1 http://cygwin.stromeko.net/release
 --2013-04-05 18:16:13--  http://cygwin.stromeko.net/release
 Resolving cygwin.stromeko.net (cygwin.stromeko.net)... 212.90.148.102
 Connecting to cygwin.stromeko.net (cygwin.stromeko.net)|212.90.148.102|:80... 
 co
 nnected.
 HTTP request sent, awaiting response... 301 Moved Permanently
 Location: http://cygwin.stromeko.net/release/ [following]
 --2013-04-05 18:16:15--  http://cygwin.stromeko.net/release/
 Connecting to cygwin.stromeko.net (cygwin.stromeko.net)|212.90.148.102|:80... 
 co
 nnected.
 HTTP request sent, awaiting response... 403 Forbidden
 2013-04-05 18:16:16 ERROR 403: Forbidden.

cheers,
  DaveK

Re: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)

[Dave Korn]

On 05/04/2013 18:07, Dave Korn wrote:
 On 04/04/2013 10:13, Yaakov (Cygwin/X) wrote:
 On Sun, 31 Mar 2013 19:57:09 +0100, Dave Korn wrote:
   And the reroll failed to build because of the problem JonY ran into with
 java.  Turns out that libjava keys off the presence of pthread_getattr_np
 (added to the DLL a few versions ago) to decide whether to invoke a couple 
 of
 boehm-gc functions that only existed in pthread versions, so weren't
 implemented for win32 threads as used by the Cygwin port.  I've added a 
 patch
 that implements them and am starting again.
 As mentioned previously, I already fixed that in Ports:

 http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc

 PLEASE use this as the basis for your packages; there are a number of
 important fixes in that patchset.
 
   Well, I was just going to do a quick update to 4.7.1-1, still as a test:
 version, in order to a) fix the dependencies and b) get exported TLS vars
 working, and then integrate all your extra patches before doing the first full
 curr: release.  Is that not a good idea?  b) in particular was important for
 getting new versions of mpfr to work without having to disable thread support.

  Also, c) I have a fixed libffi package to go with it, which would resolve
the problems mentioned by Angelo G. in
http://cygwin.com/ml/cygwin/2013-04/threads.html#00081

  I really think it's worth uploading as a stop-gap.

cheers,
  DaveK