Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
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/archive_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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
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
Re: [cmake-developers] Some advice
On Fri, Sep 16, 2011 at 5:11 AM, Alexander Neundorf neund...@kde.orgwrote:
On Thursday, September 15, 2011 10:22:52 PM James Bigler wrote:
On Mon, Sep 12, 2011 at 3:35 PM, James Bigler jamesbig...@gmail.com
wrote:
I need some advice on how to fix a problem I'm having with files with
the
same name.
I have two CUDA files with the same name in different directories:
CUDA_ADD_EXECUTABLE(test-conflict
path with spaces/conflict.cpp
path with spaces/conflict.cu
path with spaces/no-conflict.cpp
path with spaces/no-conflict.cu
conflict-main.cpp
conflict.cpp
conflict.cu
)
I notice that the cpp files get the following outputs:
path with spaces/no-conflict.cpp: test-conflict.dir\Debug
path with spaces/conflict.cpp:
test-conflict.dir\Debug\/path_with_spaces/conflict.cpp.obj
conflict.cpp: test-conflict.dir\Debug\/conflict.cpp.obj
This seems to work well and everyone is happy.
The FindCUDA code is a different story, and one I wish to get some more
input on. The current implementation takes the basename and merges it
in
with the target name like so (one example given):
${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${cuda_target}_generated
_${basename}${generated_extension}
The problem is two files with the same basename can cause collisions in
the naming scheme. I'm wondering if the best solution is to keep a per
target list of basenames as a directory property and when collisions
happen, create a new sub-directory to be used by the build script. My
question at this point is what and how to compute the non-conflicting
directories. Does anyone have any good suggestions for how to
implement
this?
Thanks,
James
How about telling me where I can find how CMake does this for the C code?
I notice that it only puts sub directories when there's a conflict, so
there's logic somewhere that determines this and then determines what the
intermediate directories should be.
CMake creates a directory for every target, and inside that directory, it
creates subdirectories for every subdirectory present in the input files.
To avoid clashes between foo.c and foo.cpp, the .o is simply appended, so
we
get foo.c.o and foo.cpp.o.
Alex
Thanks for the response Alex, but that's not quite it. From my experiments,
CMake only puts object files in sub directories (below the target
sub-directory) when it detects the clash (see the original email). I also
have clashes on file names and not just extensions.
I'm trying to figure out how to best handle the partial paths.
If you had this then I can compute the relative path with respect to
CMAKE_CURRENT_SOURCE_DIR.
dir1/file.cpp
dir2/file.cpp
What if I had this:
../dir1/file.cpp
../../dir2/file.cpp
What do I use as the sub directory? I can't use ../ in the path as this
will totally put things in the wrong directory
(CMAKE_CURRENT_BINARY_DIR/CMakeFiles/target.dir/../dir1 would generally be a
bad idea).
And what if I had an absolute file path? What do I do then?
James
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Some advice
On 9/16/2011 12:22 PM, James Bigler wrote: Thanks for the response Alex, but that's not quite it. From my experiments, CMake only puts object files in sub directories (below the target sub-directory) when it detects the clash (see the original email). I also have clashes on file names and not just extensions. CMake computes object file names deterministically for each source file compiled in each target. There is no clash detection. The deterministic algorithm guarantees that there will be no conflicts except in pathological cases. If you had this then I can compute the relative path with respect to CMAKE_CURRENT_SOURCE_DIR. dir1/file.cpp dir2/file.cpp What if I had this: ../dir1/file.cpp ../../dir2/file.cpp What do I use as the sub directory? I can't use ../ in the path as this will totally put things in the wrong directory (CMAKE_CURRENT_BINARY_DIR/CMakeFiles/target.dir/../dir1 would generally be a bad idea). CMake uses __/ instead of ../. And what if I had an absolute file path? What do I do then? CMake takes of leading slashes and places : with _. After the above transformations CMake then does a bunch more magic to prevent the paths from getting too long for Windows path length limits. The C++ code that computes object names is here: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalGenerator.cxx;hb=v2.8.5#l2580 -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
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
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 9/16/2011 2:48 PM, David Cole wrote: 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... Start by trying to build the latest upstream libarchive. CMake's copy is very old. We don't want to trouble them for something they already fixed. I know that libarchive intentionally uses separate type names for the public interface declarations and the implementation definitions. The reason is they want the public headers to not depend on any try-compile results. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 2011-09-16 14:48-0400 David Cole wrote: 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. Hmm. Brad and Bill just got through assuring me repeatedly there is no problem with the most recent MinGW/MSYS build of CMake on Microsoft Windows. Of course, they could be up against the case where some Microsoft platforms work and others do not. Anyhow, it appears this guy got the same broken build on some Microsoft platform that I am getting on Wine. It appears the next obvious step is to attempt replicating that guy's broken-build results with the most recent MinGW/MSYS on whatever Microsoft platform he was using. Note, I would be quite relieved (since I am way beyond my depth here) if one of you could find a way verify that broken build on Microsoft Windows. That means Wine is just a distraction to the discussion, and I can let some expert Kitware employee deal with this issue who presumably has a large desire to have builds of CMake with recent MinGW/MSYS actually work on all Microsoft Windows platforms. 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 9/16/2011 4:35 PM, Brad King wrote: Try this patch: diff --git a/Utilities/cmlibarchive/libarchive/archive.h b/Utilities/cmlibarchive/libarchive/archive.h index 9b918a8..b2bb829 100644 --- a/Utilities/cmlibarchive/libarchive/archive.h +++ b/Utilities/cmlibarchive/libarchive/archive.h @@ -52,7 +52,7 @@ /* These should match the types used in 'struct stat' */ #if defined(_WIN32) !defined(__CYGWIN__) #define __LA_INT64_T__int64 -# if defined(_SSIZE_T_DEFINED) +# if defined(_SSIZE_T_DEFINED) || (defined(_SSIZE_T_) !defined(_NO_OLDNAMES)) # define __LA_SSIZE_T ssize_t # elif defined(_WIN64) As expected upstream libarchive already fixed this: http://code.google.com/p/libarchive/source/detail?r=3649 -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 9/16/2011 4:40 PM, Brad King wrote: As expected upstream libarchive already fixed this: http://code.google.com/p/libarchive/source/detail?r=3649 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8dfe74c3 -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 2011-09-16 16:46-0400 Brad King wrote: On 9/16/2011 4:40 PM, Brad King wrote: As expected upstream libarchive already fixed this: http://code.google.com/p/libarchive/source/detail?r=3649 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8dfe74c3 Hi Brad, Bill, and Dave: As anticipated, that version of the patch (for cmake-2.8.5) works for me on Wine. @ Brad: Thanks for trying my suggestion that older MinGW/MSYS installers might not be so good at updating to get you the latest version of MinGW/MSYS. @ Bill: Thanks for the encouragement to keep pursuing this issue. @ Dave: Thanks for noticing the bug report that had the same broken build issue that I was having on Wine which was the key breakthrough in my opinion. This has been a tough one for me because (i) my Wine environment is slow (each cmake build takes more than an hour because of a nasty 1-second command startup latency issue for each command run by cmake and make), (ii) too many possibilities (Wine, CMake, or MinGW) for the source of the issue, and (iii) many preprocessor directives that made it virtually impossible to eyeball the code to see what was wrong (although gcc -E -dD eventually came to the rescue there). Anyhow, I am very glad that the CMake code finally has a solution for this issue! 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
