[ANNOUNCEMENT] Updated: stable compiler package gcc4-4.5.3-2

2011-09-01 Thread 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 stable release of GCC 4.5.3 which replaces the earlier experimental
release of GCC 4.5.0.


--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 full "current" version release,
any gcc packages you currently have installed will be automatically selected
to update, but you'll need to select the Devel category to see gcc and friends
if you don't have them already installed.

NEWS


> > From the README:

gcc4-4.5.3-2
- --

This is the first full stable production release from the GCC 4.5 compiler
series for Cygwin, which replaces the experimental 4.5.0-1 release.  All
the major runtime libraries are implemented as DLLs as well as static
archives.  It can fully co-exist side-by-side with the older Cygwin gcc-3.4.4
series compiler.  All languages are supported, although Ada and Java remain
works-in-progress.


What happened to gcc4-4.5.3-1?
==

This release number was used for the initial cygwinports version of the
gcc4-4.5.3 packages.  Skipping it in the main release series avoids any
problems for cygwinports users.

Known issues in Ada and Java.
=

The Ada compiler is currently implemented as a Frankenstein-like hybrid of
Cygwin/POSIX and MinGw/w32api code.  This just barely hangs together, but
does not play nicely with Cygwin's pthread library functions; the outcome
is problems in the tasking implementation, including race conditions that
may lead to failure in early startup or termination.

There are problems with the Java compiler that are less well understood,
but also manifest themselves as testsuite failures in the thread- and
process-related tests.

These issues will be addressed in a future release of the compiler; for
now, Java and Ada cannot be considered first-class languages, but remain
somewhat experimental.  It is likely however that both perform better than
the old 3.4 series compilers.


Cygwin port maintained by: Dave Korn

Please address all questions to the Cygwin mailing list at 

This is the key used for signing Cygwin GCC releases:

pub   1024D/6A388C3E 2008-05-31
uid  Dave Korn (release signing key)
 
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
R4l4Ae3Lpgduv7V4ssz15qOGPAe++FmbutyYjF2mxwvwX86coWnkarkhuTrwoB29
Mb9IAqqpWcLqdSzUof5XSm4hesB8PASC5hCJ3D6ztMTX3OOEywSt8LJlOvgaM/YZ
fSit+5xVfGG9AXZya+jKjJnJBCyiqdWZslfRLaSHDF4M4roDk2cl8SxVJTMiBl5g
s84LLnJTIrm8HQ6oeSVrjyt8nGOCoqreOqUH6auWIEz

Re: shutdown doesn't do anything, winXP

2011-09-01 Thread Larry Hall (Cygwin) 

On 9/1/2011 2:51 PM, LMH wrote:

I have a bash script that runs rsync and I have been trying to add a command
to shutdown the computer after the backup has finished running.

I have added,

shutdown -s now

and also tried,

shutdown -s 5
shutdown -x now
shutdown -x 5

but the computer doesn't shut down. Running which shutdown gives me,

/usr/bin/shutdown

so I know its there.

Any suggestions?


One - try the full path?

Otherwise:

Problem reports: http://cygwin.com/problems.html



--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

shutdown doesn't do anything, winXP

2011-09-01 Thread LMH 
I have a bash script that runs rsync and I have been trying to add a 
command to shutdown the computer after the backup has finished running.


I have added,

shutdown -s now

and also tried,

shutdown -s 5
shutdown -x now
shutdown -x 5

but the computer doesn't shut down. Running which shutdown gives me,

/usr/bin/shutdown

so I know its there.

Any suggestions?

LMH

--
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: Request locale for ISO 8601 date.

2011-09-01 Thread Corinna Vinschen 
On Sep  1 20:18, Oleksandr Gavenko wrote:
>  $ for l in `locale -a`; do echo $l `LC_TIME=$l date`; done | tee .dat
>  $ grep -E '[[:digit:]]+-[[:digit:]]+-[[:digit:]]+
> +[[:digit:]]+:[[:digit:]]+:[[:digit:]]+' <.dat
> sq_AL 2011-09-01 8:14:09.MD
> sq_AL.utf8 2011-09-01 8:14:09.MD
> 
> but this is not ISO 8601 as '.MD' component present...
> 
> Usually 'LC_TIME' set to 'en_DK' to get ISO 8601 time format
> but Cygwin miss this locale.

