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
_______________________________________________
Mico-devel mailing list
[email protected]
http://www.mico.org/mailman/listinfo/mico-devel
