I think he wants those to be displayed more prominently. I think there should be a notice right below the RC2 message on the front page that user should try the nightly builds if they have problems.
Exactly. I understand that the nightly builds are probably less stable and change a lot, but RC2 simply doesn't show the state of the project. And I guess most people don't like to try the "bleeding edge" expecting that it's much less stable, and don't bother downloading nightly builds. But I guess it's a matter of policy when the authors will decide to announce "a new and much improved build". BTW, calling these builds "release candidates" is not a good idea, since one expects from RC's to represent the final state of the project and only contain bug-fixes from there on.
The reason you can just include the std C headers and not have to worry about this is because they already have all the proper defines setup to include the "extern C" if you are using a C++ compiler.
Exactly. Naturally, I had examined MMSystem.h and noticed that it includes an extern "C" declaration.
About the library. Both C and C++ compilers do name mangling, although the C method is standard, the compiler just puts a "_" in front of the name which is why you set "_timeGetTime()" in the binary. Can you set the compiler to show the full command line and then post the results.
The problem turned out to be entirely different. First I discovered that the function name was actually the same in the object file that uses timeGetTime and in libwinmm.a - it was "_timeGetTime@0". I should have checked the .o file, but since the GNU linker message was about 'timeGetTime@0' (without a leading _), I decided that this is the exact name of the function as listed in the .o file. It turns out that the linker tries to "beatify" the name a bit, which confused me.
Then I started comparing the command lines issued by C::B and Dev-Cpp. One worked while the other didn't. I couldn't see any important differences. I started converging the two lines step by step and testing them. Finally I found out that the order of listing the object and library files in the command line is important - the linker searches for references only in the following objects on the command line. At this point I realized why in the build options of the C::B IDE you can select whether the target options are to be appended or prepended to the project options. Setting the proper order of command line generation fixed the problem.
So I guess these are just typical experience lessons from using a new compiler/linker... first the misleading error message, then the discovery about importance of order in the command line (I'm sure the MS linker doesn't require any order). I guess the explanation about this "append/prepend" option should be included in a future detailed documentation, for people without GNU C++ experience.
(BTW, I changed the topic to make it a bit more relevant.)