Re: [Dpcl-develop] Re: Dpcl-develop digest, Vol 1 #46 - 1 msg

[Dave W. <dwo...@us...>]

Chip

This is gcc 3.2 on Red Hat 8.0 for both machines, with gcc -v displaying 
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

The failing symbol according to the loader debug output is 
Aismsgbuff::queue_size which is declared as a static member of the 
AisMsgbuff class with type int.

If I try to load dpcld by invoking it from the command line 
(/opt/dpcl/bin/dpcld), then it loads just fine, issuing the dpcld banner 
with version and build date then exiting.

If it gets invoked by the super daemon, then it fails, and getting the 
debug output from the system loader shows this symbol as the problem.

For some reason, it works just fine on a second machine which has the same 
compiler version and at Red hat 8 plus some updates to various packages.

Dave




"David R. (Chip) Kent IV" <dr...@la...>
Sent by: dpc...@ww...
07/31/2003 12:46 PM
 
        To:     dpc...@ww...
        cc: 
        Subject:        [Dpcl-develop] Re: Dpcl-develop digest, Vol 1 #46 
- 1 msg



Dave,

> I'm suspicious the compiler on the failing machine has a bug that is 
> causing the load to fail, but it's very strange that it fails only when 
> loading the daemon from the DPCL super daemon and not when invoking it 
> from the command line.

What compiler are you using?  I have only been able to get Maryland's 
dyninst to run properly with GCC 3.2.3.  Maryland reports 3.2.2 working as 

well.  I have tried a number of other compiler versions, and none gave 
properly functioning code.

> 
> I don't see why this should matter at all, since the symbol that is 
> raising the error is a static int in a DPCL class which should have 
> nothing to do with any libraries being loaded.

Some of the first problems I fixed in DPCL involved static ints.  Either 
the compiler or the DWARF libraries don't properly deal with them.  I 
solved these problems by changing the static int statments to #define 
statments.  These are practically the same from a coding point of view, 
but they avoid the compiler or DWARF problem.

Chip
_______________________________________________
Dpcl-develop mailing list
Dpc...@ww...
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/dpcl-develop