rh4 binary archive + visual studio 2005 no sp1

[pdb1013]

Why have the rh4 binary archive and visual studio 2005 no sp1 .msi not been included with the latest release?

I'm having trouble using Ice 3.2.0 with GCC 4.3.3 because of the auto_ptr no type errors mentioned in other threads (possibly something to do with missing includes) and am trying to upgrade to the latest version. However, I am using visual studio 2005 with no sp1 (firm-wide decision, I have no choice in the matter) and preferred the old rh4 binary archive because everything was in one place.

Just curious... The visual studio 2005 no sp1 release would help me out tremendously. Alternatively, is there an easy way to make 3.2.0 work with GCC 4.3.3?


Here is the GCC 4.3.3 output. This code works perfectly, with no warnings in 3.4.6

Thanks!



/home/fiapp/opt/Ice-3.2.0/include/Ice/Outgoing.h:56: error: ISO C++ forbids decl
aration of âauto_ptrâ with no type
/home/fiapp/opt/Ice-3.2.0/include/Ice/Outgoing.h:56: error: invalid use of â::â
/home/fiapp/opt/Ice-3.2.0/include/Ice/Outgoing.h:56: error: expected â;â before
â<â token
/home/fiapp/opt/Ice-3.2.0/include/Ice/Outgoing.h:84: error: ISO C++ forbids decl
aration of âauto_ptrâ with no type
/home/fiapp/opt/Ice-3.2.0/include/Ice/Outgoing.h:84: error: invalid use of â::â
/home/fiapp/opt/Ice-3.2.0/include/Ice/Outgoing.h:84: error: expected â;â before
â<â token

[bernard]

Hi Peter,

We decided to provide only RPM binary distributions for Ice 3.3.x on RHEL and SLES, because RPM is the standard packaging format for these platforms. We'll do the same with the upcoming 3.4 release.

I believe we decided to require VS2005 SP1 due to some issue with the Visual Studio IDE, but I am not sure anymore. It's true that installing SP1 is a pain (it's very large and takes a long time), so in retrospect this may not have been the best decision. In any case, we do not provide a VS2005-no-SP1 binary distribution for Ice 3.3.x.

We didn't support GCC 4.3 with Ice 3.2 (http://www.zeroc.com/platforms_3_2_1.html); my recommendation would be to upgrade rather than try to "port" Ice 3.2 to GCC 4.3.

Best regards,
Bernard

[pdb1013]

I will push forward with upgrading. One thing that is causing me a lot of grief is I think Ice 3.2.0 was tolerant of _WIN32_WINNT < 0x0400. For whatever reason, other libraries I'm pulling in cause TryEnterCriticalSection to be not defined (i think they define things that prevent the inclusion of certain windows api headers), which worked fine with Ice 3.2.0 if you set _Win32_WINNT to 1 for example, before including any Ice headers. Looking in \Ice-3.3.1\include\IceUtil\Config.h, there are some differences between the versions with respect to the section that includes <windows.h>

There is some kind of order of includes issue or libraries not playing well together, resulting in TryEnterCriticalSection not being defined, although _WIN32_WINNT >= 0x0400 and the system is WinXP SP2, resulting in compilation errors about Ice-3.3.1\include\IceUtil\Mutex.h... The same slice definition worked fine with Ice 3.2.0. Any pointers anyone has would be very much appreciated. Thanks again

[pdb1013]

Interestingly, if _WIN32_WINNT is some arbitrary number less than 0x0400, everything works perfectly with Ice 3.2.0. If _WIN32_WINNT is set to 0x0400 or above, 3.2.0 has the same compile errors as 3.3.1.

With Ice 3.3.1, setting _WIN32_WINNT to less than 0x0400 doesn't appear to be an option. I tried commenting out a few parts of Config.h for Ice 3.3.1 just for fun to see if it would build anyway to no avail. Don't know if this helps or not.

-Peter

[pdb1013]

So, this problem was fixed by setting _WIN32_WINNT=0x0500 in the command line arguments to the compiler, as opposed to in the code before including the Ice headers. I think some part of the windows api was being included without that set properly, causing TryEnterCriticalSection to remain undefined. Everything is working fine in windows. It seems cleaner setting this in the project settings/command line than in the code anyway.

Thanks for your help