[omniORB] BuildDebugBinary (Win32 MSVC) for omniORB4?

[Ken Feuerman]

Tracing into the omniORB code is indeed what I want to do, but it seems 
that the DLL's don't actually contain debug information, even though the 
various object files do.  I think the problem is that the DLL's are linked 
without the /debug option set (see the log below for an example of how 
omnithread30_rtd.dll was built).  I've been playing around with the 
win32.mk file, but I can't seem to get the options right so that 
omnithread30_rtd.dll is built with /debug flags, and omnithread30_rt.dll is 
built without /debug flags.  Any suggestions there?

--Ken Feuerman.
Adobe Systems, Inc.


At 03:41 PM 8/20/2001 +0200, Lars Immisch wrote:
>Duncan Grisby:
> > On Wednesday 15 August, Ken Feuerman wrote:
> >
> > > Has anybody tried building omniORB4 on a Win2K platform (MSVC 6.0) with
> > > BuildDebugBinary = 1?
> >
> > Probably not, no.
> >
> > BuildDebugBinary only applies to .exe files -- i.e. things like
> > omniNames and catior. I'm pretty certain that the debug versions of
> > the DLLs do have full debugging symbols in them. They're certainly big
> > enough. If they don't, it can be fixed by changing
> > MSVC_DLL_CXXDEBUGFLAGS and friends in mk/win32.mk.
>
>Yes, they do contain debug information.
>
> > The reason omniidl fails with BuildDebugBinary is that omniidl.exe is
> > linked against a non-debug python15.dll. I think the full Python
> > installation includes a debug version of the Python dll, so modifying
> > the omniidl make rules to use that (when BuildDebugBinary is on)
> > should fix it.
>
>Ahhh. Thanks.
>
>But as Duncan said above, it's not necessary if you want to trace into 
>omniORB
>code linked to your application (which seems the most common use).
>
>- Lars