Re: Compiled executables requiring admin rights - different results between MinGW host type

[Corinna Vinschen]

On Mar 11 11:50, Tony Kelman wrote:
> Hi, I'm looking at a very simple 32-line c file, source is available
> here
> https://github.com/JuliaLang/julia/blob/master/contrib/stringpatch.c
> 
> I'm seeing unpredictable results w.r.t. the compiled executable
> requiring admin rights to run, depending which host compiler is
> used.
> 
> Under 32 bit Cygwin:
> gcc -o stringpatch-cyg stringpatch.c   # requires admin rights
> i686-pc-mingw32-gcc -o stringpatch-pc-32 stringpatch.c   # requires
> admin rights
> i686-w64-mingw32-gcc -o stringpatch-w64-32 stringpatch.c   #
> requires admin rights
> x86_64-w64-mingw32-gcc -o stringpatch-w64-64 stringpatch.c   # does
> not require admin rights
> 
> Under 64 bit Cygwin:
> gcc -o stringpatch-cyg stringpatch.c   # does not require admin rights
> i686-pc-mingw32-gcc -o stringpatch-pc-32 stringpatch.c   # requires
> admin rights
> i686-w64-mingw32-gcc -o stringpatch-w64-32 stringpatch.c   #
> requires admin rights
> x86_64-w64-mingw32-gcc -o stringpatch-w64-64 stringpatch.c   # does
> not require admin rights
> 
> What is the explanation for this discrepancy? Is this expected
> behavior?

You won't believe it, but yes!  Welcome to the wonderful world of
UAC installer detection!!!1!11

See http://msdn.microsoft.com/en-us/library/bb530410.aspx
and scroll down to the section called "Installer Detection".

I'll wait while you read...

[..."whistling while you work"...]

Finished?  Fine.  So, the only fault of your application is it's name.
It's called "something-with-patch-in-it".  As everybody knows, an
application which is called "something-with-patch-in-it" is an
installer and needs elevation.  But only if it's a 32 bit application.

> Is there an easy way to prevent any of the compiled
> executables from requiring admin rights?

You have four ways around this:

- Rename your executable so it doesn't have the chutzpah to call itself
  "something-with-patch-in-it" or "something-with-instal-in-it" or
  "something-with-setup-in-it" or "something-with-update-in-it".

- Take one of the manifest files you find in Cygwin's /usr/bin dir,
  and copy it alongside your binary, for instance:

$ cp /usr/bin/patch.exe.manifest ./stringpatch.exe.manifest

- Wait until the next binutils version is released (should be in the
  next couple of days), and link your executable with the new linker.
  This will give you a default manifest integrated in your executable
  by default, which doesn't only claim compatibility with all existing
  WIndows versions, but also sets the RequestedExecutionLevel to
  "asInvoker", which avoids the elevation for this executable entirely.

- Switch off UAC installer detection on your machine.  You can do this
  in the Local Security Policy MMC Snapin.


HTH,
COrinna

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


pgp5Gjf_rbQ82.pgp
Description: PGP signature

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

[Corinna Vinschen]

On Mar 11 17:05, Achim Gratz wrote:
> Corinna Vinschen  cygwin.com> writes:
> > > With the original passwd and group file in place and nsswitch.conf set to
> > > either "files" or "files db" the test fails.  With just "files" getfacl
> > > doesn't show the group ACL at all,
> > 
> > How does it look with any non-AD integrated Cygwin?
> 
> ... doesn't show the group ACL until I add them to the group file.  That
> part is consistent with the AD enabled snapshot.  Actually... if I create a
> group file with those two groups added, the access again doesn't get
> granted.  Which finally reveals that I also need to have the administrators
> group present in that file (which mkpasswd had been doing) -- then it works.
>  I can even leave out the two ACL groups again and it still works.
> 
> > Hmm.  So you're saying that the groups in question are not in
> > /etc/groups, but it works with the non-AD Cygwin but not with the
> > AD-Cygwin?
> 
> Exactly.  But as revealed above, what was really missing is the
> Administrators group.  Somehow, when "files" is in effect, that mapping
> doesn't seem to exist unless it is explicitly listed in the file.  It does
> get auto-created when I use _only_ the "db".  I hope that somehow makes 
> sense...
> 
> > > So, Perl somehow uses the gid/uid mapping and relies on those to be 
> > > working,
> 
> No, it seems to balk on not being able to map the Administrator group (which
> is my egid).

Eh, what?  You never mentioned that before!  So you changed your passwd
file to have group 544 as primary group?  That usually won't work well
if UAC is enabled.

That's the problem with bug reports which don't provide *details*.  If
you had provided full straces, your passwd and group files and your
nsswitch.conf settings, we may have been a lot further.  As it is now,
we're discussing your perl problem for days and days and *still* don't
really know what's going on in the code :(


Corinna

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


pgpJip2q8Xo4l.pgp
Description: PGP signature

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

[Corinna Vinschen]

On Mar 11 17:12, Achim Gratz wrote:
> Achim Gratz  NexGo.DE> writes:
> > Exactly.  But as revealed above, what was really missing is the
> > Administrators group.  Somehow, when "files" is in effect, that mapping
> > doesn't seem to exist unless it is explicitly listed in the file.  It does
> > get auto-created when I use _only_ the "db".  I hope that somehow makes
> sense...
> 
> I guess it does: the mapping that gets created from AD is sometimes 1049120
> instead of 544.  That depends on the settings in nsswitch.conf and whether
> an /etc/group file exists at all or contains an entry for Administrators.

Argh!  What about *details* which allow to reproduce this behaviour.

In my environment I *never* see the admins group being produced with
a GID of 1049120.  And it doesn't make any sense at all.  The UID/GID
values starting with 0x10 are reserved for accounts of the primary
domain.  The admins account is *never* an account of the primary domain
because its SID doesn't start with S-1-5-21-YOUR-DOMAIN-SID.  Rather
it's a builtin account with SID 1-5-32-544, which always gets converted
to UID/GID 544.

[...time passes...]

Hmm.  The only reason I can see which would allow to generate the GID
1049120 is, if your account has a primaryGroupID of 544 in AD, but that
*should* be impossible.  The AD user properties dialog doesn't allow to
set the primary group to a builtin group... unless you set this in the
attribute editor.  This is totally unexpected by Cygwin.  From AD it
just gets a RID value, and it simply adds this to the primary domain
offset 0x10.

Ok, so, here's the question.  Is your primaryGroupID in AD 544?  If not,
you will have to explain to me how this happens.  I have found no other
way to reproduce this.


Corinna

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


pgplNPEjZrPU_.pgp
Description: PGP signature

rebaseall advice sought to solve forking errors.

[Robin]

Hi all,
 
I was getting other fork errors trying to install a drupal theme's gems, but
thanks to someone on the cygwin IRC I was able to use "peflags -X409600
`which ruby`" and "rebaseall" to finally get "bundle install" to complete
without any reported errors. 

However, now I have another problem with fork errors and nothing I do with
rebaseall seems to resolve them.

