Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 3185 bytes --]

On Mar 20 19:19, Achim Gratz wrote:
> Corinna Vinschen writes:
> > These functions are defined on both platforms.  What's *not* defined on
> > 64 bit, but only on 32 bit, are the same functions preceeded with an
> > underscore, e.g. _copysign.
> >
> > Can you please check again?  There's something else going wrong here.
> 
> What's going wrong is that the symbols are also defined in libc.a on
> 32bit and only in libm.a on 64bit.  The configury for Cygwin removes
> both -lc and -lm from the list of libraries that should explicitly be
> linked with, a comment is present that both libc and libm symlink to
> libcygwin and are implied by gcc anyway.  However that doesn't seem to
> be the case anymore on both architectures (these files are not symlinked
> and not hardlinked either), but the symbol construction is just
> different enough for this not to work on 64bit it would seem.

No, that's not quite it.  The problem is that on 32 bit the
*underscored* functions are exported by libc.a.  This is an accident,
and probably one which is many years old.  Here's what's exported by
libm.a:

  nm libm.a | grep copysign
	   U __imp__copysign
  00000000 T _copysign
	   U __imp__copysignf
  00000000 T _copysignf

And here's what's exported on 32 bit by libc.a.  Note the extra leading
underscore:

  $ nm libc.a | grep copysign
  00000000 T __copysign
	   U __imp___copysign
  00000000 T __copysignf
	   U __imp___copysignf

These underscored versions were always exported additionally by the 32
bit version but they have never been exported on 64 bit since exporting
them was wrong from the start.

> It works correctly if I don't let the configury check the symbols via nm
> in the link libraries, but instead compile a small test program for each
> symbol.  That's probably the best solution, all things considered.  It
> does not even seem to be that much slower.

The nm expression apparently finds the underscored versions even though
it shouldn't.

> Last but not least the Win32 and Win32-API modules have trouble with
> including the right files to get at wcslen and wcscpy.  This is what
> these sources do to apparently get at those symbols:
> 
> --8<---------------cut here---------------start------------->8---
> #define WIN32_LEAN_AND_MEAN
> #include <wctype.h>
> #include <windows.h>
> #include <shlobj.h>
> --8<---------------cut here---------------end--------------->8---
> 
> --8<---------------cut here---------------start------------->8---
> #define  WIN32_LEAN_AND_MEAN	/* Tell windows.h to skip much */
> #include <windows.h>
> #include <winioctl.h>
> --8<---------------cut here---------------end--------------->8---
> 
> What needs to be defined and/or included to get these?  From the
> MSDN documentation one would think that either string.h or wchar.h
> should do it, but is one of those preferrable?

Per POSIX it's wchar.h.  If you compile these modules using Cygwin GCC,
it will find the cygwin headers, of course.


Corinna

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]