Cygwin provides all locales supported by the underlying Windows system.
Windows doesn't know en_DK.

Linux (better: glibc) supports en_DK, but what you say doesn't work for
me on Linux either:

  $ LC_TIME=en_DK date
  Thu Sep  1 20:30:01 CEST 2011

No ISO 8601 representation.

> It is possible install locale to get ISO 8601 date formatting?

There is no such locale.  I tried your above grep on the Linux locales
(on F15, glibc 2.14), too, and there isn't even one which has ISO 8601
date/time by default.

If you want that date format, you have to enforce it on a per-command
base, for instance:

  $ date +'%F %T'
  $ ls -l --time-style=long-iso
  $ ls -l --time-style='+%F %T'


Corinna

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

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

Request locale for ISO 8601 date.

2011-09-01 Thread Oleksandr Gavenko 

 $ for l in `locale -a`; do echo $l `LC_TIME=$l date`; done | tee .dat
 $ grep -E '[[:digit:]]+-[[:digit:]]+-[[:digit:]]+ 
+[[:digit:]]+:[[:digit:]]+:[[:digit:]]+' <.dat

sq_AL 2011-09-01 8:14:09.MD
sq_AL.utf8 2011-09-01 8:14:09.MD

but this is not ISO 8601 as '.MD' component present...

Usually 'LC_TIME' set to 'en_DK' to get ISO 8601 time format
but Cygwin miss this locale.

It is possible install locale to get ISO 8601 date formatting?


--
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: Re: Cygwin 1.7.x on Windows 7: Exit statuses of Win32 executables are sometimes wrong

2011-09-01 Thread Kevin Layer 
I want to go on record that it happening to us, too.  And, I can say
that it is happening *much* more since I moved to this machine:

  2x AMD Opteron 6134 (16 cores total)
  Server 2008 R2 Enterprise, Service Pack 1

Software we have installed on the machine:

  ActivePerl
  AVG 9.0
  Chrome
  Java 6 Update 26
  Platform SDK (R2) (3790.2075)
  MSVC++ 6.0 (yeah, I know, old)
  VirtualCloneDrive (from Slysoft)
  3ware disk management tools
  UltraVNC 1.0 server

The previous machine had 2 cores and was running XP Pro, and had the
same software on it.  I hardly ever ran into this.  Now, it's happens
several times a day or so.


--
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 package naming?

2011-09-01 Thread Luke Kendall 

Charles Wilson wrote:

On 8/31/2011 9:43 PM, Luke Kendall wrote:
  

I'm asking because I'm finding Cygwin packages that contain no license
information, at least in the compiled form (e.g. gawk, libiconv2).



None of the "dll" packages contain license files; they are supposed to
only contain the dll itself.  Usually the license files wind up in the
"main" package, or a "-doc" package.
  


Thanks, I'll bear that in mind.  Though gawk didn't have one.  But I'll 
have a bit more of a look around inside the tarballs, manually.



However I think your BEST bet would be to do the following...get
setup.ini from $favorite_mirror.  Every record beginning with
'@ package'
will have one or more 'source:' entries -- except for some _obsolete
packages, but we don't care about those because they will just be empty
tarballs, so no source necessary.  Multiple '@ package' will refer to
the same 'source:'

  