I'm getting a stream of errors similar to:

0 [main] ruby 2360 child_info_fork::abort: address space needed by
'fcntl.so' (0x2F) is already occupied

>From reading around I understand that this is because rebaseall does not
pick up .so files?

Searching the internet I've found various people's solutions to similar
problems, including a few from this mailing board. I have tried a variety of
their suggestions based around 'rebaseall'. The closest I have come to
getting a positive result on my system is to run 

BaSe@BaSPCa /cygdrive/c
$ find users/base/.rvm/ -iname '*.so' > /tmp/ruby.gems.local.so.lst 

in cygwin. This gives a long pause, then just shows the command line again
(so I'm not certain the command has actually run). Then exiting that, going
to c:\cygwin\bin and running dash as administrator. Then running

/usr/bin/rebaseall -T /tmp/ruby.gems.local.so.lst

However, this shows: 

i_iso2022_kddi.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/trans/emoj
i_sjis_docomo.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/trans/emoj
i_sjis_kddi.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/trans/emoj
i_sjis_softbank.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/trans/esca
pe.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/trans/gb18
030.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/trans/gbk.
so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/trans/iso2
022.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/trans/japa
nese.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/trans/japa
nese_euc.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/trans/japa
nese_sjis.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/trans/kore
an.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/trans/sing
le_byte.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/trans/tran
sdb.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/trans/utf8
_mac.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/trans/utf_
16_32.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/utf_16be.s
o: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/utf_16le.s
o: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/utf_32be.s
o: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/utf_32le.s
o: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/enc/windows_12
51.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/etc.so:
skippe
d because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/fcntl.so:
skip
ped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/fiber.so:
skip
ped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/io/console.so:
 skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/io/nonblock.so
: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/io/wait.so:
sk
ipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/json/ext/gener
ator.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/json/ext/parse
r.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/mathn/complex.
so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/mathn/rational
.so: skipped because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/nkf.so:
skippe
d because nonexistent.
users/base/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/i386-cygwin/objspace.so

Re: Need general snapshot testers/console buffer jumble

[Corinna Vinschen]

Hi Marco,

On Mar 11 21:55, Marco Atzeri wrote:
> On 10/03/2014 11:11, Corinna Vinschen wrote:
> >built from CVS.  No crash either.
> >
> >
> >Corinna
> 
> Hi Corinna,
> 
> I think it is due to the unusual history of my cygwin installation,
> that is triggering a corner case.
> 
> The system is installed on a USB disk and it migrated from
> one computer to another, so some of old ACLs are not recognized from
> one new system.
> 
> On AD aware snapshots:
> $ uname -svr
> CYGWIN_NT-6.1-WOW64 1.7.29s(0.272/5/3) 20140310 03:20:19
> 
> 
> $ ls -l nco-4.*.gz
> ls: cannot access nco-4.3.9.tar.gz: Bad address
> -rw-r--r-- 1 marco  root 5846624 Jan 29  2013 nco-4.2.5.tar.gz
> -rw-r--r-- 1 Administrators None 4479960 Jan 30 00:07 nco-4.4.1.tar.gz
> [...]
> I am using the same /etc/passwd and /etc/group
> and there is no /etc/nsswitch.conf file.
> 
> 
> Using a old version of
> SetACL by Helge Klein
> Homepage:http://setacl.sourceforge.net
> Version: 2.0.3.0
> 
> I catched the ACL for two of the files:
> 
> "\\?\E:\cygwin\pub\devel\nco\nco-4.3.9.tar.gz",1,"O:S-1-5-21-531030479-1339336681-3415091201-1009G:S-1-5-21-1870173206-1308263284-2375963468-513D:P(A;;0x1f019f;;;S-1-5-21-531030479-1339336681-3415091201-1009)(A;;FR;;;S-1-5-21-1870173206-1308263284-2375963468-513)(A;;FR;;;WD)"
> 
> SetACL finished successfully.
> "\\?\E:\cygwin\pub\devel\nco\nco-4.2.5.tar.gz",1,"O:S-1-5-21-531030479-1339336681-3415091201-1009G:BAD:P(A;;0x1f019f;;;S-1-5-21-531030479-1339336681-3415091201-1009)(A;;FR;;;BA)(A;;FR;;;WD)"
> 
> and looking on
> 
> new system /etc/group:
> None:S-1-5-21-531030479-1339336681-3415091201-513:513:
> 
> old system /etc/group:
> None:S-1-5-21-1870173206-1308263284-2375963468-513:513:
> 
> the "bad address" error is coming from the the file with the
> old ACL for "None" group.
> 
> I suspect the Xwin crash was due to some files under /tmp or /var that
> had similar files, as making extensive use of
>chgrp.exe -R Administrators *
> 
> I have not anymore the segfault.

thanks for tracking this down.  Still, it shouldn't result in a 
"Bad address" error, only in a GID value -1.  Pity that you fixed
it, otherwise your machine would be a wonderful guinea pig  :}


Thanks,
Corinna

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


pgp2jk3ee185j.pgp
Description: PGP signature

Re: Cygwin64 ignoring /etc/passwd shell field?

[Corinna Vinschen]

On Mar 11 16:58, Chris J. Breisch wrote:
> Corinna Vinschen wrote:
> >On Mar  6 14:40, Ken Brown wrote:
> >>On 3/3/2014 10:05 AM, Corinna Vinschen wrote:
> >>>On Mar  3 08:55, Charles Wilson wrote:
> On 2/26/2014 5:07 AM, Corinna Vinschen wrote:
> >Weird, I was pretty sure we already have an /etc/shells file installed
> >by default.  Apparently not.  So, shan't we add one?
> >
> >   /bin/sh
> >   /bin/bash
> >   /bin/dash
> >   /bin/mksh
> >   /bin/zsh
> >   /usr/bin/sh
> >   /usr/bin/bash
> >   /usr/bin/dash
> >   /usr/bin/mksh
> >   /usr/bin/zsh
> >
> >The base-files package would be a good place to be.  David?
> Currently inetutils-server provides /etc/defaults/etc/shells. If
> that file is required by base functionality now, then I've no
> problem removing it and modifying inetutils' postinstall/preremove
> scripts. But we'll need to synchronize the uploads of
> inetutils-server-$next and base-files-$next.
> 
> Speaking of base-files, version 4.1-2 has been in test now for over
> two years...works fine here and fixes a problem with $TEMP and other
> "standard" variable names: 4.1-1 set both $TEMP and $temp, but these
> are not distinguished by native processes, leading to confusion if a
> native process reset $TEMP (but not $temp).
> >>>I had a problem when running it in an early stage of 64 bit development,
> >>>but I don't remember at all what the problem was.  Do you run it on
> >>>64 bit as well?
> >>I think this is what you're trying to remember:
> >>
> >>   http://cygwin.com/ml/cygwin/2013-07/msg00114.html
> >
> >Thanks for finding this one!  Unfortunately David has left us,
> >apparently.
> >
> >Is anybody willing to take over maintainership of the base-files
> >package?
> >
> >
> >Thanks,
> >Corinna
> >
> 
> It seems no one is interested.
> 
> I don't know anything about package maintenance for Cygwin, but this
> particular package doesn't look that hard. I'd be willing to give it
> a shot.

