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

>> In w32api-4.0.3-1, TV_DISPINFO still seems to be defined as
>> __AW(NMTVDISPINFO), and as a result, wxWidgets still does not
>> compile. (And people are recommending using MinGW-w64 instead
>> as a solution [1].)
>
> In the stackoverflow-link we can see 'NMTVDISPINFOWW' (notice the two 'W')
> There's a problem (I don't know where) of a double use of __AW() macro.

The problem is on the line immediately below:

  #define TV_DISPINFO __AW(NMTVDISPINFO)
  #define NMTVDISPINFO __AW(NMTVDISPINFO)

Perhaps the correct solution is to omit the second line.

Either way, the point is, this is a bug in the MinGW headers that's
preventing the compilation of a major open-source C++ project, and
it really should be fixed.

Regards,
Nate
 		 	   		  

El 31/05/14 08:02, Nathan Ridge escribió:

> In w32api-4.0.3-1, TV_DISPINFO still seems to be defined as
> __AW(NMTVDISPINFO), and as a result, wxWidgets still does not
> compile. (And people are recommending using MinGW-w64 instead
> as a solution [1].)

In the stackoverflow-link we can see 'NMTVDISPINFOWW' (notice the two 'W')
There's a problem (I don't know where) of a double use of __AW() macro.

Regards,
Manolo

>>> If you edit line 2217 of /mingw/include/commctrl.h to read
>>>
>>> #define TV_DISPINFO NMTVDISPINFO
>>>
>>> instead of
>>>
>>> #define TV_DISPINFO __AW(NMTVDISPINFO)
>>>
>>> Does it help?
>>>
>>
>> That fixed it. Thanks. Do you want me to file a bug report against
>> this? I wonder if there are any other definitions that use the __AW()
>> macro that also suffer from this problem.
>
> I'll open the report. There maybe others, especially if they are
> similar to this one. I long for a good testing system for each
> element. Even an external build bot that runs a testing sequence and
> creates an online report. Dreaming ...

What is the status of this?

In w32api-4.0.3-1, TV_DISPINFO still seems to be defined as
__AW(NMTVDISPINFO), and as a result, wxWidgets still does not
compile. (And people are recommending using MinGW-w64 instead
as a solution [1].)

Thanks,
Nate

[1] http://stackoverflow.com/questions/19476533/error-while-compiling-wxwidgets-2-8-12-on-mingw-with-gcc-4-8-1
 		 	   		  

On 2014-05-27 04:18, KHMan wrote:
> I mean that users of FLOSS should not expect some kind of 
> customer-supplier relationship. Well sure, many a time it works 
> great when the community solves problems for people, but sometimes 
> people begin to take that for granted.

OK, I See that point _IF_ the project is not sufficiently organized to
provide that relationship... but it seems like an opportunity rather
than an obstacle:

If resources are scarce and folks using the product want support then
there is a natural opportunity for trade there... and as is done with
many successful free/open projects, such a customer should be able to
purchase a support subscription or per-ticket support to drive the
project forward. It's a pretty successful model.

Maybe it's time to put something like that together here.

Reach up to a higher level of service instead of down to lower expectations.

_M

-- 
Pete McNeil, President
MicroNeil Research Corporation
www.microneil.com
703.779.4909 x7010
twitter/codedweller

On 5/27/2014 1:13 AM, Alan W. Irwin wrote:
> On 2014-05-26 09:22-0400 Pete McNeil wrote:
>
>> On 2014-05-25 23:00, KHMan wrote:
>>> It's just that certain users need an adjustment. They can't expect
>>> Free Software/Open Source projects to run spiffily like actual
>>> products.
>>
>> I usually just lurk here unless I can help somebody. But this hit one of
>> my buttons.
>>
>> There is no reason our expectations of free/open software should be any
>> less than our expectations of "actual" products. [...]
>
> Well said.

Heh heh, look, I guess I put it in too few words. I simply did not 
want to write long postings.

I mean that users of FLOSS should not expect some kind of 
customer-supplier relationship. Well sure, many a time it works 
great when the community solves problems for people, but sometimes 
people begin to take that for granted. Resources is scarce, we are 
a community, we are not customers of the project to be pampered to 
some expectation of some kind of service level.

Tell 'em to de newbies, we canna take the best produce from de 
farm and do nothing for de land. We gotta fertilize the land, care 
and nuture the soil. When you see them nice produce in the 
supermarkets, well it took effort to grow 'em nice for you.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

On 2014-05-26 09:22-0400 Pete McNeil wrote:

