Malcolm, I think you are correct. I would you send an e-mail directly to Sorin Mustaca with the changes you propose.
Zoltan There was a thread about a similar issue back in 2006 (see below) when MSDEV 2005 was not officially supported yet. Note that the manifest tool used #2: --------------------------------------------------------------------------------------------------------------------------- -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zoltan Bordas Sent: Monday, February 13, 2006 7:22 AM To: 'Peter C. Chapin'; mico-devel@mico.org Subject: RE: [mico-devel] mico 2.3.12 fails to build with Visual C++ v8? Hi Peter, I do not know exactly what the problem is in your environment. I successfully built MICO 2.3.11 using MSVC8 in both 32 and 64-bit mode and we are using them in a commercial environment. Both libraries are running fine in both single and multi-threaded mode (the second one is a bit special compared to the original MICO distribution). We will probably switch over to version 2.3.12 around June this year. Your problems are most likely related to manifests. MSVC8 requires you to either specify a manifest section in your executable (like Java) or to have a manifest file next to the exe. You can test it by copying out the generated manifest file next to the binary and trying to run it again. If this is the problem you can do the following: Since the original makefiles do not h deal with manifests you need to change them. The original link looks something like this: $(LINK) $(LINKDLLFLAGS) $(DLL_OBJS) \ $(SYSLIBS) $(CCMLIB) /out:mico$(VERSION).dll \ /def:mico$(VERSION).def /implib:mico$(VERSION).lib You have to modify it to generate an intermediate manifest file and invoke the manifest tool to add it to the exe itself like this: $(LINK) $(LINKDLLFLAGS) $(DLL_OBJS) \ $(SYSLIBS) $(CCMLIB) /out:mico$(VERSION).dll \ /def:mico$(VERSION).def /implib:mico$(VERSION).lib \ /MANIFEST /MANIFESTFILE:"mico$(VERSION).dll.intermediate.manifest" mt.exe /outputresource:"mico$(VERSION).dll;#2" /manifest mico$(VERSION).dll.intermediate.manifest You probably want to do this using a specific define some version information. After these changes you will have all the binary files having an appropriate manifest section. You can also choose to generate and distribute the manifest files separately but it will double the files you need to carry around when you redistributes the MICO binaries. Since I'm using the older version of MICO I have never posted these changes to the baseline. If you have the time would you be so kind to add and post these changes for all the makefiles the produce a runtime binary. Please let me know if the problem was this or something else. Good luck: 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 Peter C. Chapin Sent: Sunday, February 12, 2006 7:17 AM To: mico-devel@mico.org Subject: [mico-devel] mico 2.3.12 fails to build with Visual C++ v8? I accidently sent this message from the wrong address so it may not have been distributed. However, if you get two copies of this message, my apologies. ---- Hello! I'm attempting to build Mico v2.3.12 using Visual C++ v8. An "out of the box" build produces a huge number of warnings so I made a few adjustments to two files. Specifically: In MakeVars.win32: + 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? + 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). + 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. 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? 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. 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: "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. 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 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Malcolm Davey Sent: Tuesday, November 25, 2008 4:38 PM To: mico-devel@mico.org Subject: [mico-devel] Building with VS 2005/2008 - manifests for dll's Hi There There are a number of lines in the windows makefiles to build the manifest into the binary. The ones for dlls are incorrect For dlls there should be a #2 instead of #1 (which is the default if left off). e.g. $(MT) -manifest micocoss$(VERSION).dll.manifest -outputresource:micocoss$(VERSION).dll;#2 This issue doesn't always show up, since if the exe loading the dll can already find the correct VC dll's it will work, otherwise there will be issues loading the VC dlls dependant on the manifest. If you use dependency walker, it won't find the dlls, if there is no separate manifest file in the folder. See MS documentation on this: http://msdn.microsoft.com/en-us/library/ms235591(VS.80).aspx Malcolm _______________________________________________ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel _______________________________________________ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
