mingw-users Mailing List for MinGW - Minimalist GNU for Windows

On 29/10/15 17:01, Anderson, Amos wrote:
> I’m trying to assess the feasibility of cross compiling a C++ program
> for Windows from OSX 10.9.

There is no reason, at all, why it should not be feasible ... it's how I
build all the MinGW.org packages I distribute, using a GNU/Linux host
for my builds.

> I followed steps like these:
> http://www.blogcompiler.com/2010/07/11/compile-for-windows-on-linux/

I've no idea how reliable the information there might be; its author is
not associated with MinGW.org, AFAIK, and I am not willing to invest my
time in vetting content over which I have no control.

> I downloaded and unpacked mingw-w64-bin_i686-darwin_20130622.tar.bz2.

Once again, I've no idea what that provides; this is not a package which
we either provide, or support, and I've always built my cross compilers
myself, from official gcc.org sources.

> And here’s what I got:
> 
> x86_64-w64-mingw32/bin/gcc test.cpp
> gcc: error trying to exec 'cc1plus': execvp: No such file or directory
> 
> I guess I expected that to work out of the box.

Looks like you may not have installed all the packages you need...

> Is there an easy fix? 

...but I suggest that you seek advice from the distributors of whatever
packages you are using; we cannot comment on issues with a distribution
which does not originate from ourselves.

-- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F

Hello MinGW Users,

I’m trying to assess the feasibility of cross compiling a C++ program for Windows from OSX 10.9. I followed steps like these:
http://www.blogcompiler.com/2010/07/11/compile-for-windows-on-linux/

I downloaded and unpacked mingw-w64-bin_i686-darwin_20130622.tar.bz2. And here’s what I got:


x86_64-w64-mingw32/bin/gcc test.cpp

gcc: error trying to exec 'cc1plus': execvp: No such file or directory


I guess I expected that to work out of the box. Is there an easy fix? It would be nice if I could do this myself (as opposed to finding someone w/ Visual Studio) since my project is simple, but I’m not really up for being a "beta tester" of the homebrew formula I found.


Thanks!

Amos.

On 11/10/15 19:39, Eli Zaretskii wrote:
> Autoconf tends to produce very complex scripts, as you well know.

Sure; just like the the a.out or a.exe produced by GCC is a complex
format, at least for a human to interpret.  I tend to view autoconf much
like a compiler, and inspect its generated configure script only for the
purpose of debugging ... the human readable form of this configure
script is configure.ac, plus any other sources it includes.

-- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F

Hi Gisle (Vanem),

Your hint solved my problem!

Many thanks for your help, as well as for the contributions of Keith Marshall and Eli Zaretskii

On 11/10/15 19:43, Eli Zaretskii wrote:
>> From: Keith Marshall
>> Date: Sun, 11 Oct 2015 19:29:27 +0100
>> 
>> Reality, however, is rather more encouraging ... autoconf isn't so lame.
>> [...]
>>   checking for unistd.h... yes
>>   checking for struct timespec.tv_sec... yes
>> 
>> successfully detects that struct timespec is defined, *without* ever
>> looking for <pthread.h>:
> 
> I know ;-)  See
> 
>   http://lists.gnu.org/archive/html/bug-gnulib/2015-01/msg00042.html

Yes.  We both know the story behind that.  It was my oversight in
mingwrt-3.21, and I fixed it in 3.21.1.  The gnulib folks might wish to
reconsider their need for that patch, (unless they wish to continue to
support a runtime library version which we consider to be defunct).

-- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F

> From: Keith Marshall <kei...@us...>
> Date: Sun, 11 Oct 2015 19:29:27 +0100
> 
> Reality, however, is rather more encouraging ... autoconf isn't so lame.
> [...]
>   checking for unistd.h... yes
>   checking for struct timespec.tv_sec... yes
> 
> successfully detects that struct timespec is defined, *without* ever
> looking for <pthread.h>:

I know ;-)  See

  http://lists.gnu.org/archive/html/bug-gnulib/2015-01/msg00042.html

> so if GNU projects *are* looking to <pthread.h> for the definition
> of struct timespec, it is because individual project maintainers
> have specified it thus ... quite inappropriately, IMO.

Yes, there's that as well.  Also, packages that are not maintained
very actively come with old versions of Autoconf macros.

