Updated: gcc-5.3.0-5 (x86)

[JonY]

gcc-5.3.0-5 has been uploaded for Cygwin, it should now scan /usr/lib
ahead of /usr/lib/w32api.

GCC5 uses a new versioning scheme, under the old scheme, it would be
5.0.3, with 5.2.0 as 5.0.2. See https://gcc.gnu.org/develop.html under
"Version Numbering Scheme for GCC 5 and Up".

This version has been built with
--with-default-libstdcxx-abi=gcc4-compatible so it should remain
compatible to GCC 4 C++ ABI.

Note that C11 with gnu extensions is now default for C. See
https://gcc.gnu.org/gcc-5/porting_to.html for more help on porting code
to GCC 5.

Changes since -4:
* Fix w32api lib search path order.

Changes since -3:
* Rebuilt for cygwin 2.5.0.

Changes since -2:
* Revert to gcc-4 behavior, search /usr/lib before /usr/lib/w32api.

Changes since -1:
* Fixed -rdynamic, thanks to Yaakov.
* libitm, libcilkrts enabled, also thanks to Yaakov.

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






signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: gcc-5.3.0-5 (x86)

[JonY]

gcc-5.3.0-5 has been uploaded for Cygwin, it should now scan /usr/lib
ahead of /usr/lib/w32api.

GCC5 uses a new versioning scheme, under the old scheme, it would be
5.0.3, with 5.2.0 as 5.0.2. See https://gcc.gnu.org/develop.html under
"Version Numbering Scheme for GCC 5 and Up".

This version has been built with
--with-default-libstdcxx-abi=gcc4-compatible so it should remain
compatible to GCC 4 C++ ABI.

Note that C11 with gnu extensions is now default for C. See
https://gcc.gnu.org/gcc-5/porting_to.html for more help on porting code
to GCC 5.

Changes since -4:
* Fix w32api lib search path order.

Changes since -3:
* Rebuilt for cygwin 2.5.0.

Changes since -2:
* Revert to gcc-4 behavior, search /usr/lib before /usr/lib/w32api.

Changes since -1:
* Fixed -rdynamic, thanks to Yaakov.
* libitm, libcilkrts enabled, also thanks to Yaakov.

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






signature.asc
Description: OpenPGP digital signature

Ruby version 2.2.4-1 troubles

[David Schmitt]

Ruby stops working when I install 2.2.4-1 and resumes working when I downgrade 
to 2.2.3-1.

I would guess the problem is triggered by anti-virus software (which I cannot 
disable) preventing the load of some new DLL.

Has anyone else encountered (and worked-around) this problem?

Symptoms:
- Ruby scripts all silently exit with status 0 (no error message)
- Invoking the ruby command directly also exits with status 0 and no error 
message

Environment:
- Windows 7 Professional 64 bit
- Cygwin 32 bit (some packages I need were not available as 64 bit)
- Installed for local user only (I don’t have admin privileges)
  
--
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: Formatting command line arguments when starting a Cygwin process from a native process

[David Allsopp]

Andrey Repin wrote:
> Greetings, David Allsopp!

And greetings to you, too!



> > I'm not using cmd, or any shell for that matter (that's actually the
> > point) - I am in a native Win32 process invoking a Cygwin process 
> > directly using the Windows API's CreateProcess call. As it happens, 
> > the program I have already has the arguments for the Cygwin process 
> > in an array, but Windows internally requires a single command line 
> > string (which is not in any related to Cmd).
> 
> Then all you need is a rudimentary quoting.

Yes, but the question still remains what that rudimentary quoting is - i.e.
I can see how to quote spaces which appear in elements of argv, but I cannot
see how to quote double quotes! 

> The rest will be handled by getopt when the command line is parsed.

That's outside my required level - I'm interested in Cygwin's emulation
handling the difference between an operating system which actually passes
argc and argv when creating processes (Posix exec/spawn) and Windows (which
only passes a single string command line). The Microsoft C Runtime and
Windows have a "clear" (at least by MS standards) specification of how that
single string gets converted to argv, I'm trying to determine Cygwin's -
getopt definitely isn't part of that.

> >> However, I've found Windows's interpretation to be inconsistent, so 
> >> often have to play with it to find what the "right combination" is 
> >> for a particular instance.
> >>
> >> I find echoing the parameters to a temporary text file and then 
> >> using the file as input to be more reliable and easier to 
> >> troubleshoot, and it breaks apart whether it is Windows cli 
> >> inconsistencies or receiving program issues very nicely with the 
> >> text file content as an intermediary
> 
> > This is an OK tack, but I don't wish to do this by experimentation 
> > and get caught out later by a case I didn't think of, so what I'm 
> > trying to determine is *exactly* how the Cygwin DLL processes the 
> > command line via its source code so that I can present it with my 
> > argv array converted to a single command line and be certain that 
> > the Cygwin will
> recover the same argv DLL.
> 
> > My reading of the relevant sources suggests that with globbing 
> > disabled, backslash escape sequences are *never* interpreted (since 
> > the quote function returns early - dcrt0.cc, line 171). If there is 
> > no way of encoding the double quote character, then perhaps I have 
> > to run with globbing enabled but ensure that the globify function 
> > will never actually expand anything - but as that's a lot of work, I 
> > was wondering
> if I was missing something with the simpler "noglob" case.
> 
> The point being, when you pass the shell and enter direct process 
> execution, you don't need much of shell magic at all.
> Shell conventions designed to ease interaction between system and 
> operator.
> But you have a system talking to the system, you can be very literal.

