This is the mail archive of the
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8
- From: Marco Atzeri <marco dot atzeri at gmail dot com>
- To: cygwin-apps at cygwin dot com
- Date: Sun, 20 Mar 2016 12:14:41 +0100
- Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8
- Authentication-results: sourceware.org; auth=none
- References: <announce dot 20160318203409 dot GA11113 at calimero dot vinschen dot de> <56EC6BDA dot 7050505 at cornell dot edu> <20160318214509 dot GD11113 at calimero dot vinschen dot de> <8760whmn3a dot fsf at Rainer dot invalid>
On 20/03/2016 11:59, Achim Gratz wrote:
Corinna Vinschen writes:
If so, it might be a good idea for maintainers to test that nothing
unexpected happens when they build their packages.
Yes, that's really a good idea.
I've run a fresh build of Perl on this.
- there's a new signal: SIGIOT
- two new symbols are found: _POSIX_C_SOURCE _POSIX_SOURCE
- compilation complains about implicit declaration of fseeko and ftello
(it could have used fseek and ftell since it's a 64bit build).
- eaccess is also implicitly defined
- some math functions are available on 32bit, but not 64bit: acosh,
asinh, atanh, cbrt, copysign, erf, erfc, expm1, finite, hypot, ilogb,
j0, lgamma, lgamma_r, log1p, lobg, nan, nextafter, remainder, scalbn
(this has likely been that way for as long as 64bit exists)
only for the long double version as in 32 bit
They exist in 2.4.1
I've also found that the configure script doesn't check correctly for
import libs and thus misses libgdm on 64bit (where only libgdm.dll.a
exists, but not libgdm.a). On 64bit gdm is also a different version
from 32bit. What's the expected standard here, really? Just .dll.a or
both that and .a?
preferred only .dll.a