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
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
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
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
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
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
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
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
On 2011-09-14 21:54-0700 Alan W. Irwin wrote:
On 2011-09-01 05:45-0700 Alan W. Irwin wrote:
On 2011-08-28 14:34-0400 Bill Hoffman wrote:
Can you try and build CMake 2.8.4, then 2.8.3 and see what happens?
[...]I thought wine-1.3.27 might have been to culprit, but it turns out I
was just
On 9/15/2011 4:12 AM, Alan W. Irwin wrote:
To eliminate the latter possibility, could somebody please try to
build cmake with the MSYS Makefiles generator on Windows?
We have a dashboard for this. I build that all the time on
my own machine too. Just in case, I updated the toolchain:
On 9/15/2011 4:12 AM, Alan W. Irwin wrote:
That automatic installer (available
at http://sourceforge.net/projects/mingw/files/Automated MinGW
Installer/mingw-get-inst/)
literally takes about 5 minutes to download and install all of
MinGW/MSYS on wine, and I am sure that it would even be
On 2011-09-15 09:22-0400 Brad King wrote:
On 9/15/2011 4:12 AM, Alan W. Irwin wrote:
To eliminate the latter possibility, could somebody please try to
build cmake with the MSYS Makefiles generator on Windows?
We have a dashboard for this. I build that all the time on
my own machine too.
On 9/15/2011 12:34 PM, Alan W. Irwin wrote:
That sounds definitive, but I don't really trust MinGW/MSYS installers
(since that is alpha software) to do the right thing with updates. It
wasn't that long ago that that functionality was completely broken.
Instead, what I did was a complete install
On 2011-09-15 09:27-0400 Bill Hoffman wrote:
On 9/15/2011 4:12 AM, Alan W. Irwin wrote:
That automatic installer (available
at http://sourceforge.net/projects/mingw/files/Automated MinGW
Installer/mingw-get-inst/)
literally takes about 5 minutes to download and install all of
MinGW/MSYS on
On 2011-08-27 16:22-0700 Alan W. Irwin wrote:
If you compare the types of archive_read_data and
archive_read_data_into_buffer in archive_read.c versus
archive.h, the *.c versions are
ssize_t
archive_read_data(struct archive *_a, void *buff, size_t s)
int
archive_read_data_into_buffer(struct
On 2011-09-01 05:45-0700 Alan W. Irwin wrote:
On 2011-08-28 14:34-0400 Bill Hoffman wrote:
Can you try and build CMake 2.8.4, then 2.8.3 and see what happens?
Given many hours of computer time (remember the severe latency issue), yes.
I will get to this eventually, but other projects and
On 2011-08-28 14:34-0400 Bill Hoffman wrote:
Can you try and build CMake 2.8.4, then 2.8.3 and see what happens?
Given many hours of computer time (remember the severe latency issue), yes.
I will get to this eventually, but other projects and computer issues are
currently
delaying it.
As an experiment on the MinGW/MSYS/wine platform I tried to
build cmake from the bash.exe command line as follows:
cmake -G MSYS Makefiles \
-DCMAKE_INSTALL_PREFIX=/z/home/wine/newstart1/cmake/install \
/z/home/software/cmake/cmake-$CMAKE_VERSION cmake.out
make make.out
where
18 matches
Mail list logo
