ddavis2speedray / googletest

Automatically exported from code.google.com/p/googletest
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

1.5.0 will not build with MinGW's GCC #298

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Download/unpack Gtest-1.5.0
2a. Using MSYS: ./configure
 or
2b. cmake -G "MSYS Makefiles"
 or
2c. cmake -G "MinGW Makefiles"
 or
2d. Using Fedora's mingw32 cross-compiling packages: mingw32-cmake
3. If you choose c above run mingw32-make, otherwise run make.

What is the expected output? What do you see instead?

I expect at least one of these methods to build a gtest library I can use for 
testing with MinGW. See attachments for the error messages.

What version of Google Test are you using? On what operating system?

1.5.0, on Windows XP SP3 and Fedora 12

Please provide any additional information below, such as a code snippet.

I was able to build gtest-1.4.0 using method 2a above, with no apparent 
problems -- the other methods were impossible since 1.4.0 wasn't using CMake.

Original issue reported on code.google.com by ian.cull...@uqconnect.edu.au on 29 Jun 2010 at 5:45

Attachments:

GoogleCodeExporter commented 9 years ago
I was able to build gtest-1.5.0 libraries and tests on MinGW-5.1.6(gcc 
3.4.5)/MSYS-1.0.11/WinXP-SP3 -- using either ./configure or CMake 2.8 with MSYS 
Makefiles generator.

Please describe your setup in more detail.

Original comment by vladlosev on 30 Jun 2010 at 7:34

GoogleCodeExporter commented 9 years ago
MinGW-5.1.6(gcc4.4.0)/WinXP-SP3 using CMake 2.8 "MSYS Makefiles" was the build 
output attached above.

The version of GCC on Fedora is: i686-pc-mingw32-g++ (GCC) 4.4.1 20090902 
(Fedora MinGW 4.4.1-3.fc12). This is on 64-bit Fedora 12. The build output is 
very similar to that attached above.

I've attached the build output from 
MinGW-5.1.6(gcc4.4.0)/MSYS-1.0.11/WinXP-SP3, using ./configure.

Sorry for taking a while to get back to you on this. Do you need any other 
details?

Original comment by ian.cull...@uqconnect.edu.au on 7 Jul 2010 at 7:28

Attachments:

GoogleCodeExporter commented 9 years ago
I was able to reproduce the issue with gcc 4.4. It looks like with gcc 4.4, 
MinGW introduced pthread implementation. This triggers several issues:

 - First, there gtest tries to use types defined in pthreads.h before including the header. This is a bug and we'll fix it shortly.
- Second, gtest makes assumption of having other POSIX features available when 
pthreads support is present. This is a reasonable assumption, but it doesn't 
hold for MinGW now. It's possible to update gtest to use Win32 APIs instead on 
Win32-based systems, but that that leads us to the third issue:
- Third, it looks like MinGW does not properly implement pthreads. The POSIX 
says that pthread_t has to be arithmetic type, and WinGW defines it as a 
structure. 

Given all this, it makes no sense for gtest to use pthreads in MinGW. Simply 
run configure with --use-pthreads=no to disable pthreads. I was able to build 
gtest with GCC 4.4 this way.

Our CMake build scripts do not yet have the equivalent of --with-pthreads=no, 
but we are planning to add it. That is tracked in the issue 269.

As we won't be making changes to address this specific issue, I am closing it 
for now.

Original comment by vladlosev on 7 Jul 2010 at 6:12

GoogleCodeExporter commented 9 years ago
As Vlad observed, some OSes support POSIX threads but gtest's threading tests 
fail there. See 
http://groups.google.com/group/googletestframework/browse_thread/thread/66eacb6c
45df8470/
8fc028eeee080d29#8fc028eeee080d29 for an example.

I think we should hard-code logic in gtest-port.h to disable threading on such 
platforms.

Original comment by w...@google.com on 28 Sep 2010 at 12:14

GoogleCodeExporter commented 9 years ago

Original comment by w...@google.com on 28 Sep 2010 at 5:34

GoogleCodeExporter commented 9 years ago
Fixed in r492.

Original comment by vladlosev on 12 Oct 2010 at 3:44