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

2014-03-12 Thread 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

cvs localtion for /usr/include/*

2014-03-15 Thread zosrothko 
Hello

I am looking for the cvs location of all the /usr/include/* includes files
but did not found any. I checked out the repository
:pserver:anon...@cygwin.com:/cvs/src. 

Did I miss something?

zos



--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/cvs-localtion-for-usr-include-tp107132.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: g++ linker problem with libcygwin.a

2014-03-16 Thread zosrothko 
Hi

Here the definition of the cmain.c program, part of libcygwin.a. This code
has a "main" entry point which is  calling the WinMain by the end So the
question remains: Why g++/ld links with this "main" entry instead of the one
of the user's main program?

zos

/* libcmain.c

   Copyright 1996, 1997, 1998, 2000, 2001, 2006, 2009 Red Hat, Inc.

This file is part of Cygwin.

This software is a copyrighted work licensed under the terms of the
Cygwin license.  Please consult the file "CYGWIN_LICENSE" for
details. */

#include 

#define SP " \t\n"

/* Allow apps which don't have a main to work, as long as they define
WinMain */
int
main ()
{
  HMODULE x = GetModuleHandle (0);
  char *s = GetCommandLine ();
  STARTUPINFO si;
  char *nexts;

  s += strspn (s, SP);

  if (*s != '"')
nexts = strpbrk (s, SP);
  else
while ((nexts = strchr (s + 1, '"')) != NULL && nexts[-1] == '\\')
  s = nexts;

  if (!nexts)
nexts = strchr (s, '\0');
  else
nexts += strspn (nexts + 1, SP);

  GetStartupInfo (&si);

  return WinMain (x, 0, nexts,
  ((si.dwFlags & STARTF_USESHOWWINDOW) != 0
   ? si.wShowWindow
   : SW_SHOWNORMAL));
}




--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/g-linker-problem-with-libcygwin-a-tp37812p107147.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

Cygwin64: openssl target arch mismatch

2015-08-17 Thread zosrothko 

Hi Everybody

It seems that the Cygwin-X86_64 setup is installing the cygwin32 openssl 
package as show in the below window capture and the find command result. 
Did I miss something?


FrancisANDRE@idefix /usr> find . -name "*ssl.a"
./i686-pc-cygwin/sys-root/usr/lib/libssl.a
./lib/w32api/libw3ssl.a

no libssl.a found in usr/x86_64-pc-cygwin/sys-root/usr/lib/

Regards

FA





Le 14/07/2015 09:39, Corinna Vinschen a écrit :

Hi folks,


I've updated the version of OpenSSL to 1.0.2d-1.  This is a security
bugfix release.



OpenSSL Security Advisory [9 Jul 2015]
===

Alternative chains certificate forgery (CVE-2015-1793)
==

Severity: High

During certificate verification, OpenSSL (starting from version 1.0.1n
and
1.0.2b) will attempt to find an alternative certificate chain if the
first
attempt to build such a chain fails. An error in the implementation of
this
logic can mean that an attacker could cause certain checks on untrusted
certificates to be bypassed, such as the CA flag, enabling them to use
a valid
leaf certificate to act as a CA and "issue" an invalid certificate.

This issue will impact any application that verifies certificates
including
SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client
authentication.

This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.

OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d
OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p

This issue was reported to OpenSSL on 24th June 2015 by Adam
Langley/David
Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL
project.

Note


As per our previous announcements and our Release Strategy
(https://www.openssl.org/about/releasestrat.html), support for OpenSSL
versions
1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates
for these
releases will be provided after that date. Users of these releases are
advised
to upgrade.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv_20150709.txt

Note: the online version of the advisory may be updated with additional
details over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/about/secpolicy.html




Peace,
Corinna







Le 14/07/2015 09:39, Corinna Vinschen a écrit :

Hi folks,


I've updated the version of OpenSSL to 1.0.2d-1.  This is a security
bugfix release.



OpenSSL Security Advisory [9 Jul 2015]
===

Alternative chains certificate forgery (CVE-2015-1793)
==

Severity: High

During certificate verification, OpenSSL (starting from version 1.0.1n
and
1.0.2b) will attempt to find an alternative certificate chain if the
first
attempt to build such a chain fails. An error in the implementation of
this
logic can mean that an attacker could cause certain checks on untrusted
certificates to be bypassed, such as the CA flag, enabling them to use
a valid
leaf certificate to act as a CA and "issue" an invalid certificate.

This issue will impact any application that verifies certificates
including
SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client
authentication.

This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.

OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d
OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p

This issue was reported to OpenSSL on 24th June 2015 by Adam
Langley/David
Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL
project.

Note


As per our previous announcements and our Release Strategy
(https://www.openssl.org/about/releasestrat.html), support for OpenSSL
versions
1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates
for these
releases will be provided after that date. Users of these releases are
advised
to upgrade.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv_20150709.txt

Note: the online version of the advisory may be updated with additional
details over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/about/secpolicy.html




Peace,
Corinna





This email has been protected by YAC (Yet Another Cleaner) http://www.yac.mx
Cygwin Configuration Diagnostics
Current System Time: Mon Aug 17 07:53:06 2015

Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1

Path:   C:\ASF\apache-ant-1.9.3\bin
C:\cygwin64\usr\local\bin
C:\cygwin64\bin
C:\Program Files (x86)\GALITT\Common
C:\ProgramData\Oracle\Java\javapath
C:\Python33
C:\Windows\system32
C:\Win