The information in this CMake bug tracker issue suggests that this is *completely* a MinGW / MSYS regression, and not really a cmake issue...
http://public.kitware.com/Bug/view.php?id=12418 According to the latest note there, just added: "With mingw 4.5.2 it works, but mingw 4.6.1 fails with this error." Nothing to do with CMake or Wine at all. I would call this one a very recently introduced mingw problem. Now perhaps they corrected something that was a mistake, and now it has exposed this inconsistency in the libarchive .h vs .c declarations of things. At a minimum, I would recommend taking this discussion to the libarchive mailing list over at http://code.google.com/p/libarchive/ and asking why the header file and source file use inconsistent declarations. Perhaps there's a legitimate reason, or perhaps they've changed it since CMake last synced with upstream libarchive, or perhaps they'll say "hey, you're right, let's make this consistent..." Thanks, David On Fri, Sep 16, 2011 at 10:16 AM, Clinton Stimpson <clin...@elemtech.com> wrote: > > First off, I want to be sure we understand that you are using wine only to run > windows binaries? Correct? Wine can also be used to compile windows code > into linux binaries (for which one would use winegcc in place of the linux > gcc), but that doesn't appear to be the case here. > > If that's the situation, then I don't see how this has anything to do with > wine's header files. And you should not expect to see > $prefix/include/wine/msvcrt/sys/types.h in the include chain for > archive_read.c.obj. > > I'd look at the mingw compiler and the header files used with that. > > Clint > > On Friday, September 16, 2011 01:10:16 am Alan W. Irwin wrote: >> Hi Clint: >> >> There are questions for you below concerning where system header >> information in the Wine environment is located. >> >> On 2011-09-15 14:34-0700 Alan W. Irwin wrote: >> > Of course, Wine _might_ be at fault here for not #defining >> > _SSIZE_T_DEFINED when ssize_t is typedefed. But is that a standard >> > that you expect to be followed on all platforms or a Microsoft Windows >> > idiosyncrasy that more robust CMake code would not have to worry >> > about? >> >> I looked further, and the _Linux_ build of wine does have the following >> in the install tree >> >> $prefix/include/wine/msvcrt/sys/types.h:#define _SSIZE_T_DEFINED >> >> where $prefix is my prefix for my Linux wine install. The context for that >> #define is as follows: >> >> #ifndef _SSIZE_T_DEFINED >> #ifdef _WIN64 >> typedef __int64 ssize_t; >> #else >> typedef int ssize_t; >> #endif >> #define _SSIZE_T_DEFINED >> #endif >> >> So _SSIZE_T_DEFINED should be unequivocally #defined by the above if >> (i) the information in msvcrt/sys/types.h is available in the wine >> environment and (ii) in a location that CMake expects in that >> free Windows environment, and (iii) it is in the #include chain >> for the build of, e.g., archive_read.c.obj. >> >> Following the general Wine directions, I put $prefix/bin on my Linux >> PATH, then run winecfg, and everything seems to work fine from within >> the wine environment (e.g, the build of ephcom-2.0.2, and the build of >> CMake-2.8.5) except for the #define of _SSIZE_T_DEFINED. >> >> Clint, this next question is mostly directed to you since you have >> some Wine platform experience. What can I do further to diagnose what >> is wrong with my Wine environment such that _SSIZE_T_DEFINED is not >> #defined? >> >> I have searched throughout my .wine prefix directory (created by >> winecfg), and there are lots of dll's in that directory tree >> (including .wine/drive_c/windows/system32/msvcrt.dll), but there >> doesn't seem to be any header files in that directory tree at all. So >> how does winecfg set up access to the headers in $prefix/include? >> >> The cmake output is ambiguous about where it finds types.h. All it >> says in that regard is >> >> -- Looking for sys/types.h >> -- Looking for sys/types.h - found >> >> and for all I know that could be referring to some other header file than >> $prefix/include/wine/msvcrt/sys/types.h. In any case at the key >> moment at make time when the cmake build needs access to the above >> #define _SSIZE_T_DEFINED in that file, that file is not in the >> #include chain so _SSIZE_T_DEFINED is not #defined. >> >> Although my present build of 2.8.5 with the -D_SSIZE_T_DEFINED >> workaround wiped out my previous experiments >> with the failing build of 2.8.3, I did save the actual >> gcc command that was failing at the time. It was the following: >> >> /Z/home/wine/newstart/MinGW/bin/gcc.exe -DCURL_STATICLIB >> -DLIBARCHIVE_STATIC -DHAVE_CONFIG_H >> -I/Z/home/wine/newstart/cmake/build_dir/Utilities/cmlibarchive >> -I/Z/home/wine/newstart/cmake/build_dir/Utilities >> -I/z/home/software/cmake/cmake-2.8.3/Utilities >> -I/z/home/software/cmake/cmake-2.8.3/Utilities/cmbzip2 >> -I/z/home/software/cmake/cmake-2.8.3/Utilities/cmlibarchive/libarchive >> -o CMakeFiles/cmlibarchive.dir/archive_read.c.obj -c >> /z/home/software/cmake/cmake-2.8.3/Utilities/cmlibarchive/libarchive/archiv >> e_read.c >> >> Notice there are no -I options to help find system headers such as >> $prefix/include/wine/msvcrt/sys/types.h. In any case that header does >> not appear to be in the #include chain for the CMake build, but I will >> attempt to confirm that further tomorrow with a repeat of my gcc -E >> -dD run (this time for 2.8.5) without the -D_SSIZE_T_DEFINED workaround. >> >> Please let me know any other experiments I should be trying to pin >> down exactly why $prefix/include/wine/msvcrt/sys/types.h is not in the >> #include chain for the archive_read.c.obj build. >> >> Sorry it is taking so long to unpeel each layer of this onion, but >> debugging wine headers is completely new to me so I am having trouble >> knowing where to look for information. >> >> Alan >> __________________________ >> Alan W. Irwin >> >> Astronomical research affiliation with Department of Physics and Astronomy, >> University of Victoria (astrowww.phys.uvic.ca). >> >> Programming affiliations with the FreeEOS equation-of-state >> implementation for stellar interiors (freeeos.sf.net); the Time >> Ephemerides project (timeephem.sf.net); PLplot scientific plotting >> software package (plplot.sf.net); the libLASi project >> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); >> and the Linux Brochure Project (lbproject.sf.net). >> __________________________ >> >> Linux-powered Science >> __________________________ > > -- > Clinton Stimpson > Elemental Technologies, Inc > Computational Simulation Software, LLC > www.csimsoft.com > _______________________________________________ > cmake-developers mailing list > cmake-developers@cmake.org > http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers > _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
