[omniORB] BuildDebugBinary (Win32 MSVC) for omniORB4?

[Ken Feuerman]

I must be having one of those "Monday morning moments"....  Here's the 
snippet of the build log that I promised:

../../../bin/x86_win32/clwrapper -gnuwin32 -c  -MDd -GX -Z7 
-Od  -D_OMNITHREAD_D
LL  -I. -I. -I../../../include -D__WIN32__ -D__x86__ -D__NT__ -D__OSVERSION__=4
-Foshareddebug/nt.o nt.cc
cl -c -MDd -GX -Z7 -Od -D_OMNITHREAD_DLL -I. -I. -I..\..\..\include -D__WIN32__
-D__x86__ -D__NT__ -D__OSVERSION__=4 -Foshareddebug\nt.o -Tpnt.cc
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

nt.cc
(namespec="omnithread _ 3 0" debug=1 extralibs="" nodeffile=1; \
          set $namespec ; if [ $2 = "_" ] ; then set $1 "" $3 $4 ; fi; 
extrasuffi
x=${debug:+d}; targetdir=shareddebug; libname=$1$2$3$4_rt${extrasuffix:-}; 
dllna
me=$targetdir/$libname.dll; defname=$targetdir/$1$2${extrasuffix:-}.def; 
version
=$3.$4; if [ -z "$nodeffile" ]; then symrefdir=${debug:+debug}; 
symreflib=${symr
efdir:-static}/$1$2${extrasuffix:-}.lib; if [ ! -f $symreflib ]; then echo 
"Cann
ot find reference static library $symreflib"; return 1; fi; set -x; echo 
"LIBRAR
Y $libname" > $defname; echo "VERSION $version" >> $defname; echo 
"EXPORTS" >> $
defname; DUMPBIN.EXE /SYMBOLS $symreflib | egrep '^[^ ]+ +[^ ]+ +SECT[^ ]+ 
+[^ ]
+ +\(\) +External +\| +\?[^ ]*|^[^ ]+ +[^ ]+ +SECT[^ ]+ +[^ ]+ +External 
+\| +\?
[^?][^ ]*'| egrep -v 'deleting destructor[^(]+\(unsigned int\)' | egrep -v 
'anon
ymous namespace' | cut -d'|' -f2 | cut -d' ' -f2 | /bin/sort -u >> 
$defname; set
  +x; defflag="-def:$defname"; fi; set -x; rm -f 
shareddebug/omnithread30_rtd.lib
; ../../../bin/x86_win32/linkwrapper -gnuwin32 -out:$dllname -DLL  $defflag 
-IMP
LIB:shareddebug/omnithread30_rtd.lib -libpath:../../../lib/x86_win32 
shareddebug
/nt.o $extralibs;)
+ rm -f shareddebug/omnithread30_rtd.lib
+ ../../../bin/x86_win32/linkwrapper -gnuwin32 
-out:shareddebug/omnithread30_rtd
.dll -DLL -IMPLIB:shareddebug/omnithread30_rtd.lib 
-libpath:../../../lib/x86_win
32 shareddebug/nt.o
link -out:shareddebug\omnithread30_rtd.dll -DLL 
-IMPLIB:shareddebug/omnithread30
_rtd.lib -libpath:..\..\..\lib\x86_win32 shareddebug\nt.o
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

    Creating library shareddebug/omnithread30_rtd.lib and object 
shareddebug/omni
thread30_rtd.exp

At 09:54 AM 8/20/2001 -0700, Ken Feuerman wrote:
>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
>