Thanks!  Yes, it's really not overly hard to maintain, you just have to
be prepared for some nagging since that package is in the forefront of
user experience when starting Cygwin the first time.

> Is the information on this page (http://cygwin.com/setup.html) up-to-date?

More or less.  The upload now works differently and is described on
https://sourceware.org/cygwin-apps/package-upload.html


Corinna

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


pgpBmsBMLJTJE.pgp
Description: PGP signature

Re: Need general snapshot testers/console buffer jumble

[Marco Atzeri]

On 12/03/2014 10:23, Corinna Vinschen wrote:



thanks for tracking this down.  Still, it shouldn't result in a
"Bad address" error, only in a GID value -1.  Pity that you fixed
it, otherwise your machine would be a wonderful guinea pig  :}


Thanks,
Corinna




That "Bad address" file is still available ;-)
And the USB disk is full of similar files

I just noticed that the 64bit is also available

$ cd /cygdrive/e/cygwin64/var/log
$ ls -l
ls: cannot access xwin: Bad address
total 864
-rw-r--r-- 1 marco root  0 May 18  2013 cygserver.log
-rw-r--r-- 1 marco root  0 May 18  2013 cygserver64.log
-rw-r--r-- 1 marco root 722781 Mar  9 12:15 setup.log
-rw-r--r-- 1 marco root 159288 Mar  9 12:15 setup.log.full
d? ? ? ? ?? xwin

what test do you need ?

Regards
Marco

--
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: Cygwin64 ignoring /etc/passwd shell field?

[Corinna Vinschen]

On Mar 11 22:19, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Thanks for finding this one!  Unfortunately David has left us,
> > apparently.
> 
> Isn't it that a bit too short a time to come to this conclusion?
> 
> > Is anybody willing to take over maintainership of the base-files
> > package?
> 
> Seeing that I have additional patches that David didn't apply to the
> test version, I could do that.  But let's confirm first that he's not
> just having a vacation.

Gosh, so we have two volunteers now :)

Chris, Achim, please figure out who's going to maintain the package.
If you like, you can even do this together.

As for David, I CCed him 3 times since Feb-26 and I'm CCing him again
with this mail.  We can wait another week or two, but you should
contemplate to prepare yourself for taking over, I guess.


Thanks,
Corinna

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


pgpUDb6Af4PWn.pgp
Description: PGP signature

Re: rebaseall advice sought to solve forking errors.

[Corinna Vinschen]

On Mar 12 02:21, Robin wrote:
> Hi all,
>  
> I was getting other fork errors trying to install a drupal theme's gems, but
> thanks to someone on the cygwin IRC I was able to use "peflags -X409600
> `which ruby`" and "rebaseall" to finally get "bundle install" to complete
> without any reported errors. 
> 
> However, now I have another problem with fork errors and nothing I do with
> rebaseall seems to resolve them.
> 
> I'm getting a stream of errors similar to:
> 
> 0 [main] ruby 2360 child_info_fork::abort: address space needed by
> 'fcntl.so' (0x2F) is already occupied
> 
> >From reading around I understand that this is because rebaseall does not
> pick up .so files?

No, that's not it.  The rebaseall script is designed to handle the DLLs
of the distro.  It picks up .dll, .so, and .oct files, but it does *not*
pick up any files which weren't installed by Cygwin's setup tool.

> Searching the internet I've found various people's solutions to similar
> problems, including a few from this mailing board. I have tried a variety of
> their suggestions based around 'rebaseall'. The closest I have come to
> getting a positive result on my system is to run 
> 
> BaSe@BaSPCa /cygdrive/c
> $ find users/base/.rvm/ -iname '*.so' > /tmp/ruby.gems.local.so.lst 
^

Use an absolute path here, not a relative path.


Corinna

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


pgp7Rp8enJGE5.pgp
Description: PGP signature

Re: Need general snapshot testers/console buffer jumble

[Corinna Vinschen]

On Mar 12 10:35, Marco Atzeri wrote:
> On 12/03/2014 10:23, Corinna Vinschen wrote:
> 
> >
> >thanks for tracking this down.  Still, it shouldn't result in a
> >"Bad address" error, only in a GID value -1.  Pity that you fixed
> >it, otherwise your machine would be a wonderful guinea pig  :}
> >
> >
> >Thanks,
> >Corinna
> >
> 
> 
> That "Bad address" file is still available ;-)

Cool.

> And the USB disk is full of similar files
> 
> I just noticed that the 64bit is also available
> 
> $ cd /cygdrive/e/cygwin64/var/log
> $ ls -l
> ls: cannot access xwin: Bad address
> total 864
> -rw-r--r-- 1 marco root  0 May 18  2013 cygserver.log
> -rw-r--r-- 1 marco root  0 May 18  2013 cygserver64.log
> -rw-r--r-- 1 marco root 722781 Mar  9 12:15 setup.log
> -rw-r--r-- 1 marco root 159288 Mar  9 12:15 setup.log.full
> d? ? ? ? ?? xwin
> 
> what test do you need ?

For a start, can you please strace an ls -l on such a file?


Thanks,
Corinna

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


pgp2p8mIrZgzg.pgp
Description: PGP signature

Re: Need general snapshot testers/console buffer jumble

[Marco Atzeri]

On 12/03/2014 10:43, Corinna Vinschen wrote:

On Mar 12 10:35, Marco Atzeri wrote:

On 12/03/2014 10:23, Corinna Vinschen wrote:




And the USB disk is full of similar files

I just noticed that the 64bit is also available

$ cd /cygdrive/e/cygwin64/var/log
$ ls -l
ls: cannot access xwin: Bad address
total 864
-rw-r--r-- 1 marco root  0 May 18  2013 cygserver.log
-rw-r--r-- 1 marco root  0 May 18  2013 cygserver64.log
-rw-r--r-- 1 marco root 722781 Mar  9 12:15 setup.log
-rw-r--r-- 1 marco root 159288 Mar  9 12:15 setup.log.full
d? ? ? ? ?? xwin

what test do you need ?


For a start, can you please strace an ls -l on such a file?


http://matzeri.altervista.org/works/cygwin/




Thanks,
Corinna



Regards
Marco

--
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: Please stop sending email to ...

[Andrey Repin]

Greetings, Christopher Faylor!

>>> I know that this is a pointless exercise but I'll say it anyway: people
>>> who think that they can have a private chat with Corinna or Larry by
>>> sending email to what seem to be their private email addresses will just
>>> show up in the spam trap, possibly even causing spamassassin to think
>>> that they are a spammer.
>>> 
>>> We mention in multiple places that cygwin-related issues should go to
>>> this list.  So, please don't bother trying to send private email unless
>>> you've been specifically asked to do so.  You'll also be doing me a
>>> favor because I won't have to spend time cleaning out the spam traps.
>>
>>Well, here goes nothing. 
>>
>>I am happy to admit that I'm one of those persons.  The problem is
>>exactly that what you claim we "should do" versus what is actually
>>possible to do.  If any of the list maintainers had actually bothered
>>to try to register to these email lists, you would probably have found
>>out that your spam filters are set so high, that it is impossible for
>>normal people to even register to these lists!

