您的位置:首页 > 其它

LibEvent的使用过程记录

2015-02-17 16:22 169 查看
The libevent APIprovides a mechanism to execute a callback function when a specific event occurs on a file descriptor or after a timeout has been reached. Furthermore, libevent alsosupport callbacks due to signals orregular timeouts.(来自官网表述)1从http://libevent.org/下载最新的源码libevent-2.0.22-stable.tar.gz编译;tar -zxvf ./libevent-2.0.22-stable.tar.gzmv libevent-2.0.22-stable ./libevent./configure --prefix=*****makemake install2.编写demo测试 略g++ ./libevent.cpp -g -O0 -levent -L /usr/local/lib./a.out: error while loading shared libraries: libevent-2.0.so.5: cannot open shared object file: No such file or directoryldd ./a.outlinux-vdso.so.1 => (0x00007fff95116000)libevent-2.0.so.5 => not foundlibstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x000000363b000000)libm.so.6 => /lib64/libm.so.6 (0x0000003638800000)libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000363ac00000)libc.so.6 => /lib64/libc.so.6 (0x0000003638c00000)/lib64/ld-linux-x86-64.so.2 (0x0000003638400000)libevent-2.0.so.5 没有找到查看位置whereis libevent-2.0.so.5libevent-2.0.so: /usr/local/lib/libevent-2.0.so.5[root@chenfeng test]# g++ ./libevent.cpp -o libevent -g -O0 -levent -L/usr/local/lib -Wl,rpath=/usr/local/lib/usr/bin/ld: rpath=/usr/local/lib: No such file: No such file or directorycollect2: ld 返回 1来自http://gcc.gnu.org/ml/gcc-help/2005-12/msg00017.html
The -L option supplies a colon-separated library path that is to be
searched at LINK TIME for libraries. Thus

cc -o foo foo.c -L/usr/local/lib -lfoo

means that either libfoo.a or libfoo.so should be found in either
/usr/local/lib, or elsewhere in the default search patch (in
GNU/Linux, the directories can be listed in /etc/ld.so.conf, and the
cache updated by running /etc/ldconfig).
Whether the .a or .so form of the library is needed is platform
dependent (e.g., IBM AIX uses only the .a form), and also dependent on
compiler options to select dynamic or static linking.  The default is
normally dynamic linking to save disk space and waste CPU time.

However, this means while that the executable foo may have been
successfully linked against a shared library, at RUN TIME, the
run-time loader looks for it in the default search path, possibly
prefixed by a colon-separated list of libraries supplied by the
LD_LIBRARY_PATH variable.

If, in our example, /usr/local/lib is not part of the default path,
then the run-time loader will not be able to find the shared library,
EVEN THOUGH LINKING SUCCEEDED (because of the -L/usr/local/lib
option).
otice the "(file not found") line.  That library is actually present
on that system in /usr/local/lib, and I can make it succeed like this:

% env -i LD_LIBRARY_PATH=/usr/local/lib ldd /usr/local/bin/emacs
libXaw3d.so.5 =>         /usr/local/lib/libXaw3d.so.5
libXmu.so.4 =>   /usr/lib/libXmu.so.4
...

Thus, when shared libraries are present in nondefault directories, you
need to supply an additional linker option, usually -R or -Wl,-rpath=,
with a run-time library path.  Our example above becomes for gcc

gcc -o foo foo.c -L/usr/local/lib -lfoo -Wl,-rpath=/usr/local/lib
In a Makefile, I would write this asgcc -o foo foo.c -L$(prefix)/lib -lfoo -Wl,-rpath=$(prefix)/lib
[root@chenfeng test]# g++ ./libevent.cpp  -o livevent -g -O0  -L/usr/local/lib -levent -Wl,-rpath=/usr/local/lib[root@chenfeng test]# ./livevent
编译通过
OK
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