Indeed, which is why I'm trying to avoid the shell! But I can't be entirely
literal, because Posix and Windows are not compatible, so I need to
determine precisely how Cygwin's emulation works... and so far, it doesn't
seem to be a terribly clearly defined animal!

So, resorting to C files to try to demonstrate it further. spawn.cc seems to
suggest that there should be some kind of escaping available, but I'm
struggling to follow the code. Consider these two:

callee.c
  #include 
  int main (int argc, char* argv[])
  {
int i;

printf("argc = %d\n", argc);
for (i = 0; i < argc; i++) {
  printf("argv[%d] = %s\n", i, *argv++);
}
return 0;
  }

caller.c
  #include 
  #include 

  int main (void)
  {
LPTSTR commandLine;
STARTUPINFO startupInfo = {sizeof(STARTUPINFO), NULL, NULL, NULL, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, NULL, NULL, NULL, NULL};
PROCESS_INFORMATION process = {NULL, NULL, 0, 0};

commandLine = "callee.exe \"@\"te\"\n\"st fo@o bar\" \"baz baz *";
if (!CreateProcess("callee.exe", commandLine, NULL, NULL, FALSE, 0,
NULL, NULL, , )) {
  printf("Error spawning process!\n");
  return 1;
} else {
  WaitForSingleObject(process.hProcess, INFINITE);
  CloseHandle(process.hThread);
  CloseHandle(process.hProcess);
  return 0;
}
  }

If you compile as follows:

  $ gcc -o callee callee.c
  $ i686-w64-mingw32-gcc -o caller caller.c
  $ export CYGWIN=noglob  # Or the * will be expanded
  $ ./caller

and the output is as required:
  argc = 6
  argv[0] = callee
  argv[1] = @te
  st
  argv[2] = fo@o
  argv[3] = bar baz
  argv[4] = fliggle
  argv[5] = *

But if I want to embed an actual " character in any of those arguments, I
cannot see any way to escape it which actually works at the moment. For
example, if you change commandLine in caller.c to be "callee.exe test\\\"
argument" then the erroneous output is:

  argc = 2
  argv[0] = callee
  argv[1] = test\ argument

where the required output is

  argc = 3
  argv[0] = 

Re: cmp missing from base

[Thomas Wolff]

Am 07.05.2016 um 03:41 schrieb Warren Young:

On May 6, 2016, at 3:53 AM, Thomas Wolff  wrote:

after a recent fresh installation of cygwin, I was surprised that `cmp` was 
missing, which is part of the traditional Unix base commands.
I think the diffutils package should be part of the base installation.

We’ve never really had a hard rule on what is in Base and what isn’t.  It’s 
always been a judgement call.

I wonder if the rule should just be “POSIX”?  That is, if it’s on this page, it 
should be in Base:

   http://pubs.opengroup.org/onlinepubs/9699919799/idx/utilities.html

That would exclude other things we’ve always excluded, such as Perl.

I’m not suggesting that we make this rule a strict one.  Most importantly, it 
cannot be an exclusion rule: Cygwin must contain things not in POSIX.  I’m just 
suggesting that it would be nice if Cygwin were as close to POSIX as practical 
out-of-the-box.

By that latter, I mean without extra effort other than adjusting some 
setup.hint files.  I mean, if there is a command on that list that doesn’t even 
have a Cygwin package, I don’t mean to propose with this rule that someone must 
go out and package it just to satisfy POSIX.

As a counterexample, that list contains pax(1), which is currently in Archive, 
not Base, so by that rule, pax(1) should also move to Base.

By that very example, though, I can argue against this proposed rule: as I 
understand it, pax(1) was added to POSIX at the same time they dropped cpio(1) 
and tar(1), thinking that by doing so, they’d change existing practice, moving 
everyone over to pax(1).  That just created a Standard in the XKCD sense:

   https://xkcd.com/927/

Thanks, Warren, for some metaphysical insights :)
Right, there isn't and shouldn't be a strict rule. But maybe there can 
be a guideline, and more a guideline of common practice than of a 15th 
standard. By decade-long practice as a Unix user, I was simply expecting 
cmp to be basic, like I would expect tar. Maybe others would agree with 
that, or maybe not...

Cheers
Thomas

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