This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


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

  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

  $ 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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]