> FYI, The Cygwin list has 1212 subscribers with 89 new joiners since
> January 1.  I'm the "list maintainer" and I'm obviously registered.
> The same software that handles Cygwin also handles gcc.gnu.org and
> sourceware.org.  There are many other mailing lists under those
> domains, and some of them have even more subscribers.

The point was, it's nowhere mentioned, who to contact in case of list issues.
Not in list mail headers, neither on list's mailman web page.
I've had multiple mails blocked for containing  "foreign language" (how can I
help? It's Microsoft smarts to translate group names to make everyone
unhappy), and I multiple times tried to find the address to appeal to. To no
avail.
Yes, I vaguely recalled, that there supposed to be "-owner" address,
but it's only my poor memory. How can I trust her without confirmation?


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 12.03.2014, <15:38>

Sorry for my terrible english...


--
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: Please stop sending email to ...

[Corinna Vinschen]

On Mar 12 15:43, Andrey Repin wrote:
> Greetings, Christopher Faylor!
> 
> >>> I know that this is a pointless exercise but I'll say it anyway: people
> >>> who think that they can have a private chat with Corinna or Larry by
> >>> sending email to what seem to be their private email addresses will just
> >>> show up in the spam trap, possibly even causing spamassassin to think
> >>> that they are a spammer.
> >>> 
> >>> We mention in multiple places that cygwin-related issues should go to
> >>> this list.  So, please don't bother trying to send private email unless
> >>> you've been specifically asked to do so.  You'll also be doing me a
> >>> favor because I won't have to spend time cleaning out the spam traps.
> >>
> >>Well, here goes nothing. 
> >>
> >>I am happy to admit that I'm one of those persons.  The problem is
> >>exactly that what you claim we "should do" versus what is actually
> >>possible to do.  If any of the list maintainers had actually bothered
> >>to try to register to these email lists, you would probably have found
> >>out that your spam filters are set so high, that it is impossible for
> >>normal people to even register to these lists!
> 
> > FYI, The Cygwin list has 1212 subscribers with 89 new joiners since
> > January 1.  I'm the "list maintainer" and I'm obviously registered.
> > The same software that handles Cygwin also handles gcc.gnu.org and
> > sourceware.org.  There are many other mailing lists under those
> > domains, and some of them have even more subscribers.
> 
> The point was, it's nowhere mentioned, who to contact in case of list issues.
> Not in list mail headers, neither on list's mailman web page.
> I've had multiple mails blocked for containing  "foreign language" (how can I
> help? It's Microsoft smarts to translate group names to make everyone
> unhappy), and I multiple times tried to find the address to appeal to. To no
> avail.
> Yes, I vaguely recalled, that there supposed to be "-owner" address,
> but it's only my poor memory. How can I trust her without confirmation?

On the other hand, the "postmaster" account exists everywhere...


Corinna

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


pgpatDMVxJovO.pgp
Description: PGP signature

Re: Please stop sending email to ...

[Adam Dinwoodie]

On Wed, Mar 12, 2014 at 03:43:11PM +0400, Andrey Repin wrote:
> The point was, it's nowhere mentioned, who to contact in case of list issues.
> Not in list mail headers, neither on list's mailman web page.
> I've had multiple mails blocked for containing  "foreign language" (how can I
> help? It's Microsoft smarts to translate group names to make everyone
> unhappy), and I multiple times tried to find the address to appeal to. To no
> avail.
> Yes, I vaguely recalled, that there supposed to be "-owner" address,
> but it's only my poor memory. How can I trust her without confirmation?

It is mentioned in the email headers.  Looking at this email, for
example, I see the following header:

List-Help: , 

Alternatively, as cgf has already mentioned,
 states "If you have *any* questions or
problems with the mailing lists, see the Sourceware mailing list FAQs"
with a link to that same Sourceware page.  And that page includes the
following:

> 10.  I can't post because your spam software won't let me, and I want
> to tell you how unhappy I am
>
> ...
>
> If you have tried all the above techniques and are still unable to
> send email to a mailing list, then send email to postmaster at this
> site.  Be prepared to be mocked, if any of the above needs to be
> repeated to you, however.

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

Problems with run.exe (silent crashes) - stopped working suddenly

[Gulliver Smith]

My system is Windows 7 professional 64 bit. The Cygwin is 32 bit,
updated monthly

I have a backup script that used to run successfully from a Windows
shortcut or scheduled task as

C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c
"/home/gulliver/bin/backup >> /cygdrive/c/temp/backup.log 2>&1"

However, around August 2013 this stopped working (it took me a while to notice)

If I try in a windows command prompt it also crashed,

I get a small run.exe.stackdump file:

Stack trace:
Frame Function  Args
00284B28  610303D2 (0114, EA60, 00A4, 00284B78)
00284C38  610DA4DD (, 0065, 00284C78, 0028CE64)

The problem is not with the bash command or script - it runs fine from
both the command prompt or a shortcut if I change the command to

C:\cygwin\bin\bash.exe -l -c "/home/gulliver/bin/backup >>
/cygdrive/c/temp/backup.log 2>&1"

but then there is an empty Windows window open for the whole time.

A related issue is an xterm shortcut that used to work:

C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c "xterm.exe -title T
-bg '#EEFFFE' -e ssh -Y @&"

This used to work as intended. Now it opens an xterm on the local host
only - the ssh command fails. Again, removing the "run" and executing
"bash" directly works but opens a second window.

Does anyone know what might be happening or how to debug this problem?

Thanks
Gulliver

--
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: Testers needed: New passwd/group handling in Cygwin

[Achim Gratz]

Corinna Vinschen  cygwin.com> writes:
> Ok, so, here's the question.  Is your primaryGroupID in AD 544?  If not,
> you will have to explain to me how this happens.  I have found no other
> way to reproduce this.

My primary group ID in AD is 513 (Domain Users), just as shown by id, I am
not member of the Administrators group and I only have effective group
membership when running from an elevated prompt (which I'm allowed to get to
via another group membership and a group policy that's totally unrelated to
the well-known Administrators group).  I have no idea what happens either,
none of the traces even contain a check for Administrators group or a
recognizable ID.   All I know is that when the mapping for Administrators
group is not 544, then the test fails.  Anyway, I've run out of time for the
moment, I'll try to set up a clean test environment later.  This whole
business of various settings in nsswitch.conf and entries in passwd/group is
creating a combinatorial explosion that I'm not sure how to manage yet. 
Then, I'll have to sanitize the traces, which will require a script if it's
more than two or three.


Regards,
Achim.



--
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: Please stop sending email to ...