> On 2014-05-25 23:00, KHMan wrote:
>> It's just that certain users need an adjustment. They can't expect
>> Free Software/Open Source projects to run spiffily like actual
>> products.
>
> I usually just lurk here unless I can help somebody. But this hit one of
> my buttons.
>
> There is no reason our expectations of free/open software should be any
> less than our expectations of "actual" products. [...]

Well said.

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
__________________________

On 2014-05-25 23:00, KHMan wrote:
> It's just that certain users need an adjustment. They can't expect 
> Free Software/Open Source projects to run spiffily like actual 
> products.

I usually just lurk here unless I can help somebody. But this hit one of
my buttons.

There is no reason our expectations of free/open software should be any
less than our expectations of "actual" products. I think exactly the
opposite. Presuming by "actual" you mean profit driven commercial
products, I think we should expect free/open software to drive toward
the highest standards and achieve them.

"Actual" products have a lot of axes to grind that have nothing whatever
to do with a high quality user experience and high quality software
engineering. Free/Open products don't have those obstacles.

The financial resources available to "actual" products may be greater
than those available to free/open software but the folks maintaining
free/open software are doing it for better reasons and should be keen to
achieve _better_ results.

The financial resources available to free/open projects don't have to be
less than those for "actual" products either -- there are ways around
that too - especially if specific goals are desired by the community
supporting them. Not only that, but without the distracting pressures
and problems associated with building "actual" products the resources
that are available to free/open projects can be more efficiently
allocated and better targeted.

So, _please_ don't suffer with the expectation that free/open software
should somehow be weaker, shabbier, or less-than commercial or "actual"
software... and by all means AVOID spreading that kind of FUD and
self-defeating misinformation. There is no good reason to believe it and
every reason we shouldn't settle for it.

Take that energy and point it toward focusing on the solution... if
there is something here that needs to be better (and there always is)
then get to work on a solution and encourage those who do focus there to
do their best work.

_M


-- 
Pete McNeil, President
MicroNeil Research Corporation
www.microneil.com
703.779.4909 x7010
twitter/codedweller

On 26/05/14 07:51, Rashad M wrote:
> I dont understand why dllexport/dllimport macro is not required to build
> dll which are linked with a dll having classes properly exported?

It works on a per DLL basis; each has its own exports table.  When you
build any DLL with MinGW tools, if no symbol added bears the dllexport
attribute, then *all* symbols added will be exported, by default.  As
soon as you add just one symbol qualified with this attribute, (either
explicitly, or by .def file inference), then only symbols so qualified
will be included in the exports table, (unless you build with the
--export-all-symbols option).

> Is it by design or am I missing something very important. Could anyone
> explain this to me.?

It is by design; see the description for --export-all-symbols, in the ld
documentation.

-- 
Regards,
Keith.

Hello,

I build a library say A with mingw  and then another library B which
depends on libA. Now libA has been sucessful in building with mingw. It has
proper dllexport and dllimport symbols defined. and class uses it

class EXPORT_OF_A classOfA {

};

so far so good.

Now when building libB with same mingw toolchain. I dont need to use EXPORT
defines. This seems to me a bit strange. I could build my dll linked with
libA and no issue. But when building an exe on top of dlls from libB I want
to proper export. This part seems fair.

I dont understand why dllexport/dllimport macro is not required to build
dll which are linked with a dll having classes properly exported?

Is it by design or am I missing something very important. Could anyone
explain this to me.?

So far I had read:
http://www.transmissionzero.co.uk/computing/building-dlls-with-mingw/
http://mingw.5.n7.nabble.com/More-fun-w-dllexport-and-dllimport-td11559.html
http://stackoverflow.com/questions/2810118/how-to-tell-the-mingw-linker-not-to-export-all-symbols

-- 
Regards,
   Rashad

On 5/26/2014 2:53 AM, Erwin Waterlander wrote:
> Op 24-5-2014 21:45 Earnie Boyd schreef:
>> If there was as much time spent on producing patches for MinGW.org as
>> there is in speculative rumor and assumption the project would be
>> further along with its own 64bit compliant headers.
>>
>> The fact is Kai did not produce a patch, he produced a replacement and
>> we pushed back asking for patches.  He decided to take it up with the
>> company he works for and that company's lawyers blessed it; so Kai
>> started a new project.  I refuse to speculate one way or another as to
>> infringement or not; I don't have the time to look but because his
>> company's lawyers saw nothing and because Redhat's lawyers with Cygwin
>> blessed it then my assumption would be that they are copesetic with
>> regard to copyright goodness.
>>
>> I am not saying Kai was correct in his decision to fork but he had the
>> right to do so and I will not throw mud or hold hostility toward him
>> for it.  Let us consider the subject closed and move MinGW.org toward
>> a more complete product.
>
> Isn't that one of the blessings of open source? That everybody can take
> the source and fork it.
> Only being f[ou][rc]ked doesn't feel so nice...

