Sorin, A few comments on you e-mail:
> Unfortunately, VSTUDIO8's compiler requires to be the only compiler installed on the system. > This is why it installs a new .NET framework and uninstalls the old one, which was required by VSTUDIO7. I don't think this is true. We have several developers with multiple versions of MSVC++ installed and we are not aware of any problem in either C++ or .NET development. Personally I have 6.0, 7.0, 7.1 and 8.0 installed and all working just fine. Also I have the associated .NET framework installed. MSVC8 did not uninstall anything for me. The only thing you might want to do is to install them in the historical order (6.0->7.0->7.1->8.0). > Well, it looks like we do not export all of them now, or we export something wrong. I am not > sure and I didn't have time to investigate. > I have to review all the code and make some tests. I have not found any problem with the export symbols in MSVC8 and v2.3.11 in the commercial baseline. I have found only 1 problem in my case: I have modified the makefile to statically link in the pthread symbols to the micoxxx.dll so I do not have to deal with the extra binary. If I compile a compined object file from the source files in 64-bit mode (ONLY!) the symbols from the pthread obj are ignored. I had to make a very simple change in the gendef.cc to deal with it. We are planning to move up to v2.3.12 around June this year and I'm planning to commercially integrate these changes to the commercial baseline if somebody else does not do it in the meantime. Regards: Zoltan Bordas Software Engineer OpenSpirit Corporation www.openspirit.com +1 281.295.1426 direct +1 281.295.1401 fax -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sorin Mustaca Sent: Sunday, February 12, 2006 5:08 PM To: Peter C. Chapin Cc: [email protected] Subject: Re: [mico-devel] mico 2.3.12 fails to build with Visual C++ v8? Hi, I also tried to compile MICO with this compiler. I did more or less the same steps as you described below. And I received exactly the same error. It looks like VSTUDIO doesn't install the binaries, libs and environment variables in a backward compatible way. I have to dig a little bit to see what exactly has changed. If you have time, please have a look at the family of batch files vsvars32/vcvars32 and see what are the changes.We might have to update the makefiles (the PATH variable). Unfortunately, VSTUDIO8's compiler requires to be the only compiler installed on the system. This is why it installs a new .NET framework and uninstalls the old one, which was required by VSTUDIO7. See below other comments. Peter C. Chapin said the following on 12.02.2006 14:16: > > + I removed /GX from the CXXFLAGS and CCFLAGS variables. This flag is > deprecated. I'm led to believe from the VC documentation that it has > exactly the same effect as /EHsc (which is already specified in CXXFLAGS). > I don't know why /GX is in CCFLAGS. Is there a reason? True, GX is the same as EHsc. I think this flag remained there for backward compatibility only. It will be removed. > > + I added /D_CRT_SECURE_NO_DEPRECATE to CXXFLAGS and CCFLAGS. If you don't > do this you get "deprecation" warnings about lots of C library functions > that are unsafe (such as strcpy, etc). Microsoft now wants everyone to use > the "safer" C library functions (such as strcpy_s, etc). Yes... There is no other workaround. > > + I removed /Yd from the PTHREADS_FLAGS variable. This flag is also > deprecated. This change didn't seem to have the effect I expected, it > looked like /Yd was still being used during the pthreads build. I guess > the actual command line for that build is set elsewhere. Yd puts debug info in every .OBJ, therefore, it makes sense only in debug versions. > > In include\mico\throw.h: > > + Around line 55 there was > > // avoid compiler warnings ... > (void)mico_throw; > > This actually causes compiler warnings (the warning is that mico_throw has > been given no arguments). Am I correct in saying that this code has no > effect? I am not sure what mico_throw does ... If you look in the file : static void mico_throw (const CORBA::Exception &ex). So, there is no default parameter. I am surprised that it compiles ... >It looks like it asserts mico_throw's address without using that > address in an expression. I commented out the line to remove the warning. > There is a similar issue on line 96 and I commented out that one as well. > > After these changes the number of warnings during the compilation was > reduced from "huge" to managable. Specifically quite a few warnings remain > about possible loss of precision when assigning 64 bit values to 32 bit > long integers. ... and a lot of "unused variables" from exception handlers. (which will be hopefully removed until next release) > > However... mico won't build. In particular the first time it attempts to > run the freshly made IDL compiler I get: > > ..\..\win32-bin\idl.exe --windows-dll coss -B..\.. --c++-skel > --name CosNaming ..\..\include\coss\CosNaming.idl > NMAKE : fatal error U1077: '..\..\win32-bin\idl.exe' : return code > '0xc0000135' > Stop. > > I don't know what this return code means to me. However, if I try to run > the IDL compiler manually (I cd into mico\win32-bin and type "idl") I get > a message box that says: It means that a function from a certain module is not found. Missing export or something like this. It has to do with the __security_error_handler and other symbols. > > "This application has failed to start because MSVCR80.dll was not found." > > The file MSVCR80.DLL is the C runtime library used when the /MD flag is > selected (I'm doing a release build of mico). The odd thing is that other > executables are able to find this DLL fine. It is more than a dll not found. It has to do with those exports... Short story: In order to make MICO export the symbols we made an ugly hack : We "manually" dumped all the symbols from all obj files and link them in a lib/dll ... Just have a look at orb/gendef.cc. Well, it looks like we do not export all of them now, or we export something wrong. I am not sure and I didn't have time to investigate. I have to review all the code and make some tests. Possible Workaround (I don't know if it works, because I haven't tried it yet): Compile MICO with a VSTUDIO project. It is not complicated to create one: Put all the .cc files from the makefile.win32 from "orb/" directory in a vcproj and be sure that you define all the symbols from root/Makevars.win32. When I'll can, I will add them myself to MICO's repository (currently I have to stick to VC7, so I can't "upgrade"). Good luck. Let us/me know if it worked. Thanks >For example when I write a > "Hello World" program using /MD and then observe which DLLs it attaches to > when it runs (using the process explorer tool from sysinternals), it finds > MSVCR80.DLL without a problem. Somehow the ability to find this DLL is > being defeated or overridden in the build of idl.exe but I'm not enough of > a Windows guru to know how that might work. > > Any thoughts or suggestions? > > Peter > > _______________________________________________ > Mico-devel mailing list > [email protected] > http://www.mico.org/mailman/listinfo/mico-devel > > _______________________________________________ Mico-devel mailing list [email protected] http://www.mico.org/mailman/listinfo/mico-devel _______________________________________________ Mico-devel mailing list [email protected] http://www.mico.org/mailman/listinfo/mico-devel