[Christopher Faylor]

On Wed, Mar 12, 2014 at 12:17:51PM +, Adam Dinwoodie wrote:
>On Wed, Mar 12, 2014 at 03:43:11PM +0400, Andrey Repin wrote:
>> The point was, it's nowhere mentioned, who to contact in case of list issues.
>> Not in list mail headers, neither on list's mailman web page.
>> I've had multiple mails blocked for containing  "foreign language" (how can I
>> help? It's Microsoft smarts to translate group names to make everyone
>> unhappy), and I multiple times tried to find the address to appeal to. To no
>> avail.
>> Yes, I vaguely recalled, that there supposed to be "-owner" address,
>> but it's only my poor memory. How can I trust her without confirmation?
>
>It is mentioned in the email headers.  Looking at this email, for
>example, I see the following header:
>
>List-Help: , 
> 
>
>Alternatively, as cgf has already mentioned,
> states "If you have *any* questions or
>problems with the mailing lists, see the Sourceware mailing list FAQs"
>with a link to that same Sourceware page.  And that page includes the
>following:

Thank you!  Can I get a gold star here for someone with good reading
skills?

cgf

--
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: sqlite3-3.8.4.1-1 for Cygwin/Cygwin64

[Jan Nijtmans]

SQLite is a software library that implements a self-contained,
serverless, zero-configuration, transactional SQL database engine

Changes since 3.8.3.1-1
=
* Updated to upstream 3.8.4.1 release. See:
 
* Two new Cygwin packages: "sqlite3-icu" and "sqlite3-zlib".
  They can be loaded dynamically by any application which
  wants to use those SQLite extensions. In sqlite3.exe this
  can be done with ".load icu" resp. ".load zlib". See:


* Additional SQLite bug-fixes, rejected (apparently) upstream:
  * VFS filename truncation issues

  * Wrong filename handling in sqlite3_load_extension() for Cygwin

  * pragma database_list returns win32 paths on Cygwin


--
Jan Nijtmans

--
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: Compiled executables requiring admin rights - different results between MinGW host type

[Tony Kelman]

You won't believe it, but yes!  Welcome to the wonderful world of
UAC installer detection!!!1!11


I get the impression you've been frustrated by this one before...


See http://msdn.microsoft.com/en-us/library/bb530410.aspx
and scroll down to the section called "Installer Detection".

I'll wait while you read...

[..."whistling while you work"...]

Finished?  Fine.  So, the only fault of your application is it's name.
It's called "something-with-patch-in-it".  As everybody knows, an
application which is called "something-with-patch-in-it" is an
installer and needs elevation.  But only if it's a 32 bit application.


Wow. Thank you tremendously for this explanation Corinna. How bizarre.


- Take one of the manifest files you find in Cygwin's /usr/bin dir,
  and copy it alongside your binary, for instance:

$ cp /usr/bin/patch.exe.manifest ./stringpatch.exe.manifest


That did the trick. In 64 bit Cygwin the only .manifest file I found in
/usr/bin was install-info.exe.manifest (apparently from texinfo package),
but that worked. Makes sense that 64 bit Cygwin wouldn't need as
many of these, but my primary use case where I'm running into this
issue is cross-compiling from 64 bit Cygwin to i686-w64-mingw32.


- Wait until the next binutils version is released (should be in the
  next couple of days), and link your executable with the new linker.
  This will give you a default manifest integrated in your executable
  by default, which doesn't only claim compatibility with all existing
  WIndows versions, but also sets the RequestedExecutionLevel to
  "asInvoker", which avoids the elevation for this executable entirely.


Don't the various MinGW cross compilers have their own binutils? I look
forward to this being the most convenient long-term solution, (renaming
could also work, but that pull request is going to result in some confused
looks and/or raised eyebrows) but will this need to come from upstream
(MinGW.org for i686-pc, or MinGW-w64 for i686-w64) to change the default
no-manifest-file behavior for any of the hosts besides 32 bit Cygwin?

-Tony


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

fltk check or enum quest

[Marco Atzeri]

I am hitting a gcc/fltk craziness, and I have no clue what to look for.

The attached example is extracted from octave configure log,
and I am almost sure that nor the test nor the fltk header
are changed at all recently.

Could someone with libfltk-devel installed try

$ . ./conftest.sh

my current result is:
--
In file included from /usr/include/FL/gl.h:45:0,
 from conftest.c:2:
/usr/include/FL/Enumerations.H:525:1: error: unknown type name ‘Fl_Boxtype’
 extern FL_EXPORT Fl_Boxtype fl_define_FL_ROUND_UP_BOX();
 ^
/usr/include/FL/Enumerations.H:528:1: error: unknown type name ‘Fl_Boxtype’
 extern FL_EXPORT Fl_Boxtype fl_define_FL_SHADOW_BOX();
---

but Fl_Boxtype is defined as enum type on the same file

   /usr/include/FL/Enumerations.H

at line 473.

What I am missing ?

Thanks in advance
Marco


#include 

#  ifdef __cplusplus
 extern "C"
#  endif

int
main ()
{

int nothing = 0;

  ;
  return 0;
}

gcc -c -ggdb -O2 -Wimplicit-function-declaration  -ggdb -O2 -pipe 
-Wimplicit-function-declaration  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE 
-D_THREAD_SAFE -D_REENTRANT  conftest.c -o conftest.o

--
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: Need general snapshot testers/console buffer jumble

[Corinna Vinschen]

On Mar 12 11:09, Marco Atzeri wrote:
> On 12/03/2014 10:43, Corinna Vinschen wrote:
> >On Mar 12 10:35, Marco Atzeri wrote:
> >>On 12/03/2014 10:23, Corinna Vinschen wrote:
> >>
> 
> >>And the USB disk is full of similar files
> >>
> >>I just noticed that the 64bit is also available
> >>
> >>$ cd /cygdrive/e/cygwin64/var/log
> >>$ ls -l
> >>ls: cannot access xwin: Bad address
> >>total 864
> >>-rw-r--r-- 1 marco root  0 May 18  2013 cygserver.log
> >>-rw-r--r-- 1 marco root  0 May 18  2013 cygserver64.log
> >>-rw-r--r-- 1 marco root 722781 Mar  9 12:15 setup.log
> >>-rw-r--r-- 1 marco root 159288 Mar  9 12:15 setup.log.full
> >>d? ? ? ? ?? xwin
> >>
> >>what test do you need ?
> >
> >For a start, can you please strace an ls -l on such a file?
> 
> http://matzeri.altervista.org/works/cygwin/

As per our private email exchange, this is fixed in CVS.


FTR,
Corinna

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


pgpBRChWmWA1_.pgp
Description: PGP signature

Re: Compiled executables requiring admin rights - different results between MinGW host type

[Corinna Vinschen]

On Mar 12 11:00, Tony Kelman wrote:
> >You won't believe it, but yes!  Welcome to the wonderful world of
> >UAC installer detection!!!1!11
> 
> I get the impression you've been frustrated by this one before...