Let's not continue with your "being forked doesn't feel so nice" 
theme. Until this latest thread, each project has been minding 
their own business peacefully for a long time.

I thought this thread started more along the lines of the idea 
that every version of MinGW must run smoothly across all versions 
for all API calls some user needs, hence the source code sharing 
discussion.

It's just that certain users need an adjustment. They can't expect 
Free Software/Open Source projects to run spiffily like actual 
products. I think most of the old timers on the list would not be 
so demanding with their opinion of how things should be done or 
how compilers should work.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

Op 24-5-2014 21:45 Earnie Boyd schreef:
> If there was as much time spent on producing patches for MinGW.org as
> there is in speculative rumor and assumption the project would be
> further along with its own 64bit compliant headers.
>
> The fact is Kai did not produce a patch, he produced a replacement and
> we pushed back asking for patches.  He decided to take it up with the
> company he works for and that company's lawyers blessed it; so Kai
> started a new project.  I refuse to speculate one way or another as to
> infringement or not; I don't have the time to look but because his
> company's lawyers saw nothing and because Redhat's lawyers with Cygwin
> blessed it then my assumption would be that they are copesetic with
> regard to copyright goodness.
>
> I am not saying Kai was correct in his decision to fork but he had the
> right to do so and I will not throw mud or hold hostility toward him
> for it.  Let us consider the subject closed and move MinGW.org toward
> a more complete product.
>

Isn't that one of the blessings of open source? That everybody can take 
the source and fork it.
Only being f[ou][rc]ked doesn't feel so nice...

regards,

-- 
Erwin

If there was as much time spent on producing patches for MinGW.org as
there is in speculative rumor and assumption the project would be
further along with its own 64bit compliant headers.

The fact is Kai did not produce a patch, he produced a replacement and
we pushed back asking for patches.  He decided to take it up with the
company he works for and that company's lawyers blessed it; so Kai
started a new project.  I refuse to speculate one way or another as to
infringement or not; I don't have the time to look but because his
company's lawyers saw nothing and because Redhat's lawyers with Cygwin
blessed it then my assumption would be that they are copesetic with
regard to copyright goodness.

I am not saying Kai was correct in his decision to fork but he had the
right to do so and I will not throw mud or hold hostility toward him
for it.  Let us consider the subject closed and move MinGW.org toward
a more complete product.

Regards,
Earnie

Changes:

New upstream release.
   * Dos2unix is part of the Translation Project (TP).
     All translations go via the Translation Project.
     See http://translationproject.org/
   * New translations of UI messages: Brazilian Portuguese, Chinese 
(traditional),
     Danish, French, Hungarian, Polish, Serbian, Ukrainian, Vietnamese.
   * New translations of the manual: Brazilian Portuguese, French, 
German,
     Polish, Ukrainian.
   * Generated man pages are included in the source package to prevent
     compilation problems with very old or very new perl/pod2man 
versions.
   * Manuals are now generated from gettext PO files with po4a for easier
     translation.
   * All manuals are now in UTF-8 encoding.
   * Skip symbolic links on Windows by default (same as on Unix).


homepage: http://waterlan.home.xs4all.nl/dos2unix.html
license: 2-clause BSD (FreeBSD)

-- 
Erwin Waterlander

---------- Forwarded message ----------
From: Андрей Парамонов <cmr...@gm...>
Date: 2014-05-19 12:57 GMT+04:00
Subject: Linking to HDF5 library
To: min...@li...


Hello!

I'm writing a minimal demonstration program (that shows how to use my
HDF5-based data format). The program is really simple:

#include "hdf5.h"