> From: Keith Marshall <kei...@us...>
> Date: Sun, 11 Oct 2015 18:58:40 +0100
> 
> >> A reasonable approach, but kind of begs the question ... if the project
> >> doesn't need pthreads, why would its configuration script(s) check for
> >> <pthread.h>?
> > 
> > Because the standard GNU configure tests "know" this is one place
> > where 'struct timespec' is declared.
> 
> Ah.  Okay, thanks for that clarification, but (being pedantic) should it
> not rather look to <sched.h>, since that is where POSIX.1 requires
> struct timespec to be defined?  (Of course, that definition would then
> propagate through <pthread.h>, which is required to expose all of the
> definitions within <sched.h> anyway, but selecting the outer header is
> nothing short of blatant namespace pollution, especially since the
> preferred origin for struct timespec is <time.h> in the first place).

They do try pthread.h, and pthread.h indeed includes sched.h.

> > No, most such packages don't use pthreads (or any threads), they just
> > need the struct declaration.
> 
> In which case, they should favour <time.h> as its provider ... yes, I do
> know that mingwrt-3.21 was broken in this respect, but that has been
> corrected in mingwrt-3.21.1.  Any preference to elect for inclusion of
> <pthread.h>, rather than <time.h>, if that's what it actually does just
> for struct timespec, seems to me like it may be a misfeature of GNU
> autoconf.

Autoconf tends to produce very complex scripts, as you well know.
While it's true that time.h (and sys/time.h) are tried before
pthread.h, I'm quite sure I've seen semi-buggy packages that sometimes
have it the other way around, especially in nested configure scripts,
or even just hard-code use of struct timespec by #ifdef HAVE_PTHREAD_H.
It's a mess...

On 11/10/15 18:58, Keith Marshall wrote:
> On 11/10/15 18:14, Eli Zaretskii wrote:
>>> From: Keith Marshall <kei...@us...>
>>> Date: Sun, 11 Oct 2015 17:56:36 +0100
>>>
>>> On 11/10/15 16:11, Eli Zaretskii wrote:
>>>> My personal solution is (assuming you don't really need pthreads in
>>>> that project) to rename the pthreads headers, so they "don't exist" as
>>>> far as the configuration scripts are concerned.
>>>
>>> A reasonable approach, but kind of begs the question ... if the project
>>> doesn't need pthreads, why would its configuration script(s) check for
>>> <pthread.h>?
>>
>> Because the standard GNU configure tests "know" this is one place
>> where 'struct timespec' is declared.
> 
> ...

>> No, most such packages don't use pthreads (or any threads), they just
>> need the struct declaration.
> 
> In which case, they should favour <time.h> as its provider ... yes, I do
> know that mingwrt-3.21 was broken in this respect, but that has been
> corrected in mingwrt-3.21.1.  Any preference to elect for inclusion of
> <pthread.h>, rather than <time.h>, if that's what it actually does just
> for struct timespec, seems to me like it may be a misfeature of GNU
> autoconf.

Reality, however, is rather more encouraging ... autoconf isn't so lame.
This minimal configure script:

  $ cat configure.ac
  AC_INIT
  AC_CHECK_MEMBERS([struct timespec.tv_sec])

when run thus:

  $ autoconf
  $ ./configure --build=linux --host=mingw32
  checking for mingw32-gcc... mingw32-gcc
  checking whether the C compiler works... yes
  checking for C compiler default output file name... a.exe
  checking for suffix of executables... .exe
  checking whether we are cross compiling... yes
  checking for suffix of object files... o
  checking whether we are using the GNU C compiler... yes
  checking whether mingw32-gcc accepts -g... yes
  checking for mingw32-gcc option to accept ISO C89... none needed
  checking how to run the C preprocessor... mingw32-gcc -E
  checking for grep that handles long lines and -e... /bin/grep
  checking for egrep... /bin/grep -E
  checking for ANSI C header files... yes
  checking for sys/types.h... yes
  checking for sys/stat.h... yes
  checking for stdlib.h... yes
  checking for string.h... yes
  checking for memory.h... yes
  checking for strings.h... yes
  checking for inttypes.h... yes
  checking for stdint.h... yes
  checking for unistd.h... yes
  checking for struct timespec.tv_sec... yes

successfully detects that struct timespec is defined, *without* ever
looking for <pthread.h>:

  $ grep pthread config.log

is completely silent, indicating absolutely no reference whatsoever, to
anything even remotely related to pthreads, so if GNU projects *are*
looking to <pthread.h> for the definition of struct timespec, it is
because individual project maintainers have specified it thus ... quite
inappropriately, IMO.

-- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F

On 11/10/15 18:14, Eli Zaretskii wrote:
>> From: Keith Marshall <kei...@us...>
>> Date: Sun, 11 Oct 2015 17:56:36 +0100
>>
>> On 11/10/15 16:11, Eli Zaretskii wrote:
>>> My personal solution is (assuming you don't really need pthreads in
>>> that project) to rename the pthreads headers, so they "don't exist" as
>>> far as the configuration scripts are concerned.
>>
>> A reasonable approach, but kind of begs the question ... if the project
>> doesn't need pthreads, why would its configuration script(s) check for
>> <pthread.h>?
> 
> Because the standard GNU configure tests "know" this is one place
> where 'struct timespec' is declared.

Ah.  Okay, thanks for that clarification, but (being pedantic) should it
not rather look to <sched.h>, since that is where POSIX.1 requires
struct timespec to be defined?  (Of course, that definition would then
propagate through <pthread.h>, which is required to expose all of the
definitions within <sched.h> anyway, but selecting the outer header is
nothing short of blatant namespace pollution, especially since the
preferred origin for struct timespec is <time.h> in the first place).

>> (Unless, of course, it can use pthreads if supported, or some
>> alternative fall-back otherwise ... in which case lack of any such
>> alternative support could be something of a show-stopper).
> 
> No, most such packages don't use pthreads (or any threads), they just
> need the struct declaration.

In which case, they should favour <time.h> as its provider ... yes, I do
know that mingwrt-3.21 was broken in this respect, but that has been
corrected in mingwrt-3.21.1.  Any preference to elect for inclusion of
<pthread.h>, rather than <time.h>, if that's what it actually does just
for struct timespec, seems to me like it may be a misfeature of GNU
autoconf.

-- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F

> From: Keith Marshall <kei...@us...>
> Date: Sun, 11 Oct 2015 17:56:36 +0100
> 
> On 11/10/15 16:11, Eli Zaretskii wrote:
> > My personal solution is (assuming you don't really need pthreads in
> > that project) to rename the pthreads headers, so they "don't exist" as
> > far as the configuration scripts are concerned.
> 
> A reasonable approach, but kind of begs the question ... if the project
> doesn't need pthreads, why would its configuration script(s) check for
> <pthread.h>?

Because the standard GNU configure tests "know" this is one place
where 'struct timespec' is declared.

> (Unless, of course, it can use pthreads if supported, or some
> alternative fall-back otherwise ... in which case lack of any such
> alternative support could be something of a show-stopper).

No, most such packages don't use pthreads (or any threads), they just
need the struct declaration.

On 11/10/15 16:11, Eli Zaretskii wrote:
> My personal solution is (assuming you don't really need pthreads in
> that project) to rename the pthreads headers, so they "don't exist" as
> far as the configuration scripts are concerned.

A reasonable approach, but kind of begs the question ... if the project
doesn't need pthreads, why would its configuration script(s) check for
<pthread.h>?  (Unless, of course, it can use pthreads if supported, or
some alternative fall-back otherwise ... in which case lack of any such
alternative support could be something of a show-stopper).

-- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F

On 11/10/15 16:13, Gisle Vanem wrote:
> Keith Marshall wrote:
> 
>> If you neglect that discrepancy, and your application calls any of the
>> pthreads-win32 functions which require a struct timespec * parameter,
>> then your application will exhibit undefined behaviour.
> 
> Look in PtW32 sources who this struct is used. Specifically how '*abstime'
> is filled (I have v2.9.1 here). So since 'tv_sec' there is 32-bit, Pthread
> programs could have problems in the year 2036. I assume you have fixed
> PtW32 till then :-)

You appear to be missing the point, (actually several related points),
entirely:--

1) HAVE_STRUCT_TIMESPEC is a configuration time macro; it has no
   business appearing in any installed header, such as <pthread.h>
   which might be considered as a system header, (or otherwise).

2) At libpthread.a build time, HAVE_STRUCT_TIMESPEC is undefined,
   by default, for a mingw32 target build; there is no configure
   time discovery, to automatically correct this anomaly.

3) If a user installs pthreads-win32 from an on-line resource, in
   preference to building it themselves, then it's likely that the
   library will have an inbuilt assumption that tv_sec is 32-bit.