Hmm, I'm too easy to read, apparently...

> >See http://msdn.microsoft.com/en-us/library/bb530410.aspx
> >and scroll down to the section called "Installer Detection".
> >
> >I'll wait while you read...
> >
> >[..."whistling while you work"...]
> >
> >Finished?  Fine.  So, the only fault of your application is it's name.
> >It's called "something-with-patch-in-it".  As everybody knows, an
> >application which is called "something-with-patch-in-it" is an
> >installer and needs elevation.  But only if it's a 32 bit application.
> 
> Wow. Thank you tremendously for this explanation Corinna. How bizarre.
> 
> >- Take one of the manifest files you find in Cygwin's /usr/bin dir,
> >  and copy it alongside your binary, for instance:
> >
> >$ cp /usr/bin/patch.exe.manifest ./stringpatch.exe.manifest
> 
> That did the trick. In 64 bit Cygwin the only .manifest file I found in
> /usr/bin was install-info.exe.manifest (apparently from texinfo package),
> but that worked. Makes sense that 64 bit Cygwin wouldn't need as
> many of these, but my primary use case where I'm running into this
> issue is cross-compiling from 64 bit Cygwin to i686-w64-mingw32.
> 
> >- Wait until the next binutils version is released (should be in the
> >  next couple of days), and link your executable with the new linker.
> >  This will give you a default manifest integrated in your executable
> >  by default, which doesn't only claim compatibility with all existing
> >  WIndows versions, but also sets the RequestedExecutionLevel to
> >  "asInvoker", which avoids the elevation for this executable entirely.
> 
> Don't the various MinGW cross compilers have their own binutils? I look
> forward to this being the most convenient long-term solution, (renaming
> could also work, but that pull request is going to result in some confused
> looks and/or raised eyebrows) but will this need to come from upstream
> (MinGW.org for i686-pc, or MinGW-w64 for i686-w64) to change the default
> no-manifest-file behavior for any of the hosts besides 32 bit Cygwin?

Our maintainers of the mingw-binutls and native binutils package just
have to update the packages to the latest from binutils git.  Actually,
that reminds me...

JonY, ping?  A couple of days ago, Nick Clifton updated binutils for
Windows so that every executable, which doesn't provide its own
manifest, will get a default manifest.  This default manifest has two
purposes:

- It sets the RequestedExecutionLevel to "asInvoker", which is the usual
  default behaviour, and

- it makes sure to make the executable compatible with all released
  versions of Windows, which is *especially* important since Windows
  8.1.  The reason is this:

  The compatibility manifest was optional up to Windows 8.  An
  executable without manifest was treated as compatible with the current
  OS version.

  Starting with Windows 8.1, the manifest is not optional anymore.  An
  executable without manifest is treated as being incompatible with all,
  but the oldest still supported OS compatibility layer.

  On Windows 8.1 this means, *all* executables without compatibility
  manifest run in Windws Vista compatibility mode.  Which is bad,
  because the compatibility setting for Vista even reproduce old bugs!

So, if you have a bit of time, it would be nice to get new
mingw64-i686-binutils and mingw64-x86_64-binutils packages (as well
as a new Cygwin binutils, but cgf already knows about this).

Every time a new Windows version is released, we will have to update the
default manifest in binutils, too, but that's the price we have to pay
for compatibility.  Sigh.


Corinna

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


pgpr7lBlWm6Wb.pgp
Description: PGP signature

Re: C++11 program link failure under GCC 4.8.2-1

[zosrothko]

Hi

Below are the compile time __STRICT_ANSI__ defines for various standards
supported by g++

FrancisANDRE@idefix /usr/include
$ gcc -xc++ -std=c++0x -dM -E - < /dev/null | grep ANSI
#define __STRICT_ANSI__ 1

FrancisANDRE@idefix /usr/include
$ gcc -xc++ -std=c++11 -dM -E - < /dev/null | grep ANSI
#define __STRICT_ANSI__ 1

FrancisANDRE@idefix /usr/include
$ gcc -xc++ -std=gnu++11 -dM -E - < /dev/null | grep ANSI

FrancisANDRE@idefix /usr/include
$ gcc -xc++ -std=c++98 -dM -E - < /dev/null | grep ANSI
#define __STRICT_ANSI__ 1

All but c++11 define __STRICT_ANSI__. That's why your sample does not
compile. This a issue with the cygwin includes that should provide snprintf
for c++11 also not only for other standards.



--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/C-11-program-link-failure-under-GCC-4-8-2-1-tp104247p107069.html
Sent from the Cygwin list mailing list archive at Nabble.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: Problems with run.exe (silent crashes) - stopped working suddenly

[Andrey Repin]

Greetings, Gulliver Smith!

> My system is Windows 7 professional 64 bit. The Cygwin is 32 bit,
> updated monthly

> I have a backup script that used to run successfully from a Windows
> shortcut or scheduled task as

> C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c
> "/home/gulliver/bin/backup >> /cygdrive/c/temp/backup.log 2>&1"

> However, around August 2013 this stopped working (it took me a while to 
> notice)

run is known to crash at random occasions, since... around that time.
I don't know if it has been fixed, sorry.
That aside, I see no reason to use run in your case.

> If I try in a windows command prompt it also crashed,

> I get a small run.exe.stackdump file:

> Stack trace:
> Frame Function  Args
> 00284B28  610303D2 (0114, EA60, 00A4, 00284B78)
> 00284C38  610DA4DD (, 0065, 00284C78, 0028CE64)

> The problem is not with the bash command or script - it runs fine from
> both the command prompt or a shortcut if I change the command to

> C:\cygwin\bin\bash.exe -l -c "/home/gulliver/bin/backup >>
> /cygdrive/c/temp/backup.log 2>&1"

> but then there is an empty Windows window open for the whole time.

Use cron, then there won't be any stray windows.

> A related issue is an xterm shortcut that used to work:

> C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c "xterm.exe -title T
> -bg '#EEFFFE' -e ssh -Y @&"

Now, THIS is a VERY wrong way to do it.
You're
1. Starting run
2. Telling it to start bash
3. Telling bash to start xterm
4. In which you're starting an SSH session.

Why not start xterm directly? Also, ever heard of PuTTY? Or mintty?

> This used to work as intended. Now it opens an xterm on the local host
> only - the ssh command fails. Again, removing the "run" and executing
> "bash" directly works but opens a second window.

> Does anyone know what might be happening or how to debug this problem?

Most simple solution would be to use right tools for the job, I'd say.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 13.03.2014, <00:14>

Sorry for my terrible english...


--
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: fltk check or enum quest

[David Stacey]

On 12/03/2014 18:06, Marco Atzeri wrote:

I am hitting a gcc/fltk craziness, and I have no clue what to look for.

The attached example is extracted from octave configure log,
and I am almost sure that nor the test nor the fltk header
are changed at all recently.



The problem is that the enumerations in FL/Enumerations.H are using the 
C++ style syntax, and the conftest source code has the '.c' extension, 
so gcc treats it as C.


