Changes between Initial Version and Version 1 of Old/Documentation/OTG/DebugNote

Timestamp:

Sep 26, 2005, 4:35:46 PM (19 years ago)

Author:

zhibinwu

Comment:

—

Old/Documentation/OTG/DebugNote

@@ +1 @@
+[wiki:WikiStart Orbit] > [wiki:OTG OTG] > FAQ
+
+== Steps to debugging OTG on Sandbox without collection server support ==
+
+ 1. install libstdc++6 library in the nodes, which is compatiable with the setting in internal4.
+{{{
+apt-get update
+apt-get -o APT::Force-LoopBreak=true install libstdc++6
+}}}
+ 1. If there is no /usr/local/lib/oml2 directory in the node, copy all the files under internal4:/usr/local/lib/oml2/ to the /usr/local/lib/oml2 of the grid nodes.
+ 1. copy "otg-oml-sample.xml" into sender and set LD_LIBRARY_PATH
+{{{
+export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./:/usr/local/lib:/usr/local/lib/oml2
+}}}
+ 1. OML_CONFIG,OML_NAME can be set by ''export OML_CONFIG="./otg-oml-sample.xml"'' and ''export OML_NAME="Node-1"'' or in otg command line
+{{{
+./otg --dsthostname=internal2 --protocol=udp --oml-name "foo" --oml-config "../etc/otg-oml-sample.xml"
+}}} 
+ 1. Similarly, copy and set "otr-oml-sample.xml" in receiving node
+{{{
+export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./:/usr/local/lib:/usr/local/lib/oml2
+export OML_CONFIG="./otr-oml-sample.xml"
+export OML_NAME="Node-2"
+}}}
+
+== Handling "non-virtual destructor" warning message with Gcc 4.0 ==
+By default, if destructor is not specified, its non-virtual,
+but for every class derived from a virutal base class, the destructor have to be virtual.
+
+In particular, here's when you need to make your destructor virtual:
+
+  * if someone will derive from your class,
+  * and if someone will say new Derived, where Derived is derived from your class,
+  * and if someone will say delete p, where the actual object's type is Derived but the pointer p's type is your class. 
+
+Confused? Here's a simplified rule of thumb that usually protects you and usually doesn't cost you anything: make your destructor virtual if your class has any virtual functions. Rationale:
+
+  * that usually protects you because most base classes have at least one virtual function.
+  * that usually doesn't cost you anything because there is no added per-object space-cost for the second or subsequent virtual in your class. In other words, you've already paid all the per-object space-cost that you'll ever pay once you add the first virtual function, so the virtual destructor doesn't add any additional per-object space cost. (Everything in this bullet is theoretically compiler-specific, but in practice it will be valid on almost all compilers.) 
+
+Note: if your base class has a virtual destructor, then your destructor is automatically virtual. You might need an explicit destructor for other reasons, but there's no need to redeclare a destructor simply to make sure it is virtual. No matter whether you declare it with the virtual keyword, declare it without the virtual keyword, or don't declare it at all, it's still virtual.
+
+Fix is easy:
+Just add virtual destructor in base class:
+{{{
+public:
+virtual ~Foo(){}
+}}}
+
+
+==  Using the external "C" Linkage Specification ==
+calling C functions (LIBMAC) in C++ code (OTG),Solition is :
+{{{
+extern "C" {
+#include <libmac/libmac.h>
+}
+}}}
+
+To handle overloaded function names the HP C++ compiler generates new, unique names for all functions declared in a C++ program. To do so, the compiler uses a function-name encoding scheme that is implementation dependent. A linkage directive tells the compiler to inhibit this default encoding of a function name for a particular function.
+
+If you want to call a C function from a C++ program, you must tell the compiler not to use its usual encoding scheme when you declare the C function. In other words, you must tell the compiler not to generate a new name for the function. If you don't turn off the usual encoding scheme, the function name declared in your C++ program won't match the function name in your C module defining the function. If the names don't match, the linker cannot resolve them. To avoid these linkage problems, use a linkage directive when you declare the C function in the C++ program.
+
+
+== Make OTG Software without working client_wrapper libraries ==
+First, get a source package of ''otg'' in the node.
+then prepare additional files. Use w-get to fetch .h .cpp and .a files. As those lib files (.a) cannot be used for some reason,
+we need manually build them in the node.
+{{{
+  cd otg/src/cpp
+  make otg;make otr; make otf
+  cp ../../build/include/* ./
+  cp ../../build/src/* ./
+}}}
+'''Get new OML client libraries'''
+{{{
+scp zhibinwu@external1:tmp/oml_libraries/* /usr/local/lib/oml2
+}}}
+'''Get oml header files'''
+{{{
+mkdir oml
+scp zhibinwu@external1:tmp/oml/* ./
+}}}
+After this, see
+ {{{
+ node1-1:~/otg/src/cpp/oml# ls
+ Metric.h  MetricAggregator.h  OmlContext.h  OmlFilter.h  OmlQueueItem.h  oml.h  oml_def.h  oml_tx.h
+ }}}
+'''Change Makefile''' [[BR]]
+adding new include
+{{{
+         CFLAGS  = -g -Wall -I$(INC_DIR)  -I. -Iauto -I/usr/local/include/scew -Ioml/
+}}}
+adding new sourcecode files
+{{{
+OTG_SRCS = ....
+    ...orbit_winlab_otg.cpp
+...
+...
+}}}
+remove the -l$(OT?_OML_LIB) in each target see: [[BR]]
+change from
+{{{
+$(CC) -o $@ $(OTG_OBJS) $(LDFLAGS) $(LIBS) -l$(OTG_OML_LIB)
+}}}
+to
+{{{
+$(CC) -o $@ $(OTG_OBJS) $(LDFLAGS) $(LIBS)
+}}}
+At last,
+{{{
+make clean
+make
+}}}
+