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: [email protected]
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
_______________________________________________
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