The C++ syntax for an enumeration is as follows:

enum EColours { eRed, eGreen, eBlue };

The C syntax for an enumeration is as follows:

typedef enum { eRed, eGreen, eBlue } EColours;

You have two options. Either patch FL/Enumerations.H to use the C syntax 
(there are also a number of C++ style comments that you may have to 
change). Or, change the test to write out a file with a '.cpp' 
extension, invoke g++ and drop the -Wimplicit-function-declaration (as 
this is not valid for C++).


Hope this helps,

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: Please stop sending email to ...

[Andrey Repin]

Greetings, Corinna Vinschen!

>> >>> I know that this is a pointless exercise but I'll say it anyway: people
>> >>> who think that they can have a private chat with Corinna or Larry by
>> >>> sending email to what seem to be their private email addresses will just
>> >>> show up in the spam trap, possibly even causing spamassassin to think
>> >>> that they are a spammer.
>> >>> 
>> >>> We mention in multiple places that cygwin-related issues should go to
>> >>> this list.  So, please don't bother trying to send private email unless
>> >>> you've been specifically asked to do so.  You'll also be doing me a
>> >>> favor because I won't have to spend time cleaning out the spam traps.
>> >>
>> >>Well, here goes nothing. 
>> >>
>> >>I am happy to admit that I'm one of those persons.  The problem is
>> >>exactly that what you claim we "should do" versus what is actually
>> >>possible to do.  If any of the list maintainers had actually bothered
>> >>to try to register to these email lists, you would probably have found
>> >>out that your spam filters are set so high, that it is impossible for
>> >>normal people to even register to these lists!
>> 
>> > FYI, The Cygwin list has 1212 subscribers with 89 new joiners since
>> > January 1.  I'm the "list maintainer" and I'm obviously registered.
>> > The same software that handles Cygwin also handles gcc.gnu.org and
>> > sourceware.org.  There are many other mailing lists under those
>> > domains, and some of them have even more subscribers.
>> 
>> The point was, it's nowhere mentioned, who to contact in case of list issues.
>> Not in list mail headers, neither on list's mailman web page.
>> I've had multiple mails blocked for containing  "foreign language" (how can I
>> help? It's Microsoft smarts to translate group names to make everyone
>> unhappy), and I multiple times tried to find the address to appeal to. To no
>> avail.
>> Yes, I vaguely recalled, that there supposed to be "-owner" address,
>> but it's only my poor memory. How can I trust her without confirmation?

> On the other hand, the "postmaster" account exists everywhere...

Not to argue, but postmaster is often not the right person to contact mailing
list owner.
Now, given proper explanation, I realize this is not the case for cygwin
mailing list, and I've already pinned Christopher's message for future
reference.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 12.03.2014, <23:32>

Sorry for my terrible english...


--
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 in /dev/dsp = problems at short wav-files (<2sec)

[Dr. Alexander Kleinsorge]

/dev/dsp has problems playing short wav-files!
# Cygwin 1.7.28 (32bit), Windows 7 (64 bit).

# get 2 test files here ( 25 kB both )
wget http://www.physik.tu-berlin.de/~aleks/wave14sL.wav
wget http://www.physik.tu-berlin.de/~aleks/wave16sL.wav

# Test that fails:
cp wave16sL.wav /dev/dsp ==> I hear something (file = 1.6 sec, 12 kB).
cp wave14sL.wav /dev/dsp ==> I hear nothing ! (file = 1.4 sec, 13 kB).
# Format: both 8000 Hz, mono, 8 bit. (but first file is played truncated!)
aplay same.wav # in Ubuntu 12.04 works fine.
# also any other player (Win32 or Ubuntu is able to play both files fine).

$ file wave14sL.wav wave16sL.wav
wave14sL.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit,
mono 8000 Hz
wave16sL.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit,
mono 8000 Hz

$ cat /proc/version
CYGWIN_NT-6.1-WOW64 version 1.7.28(0.271/5/3)
(cori...@calimero.vinschen.de) (gcc version 4.8.2 20131016 (Fedora Cygwin
4.8.2-2) (GCC) ) 2014-02-09 21:06

Thanks for reply,
Alexander


--
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 /dev/dsp = problems at short wav-files (<2sec)

[Corinna Vinschen]

On Mar 12 22:24, Dr. Alexander Kleinsorge wrote:
> /dev/dsp has problems playing short wav-files!

And you started a new thread to report this a second time, because...?

Here was my reply to your original thread:

  http://cygwin.com/ml/cygwin/2014-03/msg00217.html


Corinna

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


pgpqbYlguQh98.pgp
Description: PGP signature

Re: Compiled executables requiring admin rights - different results between MinGW host type

[JonY]

On 3/13/2014 02:41, Corinna Vinschen wrote:
> So, if you have a bit of time, it would be nice to get new
> mingw64-i686-binutils and mingw64-x86_64-binutils packages (as well
> as a new Cygwin binutils, but cgf already knows about this).
> 

Sure, I'll get to it this weekend.





signature.asc
Description: OpenPGP digital signature

Re: Bug in /dev/dsp = problems at short wav-files (<2sec)

[PolarStorm]

Corinna Vinschen-2 wrote
> Here was my reply to your original thread:
> http://cygwin.com/ml/cygwin/2014-03/msg00217.html

That seem to link back to OP in THIS same thread. (at least it does so for
me.)



--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/Bug-in-dev-dsp-problems-at-short-wav-files-2sec-tp107074p107076.html
Sent from the Cygwin list mailing list archive at Nabble.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: Bug in /dev/dsp = problems at short wav-files (<2sec)

[Andrey Repin]

Greetings, Dr. Alexander Kleinsorge!

> /dev/dsp has problems playing short wav-files!
> # Cygwin 1.7.28 (32bit), Windows 7 (64 bit).

http://cygwin.com/ml/cygwin/2014-03/msg00133.html
Please read that message.

> # get 2 test files here ( 25 kB both )
> wget http://www.physik.tu-berlin.de/~aleks/wave14sL.wav
> wget http://www.physik.tu-berlin.de/~aleks/wave16sL.wav

> # Test that fails:
> cp wave16sL.wav /dev/dsp ==> I hear something (file = 1.6 sec, 12 kB).
> cp wave14sL.wav /dev/dsp ==> I hear nothing ! (file = 1.4 sec, 13 kB).
> # Format: both 8000 Hz, mono, 8 bit. (but first file is played truncated!)
> aplay same.wav # in Ubuntu 12.04 works fine.
> # also any other player (Win32 or Ubuntu is able to play both files fine).

> $ file wave14sL.wav wave16sL.wav
> wave14sL.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit,
> mono 8000 Hz
> wave16sL.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit,
> mono 8000 Hz

> $ cat /proc/version
> CYGWIN_NT-6.1-WOW64 version 1.7.28(0.271/5/3)
> 4.8.2-2) (GCC) ) 2014-02-09 21:06

> Thanks for reply,
> Alexander


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 13.03.2014, <02:23>