int main()
{
  hid_t file_id;
  hid_t dataset_id;
  hid_t attribute_id;
  hid_t space_id;
  hssize_t nscans, npeaks;
  double minmz, maxmz;

  printf("Opening MS.abf ... ");
  file_id = H5Fopen("MS.abf", H5F_ACC_RDONLY, H5P_DEFAULT);
  if(file_id > 0)
    printf("done.\n");
  else{
    printf("error!\n");
    return 1;
  };

  dataset_id = H5Dopen(file_id, "rettime", H5P_DEFAULT);
  space_id = H5Dget_space(dataset_id);
  nscans = H5Sget_simple_extent_npoints(space_id);
  printf("Total scans: %lld.\n", nscans);
  H5Sclose(space_id);
  H5Dclose(dataset_id);

  dataset_id = H5Dopen(file_id, "specdata/mz", H5P_DEFAULT);
  space_id = H5Dget_space(dataset_id);
  npeaks = H5Sget_simple_extent_npoints(space_id);
  printf("Total MS peaks: %lld.\n", npeaks);
  H5Sclose(space_id);

  attribute_id = H5Aopen(dataset_id, "min", H5P_DEFAULT);
  H5Aread(attribute_id, H5T_NATIVE_DOUBLE, &minmz);
  H5Sclose(attribute_id);
  attribute_id = H5Aopen(dataset_id, "max", H5P_DEFAULT);
  H5Aread(attribute_id, H5T_NATIVE_DOUBLE, &maxmz);
  H5Sclose(attribute_id);
  printf("M/z range: %f..%f.\n", minmz, maxmz);

  H5Dclose(dataset_id);

  H5Fclose(file_id);

  return;
}

What I want to do it to make sure that users (most of which are on w32) can
compile and run the program as easily as possible. So, I don't want to
resort to heavy artillery such as cmake or even makefiles. I believe for
such a trivial program a simple gcc call should be enough.