So, basically I think you're saying I should look inside the "source:" 
instead of the "install:" (which is where I've *been* looking).


Because I have to use a mix of algorithm and *heuristics* to find the 
license files, I'd prefer to try the heuristics on the "install:" tar 
file, just because the search space (no. of files) is much smaller.


Thanks for the suggestion, though, it sounds sensible - I'll have a 
manual look inside gawk's at least and see if that looks promising, and 
if so I'll modify the script to look inside the "source:" as a fallback.



With some judicious coding (*), you should be able to flip that around,
and create a database that represents the information the other way:

-
   @ package <1>-
   @ package <2>-
   @ package <3>-
-  [same "package", different version]
   @ package <1>-
   @ package <2>-
   @ package <3>-
-
   @ package <4>-
   @ package <5>-

  


I don't think I need to do that inversion - currently if I find the 
source licenses in package 1, and it's also used for package 2, then the 
script will automatically find the licenses for package 2.



I doubt the license would often change between versions of the same
package, but it HAS been known to happen.

  


Sure.  At the moment, I'm only looking in the most recent version, too.  
I think looking in the source is more likely to find it if there's no 
license in the "install:" tarball.  I can't imagine someone deliberately 
stripping the license files out of a package.  That'd be just weird.



Now, you can find the s for which you can't identify the
license, and either (a) find another package in the same "family" --
e.g. derived from the same source -- for which you DO know the license.
 WIN!

If *all* of the "child" packages of a given source have an unknown
license, well -- then you can get the -src package itself and troll
around in it, or check freshmeat.  Usually the -src packages are named
pretty simply:
  ---src.tar.*

Watch out for this: some packages have different licenses for different
pieces.  The "libiconv" group of packages specifies that the *libraries*
are LGPL, but the *app* is GPL.  This means:
libcharset1:LGPL
libiconv2:  LGPL
libiconv:   GPL

Also, gettext group is similar; some of the libs and apps are GPL, and
some of the apps and libs are LGPL.  Fortunately, they are segregated in
the cygwin packages:
libasprintf0:   LGPL
libintl8:   LGPL
libgettextpo0:  GPL
gettext:LGPL
gettext-devel   GPL

  


Tell me about it.  "base-files" and "cygwin" are two good examples. :-)


Fortunately, that sort of structure is rare.

(*) Maybe borrow from genini, or upset?

--
Chuck



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

  


Thanks for all that!

Regards,

luke

--
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 package naming?

2011-09-01 Thread Luke Kendall 

Larry Hall (Cygwin) wrote:

On 8/31/2011 9:43 PM, Luke Kendall wrote:

Can someone with some official Cygwin standing tell me how the Cygwin
package names correspond with the "official" names of the packages, 
chosen

by the package owners? In other words, how are the Cygwin package names
determined? (My hope is that the "official" name is used, possibly with
"cygwin" added to it in some form.)


Sorry, I have no badge and gun but perhaps I will do.


I'm asking because I'm finding Cygwin packages that contain no license
information, at least in the compiled form (e.g. gawk, libiconv2). So 
I'm
thinking that in such cases, I can modify my Cygwin license-finding 
script
to look up the package by name on freshmeat and try to find the 
license from

there.

But that is pointless if the Cygwin package name may have the same 
name as a

freshmeat package, but is in fact some other software.


How about ?



Thanks!  Yes, I think that should be enough (it certainly looks like a 
public statement of Cygwin's package naming policy, so that's good 
enough for me):


"Package file naming

Package naming scheme: use the vendor's version plus a release suffix 
for ports of existing packages"




Aside: I had to muster all my strength to keep from using the phrase "Use
the source Luke!"  I expect you never tire of that. ;-)




Ah, yes, very true.  Not to mention when I eat with my fingers ("Use the 
forks, Luke!").


Thanks, Larry!

luke


--
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: mingw64-x86_64-gcc-4.5.3-2

2011-09-01 Thread JonY 
On 9/1/2011 12:37, Charles Wilson wrote:
> [sorry, sent to wrong list]
> 
> On 8/31/2011 10:22 PM, JonY wrote:
>> setup.hint still lists libmpfr1 while it should be libmpfr4, can
>> anybody correct the hint file? Or should I redo the build?
>>
> fixed on sourceware.  be sure to update your local sources, yadda
> yadda yadda.
> 

I see you have also bumped the i686 version, thanks.



signature.asc
Description: OpenPGP digital signature