4) When this same user builds a client application, and works around
   the HAVE_STRUCT_TIMESPEC issue, by forcibly defining it, then the
   user's client application will, (if using mingwrt-3.21.1 or later),
   construct timespec structures with 64-bit tv_sec; if these are
   then passed by reference, to any libpthread.a function, then the
   tv_sec and tv_nsec values may be misinterpreted within the library
   code; the outcome is unpredictable, and hence undefined.

5) That <pthread.h> defines struct timespec itself is a violation of
   POSIX.1.  It should be defined in <sched.h>, (which then makes it
   indirectly visible, when <pthread.h> is included).  However, the
   POSIX.1 requirement for <sched.h> is that it shall define struct
   timespec *exactly* as it is defined by <time.h> ... admittedly a
   thorny issue for a windows implementation, where the platform
   vendor doesn't define this structure in *any* header, AFAIK.  In
   this case, the pthreads-win32 implementation really shouldn't
   implement any function which refers to struct timespec, *unless*
   configuration time discovery shows it to be defined in a third
   party header (for exclusive use with a third party compiler suite)
   such as MinGW.org's.

-- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F

Keith Marshall wrote:

> If you neglect that discrepancy, and your application calls any of the
> pthreads-win32 functions which require a struct timespec * parameter,
> then your application will exhibit undefined behaviour.

Look in PtW32 sources who this struct is used. Specifically how '*abstime'
is filled (I have v2.9.1 here). So since 'tv_sec' there is 32-bit, Pthread
programs could have problems in the year 2036. I assume you have fixed
PtW32 till then :-)

-- 
--gv

> From: G <op...@ho...>
> Date: Sun, 11 Oct 2015 08:24:25 +0000
> 
> 1 c:\mingw\include\parts\time.h:65:8: error: redefinition of 'struct timespec' 
> 
> 2 c:\mingw\include\pthread.h:320:8: error: previous definition of 'struct
> timespec'

A misfeature of the ported pthreads, I agree with Keith.

My personal solution is (assuming you don't really need pthreads in
that project) to rename the pthreads headers, so they "don't exist" as
far as the configuration scripts are concerned.

On 11/10/15 10:50, Gisle Vanem wrote:
> G wrote:
> 
>> 1 c:\mingw\include\parts\time.h:65:8: error: redefinition of 'struct timespec'
>>
>>
>> 2 c:\mingw\include\pthread.h:320:8: error: previous definition of 'struct timespec'
>>
>>
>> I have seen that this is an error already referenced in postings on
>> stackoverflow and elsewhere ...

Be careful with advice posted on StackOverflow ... it's often posted by
reputation seekers with absolutely no knowledge or experience of the
actual platform in question, so best treated with grave suspicion.

>> but I don't really know what the solution would be, without making
>> changes in my source code files.

This results from a misfeature of upstream pthreads-win32 -- it makes no
inherent allowance for the possibility that the compiler suite, (on
which it depends), may add its own definition of struct timespec, as we
have done in mingwrt-3.21.1.

> Easy. Add '-DHAVE_STRUCT_TIMESPEC' to your CFLAGS.

Be careful if you adopt this apparently simple "solution"; unless you
also rebuild the pthreads-win32 libraries, with identically the same
addition to CFLAGS, you will have an incompatibility between the
understanding of struct timespec within libpthread.a, (and its
derivatives), ... effectively:

  struct timespec
  {
    __time32_t  tv_sec;
    __int32     tv_nsec;
  };

and the implementation within mingwrt-3.21.1 ... effectively (required
to accommodate the brain damage of MSVCR80.DLL and later):

  struct timespec
  {
    __time64_t tv_sec;
    __int32    tv_nsec;
  };

If you neglect that discrepancy, and your application calls any of the
pthreads-win32 functions which require a struct timespec * parameter,
then your application will exhibit undefined behaviour.

FWIW, I've been exploring various issues within the pthreads-win32
implementation, over the past week or so.  The upstream project conveys
a strong impression of abandonment, so we may wish to adopt and fork it,
but before I do that, and after I've developed a better understanding of
the issues, I will attempt to contact the maintainer of the original
project, and I may then wish to discuss the subject further, here.

-- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F

G wrote:

> 1 c:\mingw\include\parts\time.h:65:8: error: redefinition of 'struct timespec'
>
>
> 2 c:\mingw\include\pthread.h:320:8: error: previous definition of 'struct timespec'
>
>
> I have seen that this is an error already referenced in postings on stackoverflow and elsewhere but I don't really know
> what the solution would be, without making changes in my source code files.

