1   2005-12-16 LD_LIBRARY_PATH and LD_RUN_PATH

(Pointed out in an email by Garrick Staples)

Environment variable LD_LIBRARY_PATH (set it in bash by export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/) is run-time; affecting all programs in your env. So even 'ls' must first do a dozen stat()'s in your home directory to run. For this, steps:

• g++ -L~/ -ltest hello.o -o hello
• export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/
• ~/hello

LD_RUN_PATH is build-time; writing that path into the binary. It's equivalent to -R of ld. Look for LD_RUN_PATH, -rpath(= -R) in man ld. Also see man ld.so. steps:

• g++ -R~/libtest.so hello.o -o hello #(g++ would complain it can't recognize -rpath/-R. but it calls ld which recognizes it.)
• ~/hello

Or:

• export LD_RUN_PATH=$LD_RUN_PATH:~/
• g++ hello.o -o hello
• ~/hello

Somehow, -rpath is supposed to be followed by a directory. but it works on a filename, not a dir.

2   2006-01 access pair iterator:

Suppose a pair iterator '__gnu_cxx::hash_map<long, boost::dynamic_bitset<> >::iterator edge2bitset_iter = edge2bitset.begin();', you can access key by 'edge2bitset_iter->first' but not 'edge2bitset_iter.first'. (value is ->second)

However, if it's not an iterator, '.' should be used instead of '->':

std::pair<Graph, std::vector<boost::dynamic_bitset<> > > graph_recurrence_bitset_vector;
_recurrence_bitset_vector = graph_recurrence_bitset_vector.second;

2008-04-07 the correct expression to access pair iterator is:

cerr << (*edge2bitset_iter).first << std::endl;
cerr << (*edge2bitset_iter).second << std::endl;

2008-04-07 given the key, edge2bitset[key] will give you nothing. Have to use iterator from .find() to return value.:

edge2bitset_iter = edge2bitset.find(key);
std::cerr<< (*edge2bitset_iter).second <<std::endl;

3   2006-01 hash_map include:

correct format is:

#include <ext/hash_map>
__gnu_cxx::hash_map<long, boost::dynamic_bitset<> > edge2bitset;

4   2006-01 customize hash function:

Remember, hash function is a type, not merely a function. So 'struct' or 'class' with '()' reloading is ok:

struct hash_edge_name
{
  size_t operator()(std::pair<int, int> edge_name) const
  {
    return ((edge_name.first<<32)+edge_name.second);
  }
};

__gnu_cxx::hash_map<std::pair <int, int>, int, hash_edge_name > edge_sig_vector_hash_map;

5   2006-01-10 error: return type specification for constructor invalid:

stupid error because of missing ';' in the end of class definition

Mostly about the constructor function, it will also incur this kind of message:

error: return type specification for constructor invalid

It's because the class def is treated as a type by the compiler.

6   2006-10-10 undefined reference to '__ctype_b'

bug in linking old libraries with new libc

2006-10-10 It happened in compiling haiyan's modes with LEDA library via g++-2.95. The LEDA library is the old free version which requires g++-2.95. More than half a year ago, everything went smooth. Now due to the version upgrade of libc6(debian package) to 2.3.6.ds1-4, it started to break down in compiling:

g++-2.95 -g  -Xlinker -zmuldefs -L../lib/leda -L/usr/X11R6/lib   -o ../bin/modes modes.o ReadData.o OHCS.o Utilities.o BFS.o ../lib/superlu_linux.a ../lib/libarpack_i686.a ../lib/liblapack.a ../lib/libblas.a  ../lib/libg2c.a -lG -lL -lstdc++ -lm
../lib/leda/libL.a(_file.o): In function `tmp_file_name(void)':
_file.c:(.text+0x14c3): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
../lib/libg2c.a(open.o): In function `f_open':
/home/hhu/usr/gcc295/gcc-2.95.3/i686-pc-linux-gnu/libf2c/libI77/open.c:213: warning: the use of `tempnam' is dangerous, better use `mkstemp'
../lib/leda/libG.a(_g_inout.o): In function `read_data_string(istream &)':
_g_inout.c:(.text+0xc6a): undefined reference to `__ctype_b'
../lib/leda/libG.a(_g_inout.o): In function `read_reversal(istream &)':
_g_inout.c:(.text+0xf43): undefined reference to `__ctype_b'
_g_inout.c:(.text+0xf91): undefined reference to `__ctype_b'
../lib/leda/libL.a(_basic.o): In function `leda_isspace(char)':
_basic.c:(.text+0x19): undefined reference to `__ctype_b'
../lib/leda/libL.a(_dlist.o): In function `dlist::read(istream &, leda_string, int)':
_dlist.c:(.text+0x28f4): undefined reference to `__ctype_b'
../lib/leda/libL.a(_dlist.o):_dlist.c:(.text+0x2a54): more undefined references to `__ctype_b' follow
../lib/leda/libL.a(_string.o): In function `leda_string::to_lower(void) const':
_string.c:(.text+0x323b): undefined reference to `__ctype_tolower'
collect2: ld returned 1 exit status
make: *** [../bin/modes] Error 1

Here, http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86465 is a source of help. It turns out that a file, http://newweb.ices.utexas.edu/misc/ctype.c is needed to fix the "undefined references". Now it's in hhu_clustering/common/. Other hhu_clustering programs also need ctype.c to work.

7   2006-01-24 notice when using shift operators:

shift operators are probably the lowest in the order. '1421+4321<<16' is different from '1421+(4321<<16)'

8   2007-01-17 bit_vector

previously #include <vector> is probably enough. but now #include <bvector.h> is required to get it correctly compiled.

9   2007-01-17 overloading issue of abs()

The Standard C++ library is supposed to overload abs the way you expect, but it's common for implementations to omit the overloads, or put them in the wrong place (<cmath> instead of <math.h>).

Problem encounted when compiling graph_modeling.cc due to this problem. #include <cmath> solves the issue.

10   2008-12-02 link f77 objects with c objects

-lf2c doesn't work to link f77 objects with c objects. ERROR: /usr/bin/../lib/libf2c.so: undefined reference to `MAIN__'. so link /usr/lib/libf2c.a directly into the binary and remove -lf2c. like this:

$(CC) -O -I$(IDIR) $(DEBUG_OPTIONS) -o $(M1) $(M1O) /usr/lib/libf2c.a  -lm -llapack -l$(BLAS) -Wimplicit # -lf2c