I do not care much whether I link to *.lib file of *.dll file (however the
latter seems easier to me -- but I'm no C specialist). It seems that *.h
files along with *.dll file should be enough to provide the compiler and
linker all needed information.

I'm running

>gcc test.c -I"C:\Progra~2\HDF_Group\HDF5\1.8.12\include"
-L"C:\Progra~2\HDF_Group\HDF5\1.8.12\lib" -lhdf5 -otest.exe

where C:\Progra~2\HDF_Group\HDF5\1.8.12 is obtained from

http://www.hdfgroup.org/ftp/HDF5/releases/hdf5-1.8.12/bin/windows/hdf5-1.8.12-win32-vs10shared.zip

but I get

C:\Users\paramon\AppData\Local\Temp\ccqrZOee.o:test.c:(.text+0x177):
undefined reference to `H5T_NATIVE_DOUBLE_g'
C:\Users\paramon\AppData\Local\Temp\ccqrZOee.o:test.c:(.text+0x1c5):
undefined reference to `H5T_NATIVE_DOUBLE_g'
c:*/mingw/bin/*../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe:
C:\Users\paramon\AppData\Local\Temp\ccqrZOee.o: bad reloc address 0x20 in
section `.eh_frame'
c:*/mingw/bin/*../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe:
final link failed: Invalid operation
collect2.exe: error: ld returned 1 exit status

It seems that linker cannot find H5T_NATIVE_DOUBLE_g. However, it *is* in
hdf5.dll: I can see it in Dependency Walker, and in fact I can use
H5T_NATIVE_DOUBLE_g from Delphi (Pascal dialect) code.

Without H5T_NATIVE_DOUBLE -related lines, everything compiles and runs file.

What am I missing?

Best wishes,
Andrey Paramonov

Thanx for the the true helpfullness.
The installer I have used and it worked find in obscurity,
however when jobb done things still didnt work, it had overlaid
files of the previous 2.8 installation without any hint of what it had been 
doing.
There is no knowing of what files were there before and have been 
substituted,
and indeed why it fails internally when linking the Vector package.
I prefer to be incontrol even if it takes some more time.

Br georg
----- Original Message ----- 
From: "Keith Marshall" <kei...@us...>
To: "MinGW Users List" <min...@li...>
Sent: Thursday, May 15, 2014 9:24 PM
Subject: Re: [Mingw-users] gcc installation


> On 15/05/14 19:33, georg chambert wrote:
>> still, I find it troublesome that development goes backwards as to
>> usability,
>
> And your definition of "usability" comes down to a prehistoric version
> of GCC, no longer maintained, nor even maintainable.
>
>> I have still not after months of attempts successfully gotten a new
>> gcc installed, while previous version 2.8 took me 2 days.
>
> You think 2 days is good?  Incredible!  Thankfully, the majority of
> users are less befuddled by Microsoft brainwashing.
>
> Using the current mingw-get installer, I can install a full system in
> around 30 minutes.  Yes, that needs an on-line install, but you need
> on-line connectivity to download packages for any installation -- if you
> want it off-line, direct that initial installation to removable media,
> and, as John E. has already suggested, you can clone it to as many
> off-line machines as you like.
>
> -- 
> Regards,
> Keith.
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform 
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> 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 

On 15/05/14 19:33, georg chambert wrote:
> still, I find it troublesome that development goes backwards as to
> usability,

And your definition of "usability" comes down to a prehistoric version
of GCC, no longer maintained, nor even maintainable.

> I have still not after months of attempts successfully gotten a new
> gcc installed, while previous version 2.8 took me 2 days.

You think 2 days is good?  Incredible!  Thankfully, the majority of
users are less befuddled by Microsoft brainwashing.

Using the current mingw-get installer, I can install a full system in
around 30 minutes.  Yes, that needs an on-line install, but you need
on-line connectivity to download packages for any installation -- if you
want it off-line, direct that initial installation to removable media,
and, as John E. has already suggested, you can clone it to as many
off-line machines as you like.

-- 
Regards,
Keith.

Hi, 

still, I find it troublesome that development goes backwards as to usability,

I have still not after months of attempts successfully gotten a new gcc installed, while previous version 2.8 took me 2 days.
why

Is there by chance a list of the filestructure 
that give a sample of the files needed as a basic set to get a gcc compiler for C,C++ and Ada running (and with the libstdc++ 
which access to is the root of all this trouble, I just need to get that lib working for reference from the application Im so long delayed in compiling&linking)

many Tnx 
for possible help
Georg



  ----- Original Message ----- 
  From: John E. / TDM 
  To: min...@li... 
  Sent: Saturday, May 10, 2014 5:44 PM
  Subject: Re: [Mingw-users] gcc installation


  On 5/10/2014 9:25 AM, georg chambert wrote:

    HELP, is there anywhere where I can get a (binary) full installation, and self installing, on ONE FILE ?

  Hi Georg,

  The MinGW project does not currently offer an all-in-one installer, instead opting for the online version to minimize users' total bandwidth utilization during the download process.

  However, if you run the installation process on a networked machine, it will be safe for you to then copy the contents of the MinGW installation (starting at the root folder that you choose during installation) to a non-networked machine, to obtain a working MinGW installation there.

  Alternatively (and I stress that this is not in any way supported by the MinGW project), you may consider TDM-GCC[1], which offers a GCC toolchain based on MinGW with some patches for Windows-friendliness.

  -John E. / TDM

  [1] - <http://tdm-gcc.tdragon.net>



------------------------------------------------------------------------------


  ------------------------------------------------------------------------------
  Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
  &#149; 3 signs your SCM is hindering your productivity
  &#149; Requirements for releasing software faster
  &#149; Expert tips and advice for migrating your SCM now
  http://p.sf.net/sfu/perforce


------------------------------------------------------------------------------


  _______________________________________________
  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

That should be ok, Im looking for something newer than 2.8 (which has suited me fine until now, missing the libstdc++ library, and unable to get it into my 2.8, its said to be
internal in the later installations)

Tnx will try
Georg
  ----- Original Message ----- 
  From: Sergio NNX 
  To: geo...@te... 
  Sent: Saturday, May 10, 2014 5:34 PM
  Subject: MinGW Standalone installer


  > HELP, is there anywhere where I can get a (binary) full installation, and self installing, on ONE FILE ?

  I'm aware of one standalone/offline installer, but it's GCC 4.7.2. Is that ok?

  Cheers.

  Ser.

On 5/10/2014 9:25 AM, georg chambert wrote:
> HELP, is there anywhere where I can get a (binary) full installation, 
> and self installing, on ONE FILE ?

Hi Georg,

The MinGW project does not currently offer an all-in-one installer, 
instead opting for the online version to minimize users' total bandwidth 
utilization during the download process.

However, if you run the installation process on a networked machine, it 
will be safe for you to then copy the contents of the MinGW installation 
(starting at the root folder that you choose during installation) to a 
non-networked machine, to obtain a working MinGW installation there.

Alternatively (and I stress that this is not in any way supported by the 
MinGW project), you may consider TDM-GCC[1], which offers a GCC 
toolchain based on MinGW with some patches for Windows-friendliness.

-John E. / TDM

[1] - <http://tdm-gcc.tdragon.net>

I want to do what I have done before; download a MinGw full package with installer to my XP.

NOW; developments seem to go from good to bad

I can not find one / A file to download which does this task for me (am I right ?? hope not),  as was previously possible 

NOW it seems that Im to download a loader, which will in turn download, of cause over the net, which I dont want, because I want to make
the installation on a non networkable machine.

HELP, is there anywhere where I can get a (binary) full installation, and self installing, on ONE FILE ?

BR & tnx
Georg

> Date: Thu, 8 May 2014 13:20:44 -0700
> From: Greg Jung <gv...@gm...>
> 
> Binary incompatibility notice!
> ------------------------------
> 
> The C and C++ ABI changed in GCC 4.7.0, which means in general you can't
> link together binaries compiled with this version of the compiler and with
> versions before GCC 4.7.0. In particular:
> 
> * The option -mms-bitfields is enabled by default, which means the bitfield
> layout
> follows the convention of the Microsoft compiler.
> 
> * C++ class-member functions now follow the __thiscall calling convention.
> 
> * The compiler now assumes that the caller pops the stack for the implicit
> arguments pointing to an aggregate return value. This affects functions
> returning structs by value, like the complex math type.
> 
> New features:
> -------------
> 
> See http://gcc.gnu.org/gcc-4.7/changes.html
> 
> ===========================
>    Evidently, to build a package using gcc4.7 or better you need all
> (XXX.dll, XXX.a, XXX.o), and any included for dependencies, to be compiled
> with version > 4.7 or you might get random troubles.
> 
> Even if this were easy, it is quite disruptive.  However the GCC version
> information is not embedded in most binaries
> so how can it even be implemented properly?

Are you talking about the first issue or about the second issue?

For the first one, which affects both C and C++ programs, I had these
concerns when 4.7 was released, but have since found this to be not a
problem.  I'm happily using DLLs compiled by GCC < 4.7 with programs
compiled by 4.7.23, and vice versa, with no problems at all.

As for the second issue, the one that only affects C++ programs, I
don't know.  Maybe someone else will chime in.  However, in general,
C++ programs should be built by the same compiler from the ground up,
AFAIK.

On Thu, May 8, 2014 at 11:46 PM, Jay Kay <gam...@gm...> wrote:
> I've got a very peculiar problem with MinGW (Windows 7 64-bit).  This
> doesn't always happen 100% of the time, but when I attempt to compile,
> it often makes the executable, stalls for a few seconds, and then
> deletes the executable.

This is embarrassing.  It was my antivirus.  I hate everything.

Hi,

I sincerely apologise in advance for the length of this, but it's so
intermittent and finicky that I wanted to supply as much information
as I possibly could.

I've got a very peculiar problem with MinGW (Windows 7 64-bit).  This
doesn't always happen 100% of the time, but when I attempt to compile,
it often makes the executable, stalls for a few seconds, and then
deletes the executable.  My command prompt shows the following
information:

> C:\Users\Jay\Documents\C_Projects>make ex1
> cc -Wall -g    ex1.c   -o ex1
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  ex1.c
>
> C:\Users\Jay\Documents\C_Projects>cat Makefile
> CFLAGS=-Wall -g
>
> clean:
>         rm -f ex1
>
> C:\Users\Jay\Documents\C_Projects>cc ex1.c
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  ex1.c
>
> C:\Users\Jay\Documents\C_Projects>gcc ex1.c
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  ex1.c
>
> C:\Users\Jay\Documents\C_Projects>cc --version
> cc (GCC) 4.8.1
> Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> C:\Users\Jay\Documents\C_Projects>gcc --version
> gcc (GCC) 4.8.1
> Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Note that in Windows Explorer, I can see ex1.exe being created (an
87.9KB file, so it is indeed writing something) and then being
destroyed.  When I first found this problem a few days ago I thought I
tracked it down to the -g flag.  Upon removal of that flag, I could
compile fine for a little while.  It came back later, so I tried
playing with the flags again to no avail.  After commenting my entire
Makefile and running it again with no luck, I removed the comments
again and it began to work again.  Some time later it came back again
with the other tricks not working, so I deleted Makefile, ran it again
(and it worked), remade Makefile, and it worked again.  This time,
nothing I do is fixing the issue.  I have even tried removing and
reinstalling the compilers, and also have tried using 4.8.2 with the
same results.  I should also note that this issue has popped up
randomly; I would compile, make a small change in the source, attempt
to recompile, and be faced with this issue.  Cygwin GCC 4.8.2 does not
seem to have this issue.

The source of ex1.c, by the way, is:

> #include <stdio.h>
>
> int main(int argc, char *argv[])
> {
>     printf("blah!\n");
>     return 0;
> }

If any other information is needed, please tell me.  Thanks in
advanced for any insight or suggestions.


All right, so before sending this mail out, I did some more testing.
I changed Makefile, fixing my "all" line to "all: ex1", but testing
had no success.  Some time later I tried the following:

ex1.c is now a more complex source.

> C:\Users\Jay\Documents\C_Projects>g++ ex1.c
> ex1.c: In function 'int main(int, char**)':
> ex1.c:10:2: warning: deprecated conversion from string constant to 'char*' [-Wwr
> ite-strings]
>   };
>   ^
> ex1.c:10:2: warning: deprecated conversion from string constant to 'char*' [-Wwr
> ite-strings]
> ex1.c:10:2: warning: deprecated conversion from string constant to 'char*' [-Wwr
> ite-strings]
> ex1.c:10:2: warning: deprecated conversion from string constant to 'char*' [-Wwr
> ite-strings]
> ex1.c:10:2: warning: deprecated conversion from string constant to 'char*' [-Wwr
> ite-strings]
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  ex1.c
>
> C:\Users\Jay\Documents\C_Projects>g++ --version
> g++ (GCC) 4.8.1
> Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ex1.c is now the shorter source again.

> C:\Users\Jay\Documents\C_Projects>g++ ex1.c
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  ex1.c
>
> C:\Users\Jay\Documents\C_Projects>make ex1
> cc -Wall -g ex1.c -o ex1
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  ex1.c
>
> C:\Users\Jay\Documents\C_Projects>rm a
>
> C:\Users\Jay\Documents\C_Projects>make
> cc -Wall -g ex1.c -o ex1
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  ex1.c
>
> C:\Users\Jay\Documents\C_Projects>cc ex1.c
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  ex1.c
>
> C:\Users\Jay\Documents\C_Projects>rm a
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  ex1.c
>
> C:\Users\Jay\Documents\C_Projects>gcc ex1.c
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  ex1.c
>
> C:\Users\Jay\Documents\C_Projects>gcc ex1.c -o asdf
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  asdf.exe  ex1.c
>
> C:\Users\Jay\Documents\C_Projects>make
> cc -Wall -g ex1.c -o ex1
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  asdf.exe  ex1.c
>
> C:\Users\Jay\Documents\C_Projects>rm asdf
>
> C:\Users\Jay\Documents\C_Projects>cc ex1.c -o asdf
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  asdf.exe  ex1.c
>
> C:\Users\Jay\Documents\C_Projects>make
> cc -Wall -g ex1.c -o ex1
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  asdf.exe  ex1.c
>
> C:\Users\Jay\Documents\C_Projects>cc -Wall -g ex1.c -o foobar
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  asdf.exe  ex1.c
>
> C:\Users\Jay\Documents\C_Projects>cc -Wall ex1.c -o foobar
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  asdf.exe  ex1.c  foobar.exe
>
> C:\Users\Jay\Documents\C_Projects>g++ ex1.c -o pancakes
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  asdf.exe  ex1.c  foobar.exe  pancakes.exe
>
> C:\Users\Jay\Documents\C_Projects>rm pancakes
>
> C:\Users\Jay\Documents\C_Projects>g++ ex1.c -Wall -g -o pancakes
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  asdf.exe  ex1.c  foobar.exe

Changed ex1.c to longer source again

> C:\Users\Jay\Documents\C_Projects>g++ ex1.c -o pancakes
> [deprecation warnings as shown above]
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  asdf.exe  ex1.c  foobar.exe
> C:\Users\Jay\Documents\C_Projects>cc ex1.c -o pancakes
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  asdf.exe  ex1.c  foobar.exe

Notice that I tried it with the shorter source to no avail (first
part), tried it with the longer source to no avail, then tried it with
the shorter source again and it worked.  You can also see it deleting
everything when -g is set as well.  Here's the longer source (taken
from Learn C The Hard Way,
http://c.learncodethehardway.org/book/ex15.html):

> #include <stdio.h>
>
> int main(int argc, char *argv[])
> {
> // create two arrays we c are about
> int ages[] = {23, 43, 12, 89, 2};
> char *names[] = {
> "Alan", "Frank",
> "Mary", "John", "Lisa"
> };
>
> // safely get the sizes of ages
> int count = sizeof(ages) / sizeof(int);
> int i = 0;
>
> // first way using indexing
> for (i = 0; i < count; ++i) {
> printf("%s has %d years alive.\n",
> names[i], ages[i]);
> }
>
> printf("---\n");
>
> // setup the pointers to the start of the arrays
> int *cur_age = ages;
> char **cur_name = names;
>
> // second way using pointers
> for (i = 0; i < count; ++i) {
> printf("%s is %d years old.\n",
> *(cur_name+i), *(cur_age+i));
> }
>
> printf("---\n");
>
> // third way, pointers are just arrays
> for (i = 0; i < count; ++i) {
> printf("%s is %d years old again.\n",
> cur_name[i], cur_age[i]);
> }
>
> printf("---\n");
>
> // fourth way with pointers in a stupid complex way
> for (cur_name = names, cur_age = ages;
> (cur_age - ages) < count;
> ++cur_name, ++cur_age)
> {
> printf("%s lived %d years so far.\n",
> *cur_name, *cur_age);
> }
>
> return 0;
> }

Finally, to show that my source is valid:

> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  asdf.exe  ex1.c  foobar.exe
>
> C:\Users\Jay\Documents\C_Projects>cygwin-gcc -Wall -g ex1.c -o pancakes
>
> C:\Users\Jay\Documents\C_Projects>ls
> Makefile  a.exe  asdf.exe  ex1.c  foobar.exe  pancakes.exe

I cannot stress enough that this has happened with other sources.  It
would run fine, suddenly break, I would do something and then put it
back (as mentioned above), and it would run fine for a while before
breaking again.  This is driving me insane.

Again, thanks in advance for any help.

 - Jay

On 5/9/2014 5:48 AM, Zouzou wrote:
> On 06/05/2014 20:44, Kirk Joppy wrote:
>>> What would Microsoft gain if they would chase away mingw from Windows?
>>
>> If mingw has a policy to remain bullet-proof against possible legal
>> action then guessing the mind of the party which might bring that
>> action is missing the point.
>>
>>> The mingw organisation is not a multi-million dollar company. "You can't
>>> pluck a bald chicken" (Dutch saying).
>>[snip]
>> Arguments similar to those you are making about mingw enlarging the
>> Windows user base could be made for the incident I described in the
>> previous paragraph. My _guess_ is that the company did this to prevent
>> legal precedent in which their copyright was not protected.
>>
>> Anyway, my point is, it is not only beside the point to guess about
>> what legal action Microsoft might take against mingw, it is also
>> potentially ruinous.
>
> Hey,
>
> The last time I can recall a Microsoft employee writing in this list, he
> seemed favorable to open-source compilers using Windows SDK headers:
> <http://mingw-users.1079350.n2.nabble.com/gcc-forks-on-Windows-was-re-repository-for-Open-Source-Windows-tp5223054p5284095.html>.

I think the only thing that can fly would be an iron-clad legal 
agreement, like what the Samba people did when Microsoft decided 
to cooperate and I guess have Samba as part of their ecosystem.

Remember, all of the header files are copyrighted. Asking for 
complete publicly-available documents would be easier than asking 
their lawyers to sign off on opening up their API files.

I still think someone on the Win32 open source API side should 
ping Satya Nadella or a visible personality on the compiler side 
like Herb Sutter.

Poke the gorilla (aka Microsoft) and ask nicely, so to speak... ;-)

> Has anything happened on that front? CoApp <http://coapp.org/index.html>
> still appears to be updated, though it never mentions MinGW.
>
> I do agree on erring on the side of caution for the moment.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

On 06/05/2014 20:44, Kirk Joppy wrote:
>> What would Microsoft gain if they would chase away mingw from Windows?
>
> If mingw has a policy to remain bullet-proof against possible legal
> action then guessing the mind of the party which might bring that
> action is missing the point.
>
>> The mingw organisation is not a multi-million dollar company. "You can't
>> pluck a bald chicken" (Dutch saying).
>
> False. Innocuous, free, and small projects posing no significant
> economic threat get taken down and their developers sued. The dollar
> amount doesn't even matter: you are going to settle for a fee that's
> so small it can't possibly matter to the company suing you. The real
> problem problem for you is that you will have to pay a lawyer and
> waste enormous amounts of time.
>
> Not too long ago the Cockatrice project (a small online card gaming
> program) was taken down and its developer sued. Users of the program
> argued that they used it to test the value of various cards before
> buying them through a paid gaming service offered by the company the
> brought the legal action. Apparently the company did not agree with
> this logic.
>
> Arguments similar to those you are making about mingw enlarging the
> Windows user base could be made for the incident I described in the
> previous paragraph. My _guess_ is that the company did this to prevent
> legal precedent in which their copyright was not protected.
>
> Anyway, my point is, it is not only beside the point to guess about
> what legal action Microsoft might take against mingw, it is also
> potentially ruinous.

Hey,

The last time I can recall a Microsoft employee writing in this list, he 
seemed favorable to open-source compilers using Windows SDK headers: 
<http://mingw-users.1079350.n2.nabble.com/gcc-forks-on-Windows-was-re-repository-for-Open-Source-Windows-tp5223054p5284095.html>.

Has anything happened on that front? CoApp <http://coapp.org/index.html> 
still appears to be updated, though it never mentions MinGW.

I do agree on erring on the side of caution for the moment.

Zouzou