Easy. Add '-DHAVE_STRUCT_TIMESPEC' to your CFLAGS.


-- 
--gv

Hi,

I'm using the latest MinGW in Windows 7/32 bit, and my development environment is Eclipse Kepler.

I have two portable C/C++ projects that seamlessly build&run the SAME code on Visual Studio 2010 and Eclipse Kepler/Linux 12.04.

One of the projects builds&runs with no error also in Eclipse with MinGW toolchain in Windows.

But another project, created on the same architecture gives me the following errors at build wih Eclipse+MinGW:

1    c:\mingw\include\parts\time.h:65:8: error: redefinition of 'struct timespec'


2    c:\mingw\include\pthread.h:320:8: error: previous definition of 'struct timespec'


I have seen that this is an error already referenced in postings on stackoverflow and elsewhere but I don't really know what the solution would be, without making changes in my source code files. Am I doing a MinGW configuration error?

I appreciate your help.

>From: G 
>Subject: [Mingw-users] MinGW in Eclipse: 'Build Project' has encountered a problem

<snip>

>Errors occurred during the build.
>Errors running builder 'CDT Builder' on project 'openPROJECT'.
>Internal error building projectopenPROJECT configuration Default
>java.lang.NullPointerException
>Internal error building project openPROJECT configuration Default
>java.lang.NullPointerException

>I don't know if this is related to the configuration of MinGW but it happens only when I use this toolchain.
>Thanks for help!

I don't use Eclipse for C/C++ development, so I am no expert on CDT, but it appears that
CDT builder tried to do something that didn't work. The Java messages seem to come 
from the Eclipse tools and do not indicate a need for any MinGW Java.  Is there any kind of
trace log that CDT Builder produces, or can produce if turned on? Knowing exactly what it
was doing when it crashed is the key to understanding the failure.

My 2c: If you need Java to build this, I don't think it will work, as gcc
java has been broke for a while; the windows' Java will not be compatible.

On Thu, Oct 8, 2015 at 2:59 AM, G <op...@ho...> wrote:

> Hi guys,
>
> I have installed the currently available MinGW with the following Basic
> Setup packages:
>
> - mingw-developer-toolkit
>
> - mingw32-base
>
> - mingw32-gcc-g++
>
> - msys-base
>
> I have created a "MakeFile project from existing code" project in Eclipse
> Kepler/Windows 7/32 bit.
>
> This project's same code builds and runs perfectly both in Visual Studio
> 2010 (VC++) and in Eclipse (gcc and g++) on Linux Ubuntu 12.04; it uses
> conditional compiling in the headers, for Windows, Linux and Mac.
>
> In Eclipse, when I hit Build project with the MinGW toolchain it gives me
> no messages in the Console and Errors perspectives, but I get a pop-up
> window with the message in subject.
>
> When I click on the Details button of this pop-up window I have this:
>
>
> Errors occurred during the build.
> Errors running builder 'CDT Builder' on project 'openPROJECT'.
> Internal error building projectopenPROJECT configuration Default
> java.lang.NullPointerException
> Internal error building project openPROJECT configuration Default
> java.lang.NullPointerException
>
> I don't know if this is related to the configuration of MinGW but it
> happens only when I use this toolchain.
>
> Thanks for help!
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list
> etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:min...@li...?subject=unsubscribe
>

Hi guys,

I have installed the currently available MinGW with the following Basic Setup packages:

- mingw-developer-toolkit

- mingw32-base

- mingw32-gcc-g++

- msys-base

I have created a "MakeFile project from existing code" project in Eclipse Kepler/Windows 7/32 bit.

This project's same code builds and runs perfectly both in Visual Studio 2010 (VC++) and in Eclipse (gcc and g++) on Linux Ubuntu 12.04; it uses conditional compiling in the headers, for Windows, Linux and Mac.

In Eclipse, when I hit Build project with the MinGW toolchain it gives me no messages in the Console and Errors perspectives, but I get a pop-up window with the message in subject.

When I click on the Details button of this pop-up window I have this:


Errors occurred during the build.
Errors running builder 'CDT Builder' on project 'openPROJECT'.
Internal error building projectopenPROJECT configuration Default
java.lang.NullPointerException
Internal error building project openPROJECT configuration Default
java.lang.NullPointerException


I don't know if this is related to the configuration of MinGW but it happens only when I use this toolchain.

Thanks for help!