axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lilantha Darshana" <Lilantha.Darsh...@Siebel.com>
Subject RE: /MD and /MT compiler options on MSVC6
Date Fri, 23 Sep 2005 20:45:11 GMT
First question is why are you trying to link with both msvcrt and
msvcr71 CRT libs at the same time? 

 

If we use /MT option that mean we link statically to multi-threaded
library so the generated object file size 

is large. But if we use /MD we link to a static lib - having
LoadLibrary() method and respective code to get the

ProcAddress() of called functions - that is having only the tiny code
for loading functions from a 

shared lib at runtime. So the final object code is small.

 

Check your lib path and linker path to see whether you are using
anything from .NET instead of all libs from MDVC6.

 

Thanks

-Lilantha

 

 

 

  _____  

From: Fred Preston [mailto:PRESTONF@uk.ibm.com] 
Sent: Friday, September 23, 2005 7:16 AM
To: axis-c-dev@ws.apache.org; axis-c-user@ws.apache.org
Subject: /MD and /MT compiler options on MSVC6

 


Hi All, 
        I'd like to discuss the /MD and /MT compiler options available
on MSVC6. 

        The AxisClient DLLs are built with the /MD option that instructs
the DLLs to use both multi-threaded and DLL specific options within the
standard header files.  It also tells the compiler to put the MSVCRT.lib
into the object file and applications are statically linked to it.  The
DLLs are dynamically linked to msvcprt.lib while still dynamically
linked to the main C runtime via msvcrt.lib. 

        Now, If I use the ant scripts to build one of the tests (such as
AxisBench) it will build and run successfully.  What I hadn't realised
up to now is that when I use the ant scripts, it uses the same compiler
options to build the tests as it does to build the Axis DLLs and so the
tests are being built with the /MD compiler option.  I am looking at
AXISCPP-149, trying to work out the best way to clean up the 'delete
<stub_generatred_object>' problems with complex objects and needed to
debug a couple of tests to see what is missing in the delete (this is a
bit of an aside, but helps set the context).  So I created a new MSVC
project using the test generated framework for AxisBench and compiled
the project using the 'normal' application build options (i.e. /MT for
multi-threaded application).  Now, using the /MT option causes the
compiler to place the LIBCMT.lib into the object file.  When the
'release' version of the application was built, it was immediately
obvious that I had two different exe's because the ant built one was 56K
whilst the MSVC built one was 208K.  So what does this mean?  Well, I've
already said that the ant built exe runs, but the MSVC built one with
the /MT option failed with the following messages:- 
Unknown Exception occurred. 
Unknown Exception occurred. 
Unknown Exception on clean up: 
Unknown Exception occurred. 
Unknown Exception on clean up: 

        It is failing inside
BenchDataType::Axis_Deserialize_BenchDataType( BenchDataType * param,
IWrapperSoapDeSerializer * pIWSDZ) at the beginning of the method when
it tries to delete 'count' which is an object that is passed back after
being created within the deserialiser (across the DLL boundary? - more
on this later...).  This is because 'count' is not known to the heap and
it reports the following error:- 
HEAP[AxisBench.exe]: Invalid Address specified to RtlFreeHeap( 00340000,
0057B2D8)  <-- obviously the numbers will change! 

        So, I looked at the compiler options and discovered that ant was
building the applications with the /MD option.  When I tried this
option, the exe size was the same and the application ran without a
problem. 

        So, what does this mean?  I started with the libraries...
Looking at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/
html/_core_.2f.MD.2c_2f.ML.2c_2f.MT.2c_2f.LD.asp and
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/h
tml/_crt_c_run.2d.time_libraries.asp, the LIBCMT.lib is a
multi-threaded, static link library and MSVCRT.lib is a multi-threaded
dynamic link library...  "Humm, so what?", I thought, but I kept
reading...  The very last sentence of the "What problems exist if an
application uses both msvcrt and msvcr71?" is very revealing, "...If
your DLLs pass CRT resources across the library boundary, you will
encounter issues with mismatched CRTs...".  I would take this to be
memory issues, such as heap, etc.  And it finishes with "...recompile
your project with Visual C++ .NET.". 

        So, we have potential problems with different libraries using
MSVC6 and Microsoft is suggesting that if we are finding problems, then
we need to move to '.NET' which I think implies that we should move to
MSVC7 (which can be found on MSVC 2003 .NET).  Interesting... 

RECOMMENDATIONS: 
1.        If you are having similar problems as I did running
AxisClient, try using the /MD rather than /MT compiler flag. 
2.        AxisClient should be built using MSVC7 to avoid future library
inconsistencies. 

Regards,

Fred Preston.


_______________
Siebel
IT'S ALL ABOUT THE CUSTOMER
Visit www.siebel.com

This e-mail message is for the sole use of the intended recipient(s) and contains confidential
and/or privileged information belonging to Siebel Systems, Inc. or its customers or partners.
Any unauthorized review, use, copying, disclosure or distribution of this message is strictly
prohibited. If you are not an intended recipient of this message, please contact the sender
by reply e-mail and destroy all soft and hard copies of the message and any attachments. Thank
you for your cooperation.

Mime
View raw message