Sorry for my terrible english...


--
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: Cygwin64 ignoring /etc/passwd shell field?

[Chris J. Breisch]

Corinna Vinschen wrote:

On Mar 11 22:19, Achim Gratz wrote:

Corinna Vinschen writes:

Thanks for finding this one!  Unfortunately David has left us,
apparently.

Isn't it that a bit too short a time to come to this conclusion?


Is anybody willing to take over maintainership of the base-files
package?

Seeing that I have additional patches that David didn't apply to the
test version, I could do that.  But let's confirm first that he's not
just having a vacation.


Gosh, so we have two volunteers now :)

Chris, Achim, please figure out who's going to maintain the package.
If you like, you can even do this together.


I'm willing to defer to Achim, since he already has some patches, but 
I'm flexible.




--
Chris J. Breisch

--
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: Please stop sending email to ...

[Christopher Faylor]

On Thu, Mar 13, 2014 at 12:56:46AM +0400, Andrey Repin wrote:
>Greetings, Corinna Vinschen!
>
>>> >>> I know that this is a pointless exercise but I'll say it anyway: people
>>> >>> who think that they can have a private chat with Corinna or Larry by
>>> >>> sending email to what seem to be their private email addresses will just
>>> >>> show up in the spam trap, possibly even causing spamassassin to think
>>> >>> that they are a spammer.
>>> >>> 
>>> >>> We mention in multiple places that cygwin-related issues should go to
>>> >>> this list.  So, please don't bother trying to send private email unless
>>> >>> you've been specifically asked to do so.  You'll also be doing me a
>>> >>> favor because I won't have to spend time cleaning out the spam traps.
>>> >>
>>> >>Well, here goes nothing. 
>>> >>
>>> >>I am happy to admit that I'm one of those persons.  The problem is
>>> >>exactly that what you claim we "should do" versus what is actually
>>> >>possible to do.  If any of the list maintainers had actually bothered
>>> >>to try to register to these email lists, you would probably have found
>>> >>out that your spam filters are set so high, that it is impossible for
>>> >>normal people to even register to these lists!
>>> 
>>> > FYI, The Cygwin list has 1212 subscribers with 89 new joiners since
>>> > January 1.  I'm the "list maintainer" and I'm obviously registered.
>>> > The same software that handles Cygwin also handles gcc.gnu.org and
>>> > sourceware.org.  There are many other mailing lists under those
>>> > domains, and some of them have even more subscribers.
>>> 
>>> The point was, it's nowhere mentioned, who to contact in case of list 
>>> issues.
>>> Not in list mail headers, neither on list's mailman web page.
>>> I've had multiple mails blocked for containing  "foreign language" (how can 
>>> I
>>> help? It's Microsoft smarts to translate group names to make everyone
>>> unhappy), and I multiple times tried to find the address to appeal to. To no
>>> avail.
>>> Yes, I vaguely recalled, that there supposed to be "-owner" address,
>>> but it's only my poor memory. How can I trust her without confirmation?
>
>> On the other hand, the "postmaster" account exists everywhere...
>
>Not to argue, but postmaster is often not the right person to contact mailing
>list owner.
>Now, given proper explanation, I realize this is not the case for cygwin
>mailing list, and I've already pinned Christopher's message for future
>reference.

And presumably you won't argue with reference at the Cygwin list page which
says

"If you have any questions or problems with the mailing lists, see the 
Sourceware mailing list FAQs. "

and points you at a location which specifically answers your question.

The sourceware faq is mentioned *twice* at http://cygwin.com/lists.html so
your claims that it isn't mentioned anywhere would seem to indicate that you
didn't search too hard.  Ditto, your claim that nothing is mentioned in
the headers.

--
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: Problems with run.exe (silent crashes) - stopped working suddenly

[Gulliver Smith]

1) double clicking xterm.exe results in two windows - a command window
plus the xterm - this is unacceptable
2) I have used putty a lot in the past; I simply prefer xterm which I
have been using since the beginning of X-Windows
3) I have used cron for backup in the past and use it on various Linux
VMs for various purposes; with this new(er) computer I wanted to avoid
having another background service running when Windows theoretically
offers a good solution. In any case, it worked for over a year.

On Wed, Mar 12, 2014 at 4:19 PM, Andrey Repin  wrote:
> Greetings, Gulliver Smith!
>
>> My system is Windows 7 professional 64 bit. The Cygwin is 32 bit,
>> updated monthly
>
>> I have a backup script that used to run successfully from a Windows
>> shortcut or scheduled task as
>
>> C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c
>> "/home/gulliver/bin/backup >> /cygdrive/c/temp/backup.log 2>&1"
>
>> However, around August 2013 this stopped working (it took me a while to 
>> notice)
>
> run is known to crash at random occasions, since... around that time.
> I don't know if it has been fixed, sorry.
> That aside, I see no reason to use run in your case.
>
>> If I try in a windows command prompt it also crashed,
>
>> I get a small run.exe.stackdump file:
>
>> Stack trace:
>> Frame Function  Args
>> 00284B28  610303D2 (0114, EA60, 00A4, 00284B78)
>> 00284C38  610DA4DD (, 0065, 00284C78, 0028CE64)
>
>> The problem is not with the bash command or script - it runs fine from
>> both the command prompt or a shortcut if I change the command to
>
>> C:\cygwin\bin\bash.exe -l -c "/home/gulliver/bin/backup >>
>> /cygdrive/c/temp/backup.log 2>&1"
>
>> but then there is an empty Windows window open for the whole time.
>
> Use cron, then there won't be any stray windows.
>
>> A related issue is an xterm shortcut that used to work:
>
>> C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c "xterm.exe -title T
>> -bg '#EEFFFE' -e ssh -Y @&"
>
> Now, THIS is a VERY wrong way to do it.
> You're
> 1. Starting run
> 2. Telling it to start bash
> 3. Telling bash to start xterm
> 4. In which you're starting an SSH session.
>
> Why not start xterm directly? Also, ever heard of PuTTY? Or mintty?
>
>> This used to work as intended. Now it opens an xterm on the local host
>> only - the ssh command fails. Again, removing the "run" and executing
>> "bash" directly works but opens a second window.
>
>> Does anyone know what might be happening or how to debug this problem?
>
> Most simple solution would be to use right tools for the job, I'd say.
>
>
> --
> WBR,
> Andrey Repin (anrdae...@yandex.ru) 13.03.2014, <00:14>
>
> Sorry for my terrible english...
>

--
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: Compiled executables requiring admin rights - different results between MinGW host type

[Christopher Faylor]

On Thu, Mar 13, 2014 at 06:14:07AM +0800, JonY wrote:
>On 3/13/2014 02:41, Corinna Vinschen wrote:
>> So, if you have a bit of time, it would be nice to get new
>> mingw64-i686-binutils and mingw64-x86_64-binutils packages (as well
>> as a new Cygwin binutils, but cgf already knows about this).
>> 
>
>Sure, I'll get to it this weekend.

As will I.

cgf

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