Which dynamic (shared) library shall I look up at the execution time.
-loptions to tell where a library locates and which library to be linked. Actually, these options are passed to
ld. However, here I will tell you them as
There are two ways to determine a library path for execution time.
LD_RUN_PATH. For example,
setenv LD_RUN_PATH /usr/X11R6/lib64 (for csh) export LD_RUN_PATH=/usr/X11R6/lib64 (for bash)
-R. Actually, gcc 3.2 info seems to be mistaken. I've succeeded with next way (Gcc 3.2.1).
g++ --rpath=/usr/X11R6/lib64 ... g++ -R/usr/X11R6/lib64 ... g++ -Wl,rpath,/usr/X11R6/lib64 ...
One weird thing is that these options depend on environment. (gcc 3.2.1) I've tested this on Linux 2.4 (Woddy) and SunOS 5.9.
--rpath: Linux, SunOS (both are ok.)
-R: only SunOS
-Wl,rpath: only Linux
LD_LIBRARY_PATH. For example,
setenv LD_LIBRARY_PATH /usr/X11R6/lib64:/usr/local/lib64 (for csh) export LD_LIBRARY_PATH=/usr/X11R6/lib64:/usr/local/lib64 (for bash)
This is somehow convenient, but it also includes security problem. Please take care.
C/C++for me. Even you succeed to compile your code, you can not run when you mistook the library path. This is powerful, but it is really not intuitive.)
How can I build a 64 bit executable?
-m64option at command line. For example,
g++ -m64 a.cc
This looks easy, however, you should care about the library path. First you must sure which version of library (32 bit/64 bit) you will use. The problems arise this point. This is why I start the story of Run path. The library directory names are not consistent system by system, sometimes even depends on software (e.g., /usr/lib/lib*64.a). The name lib64 is one good starting point to look for. I found some systems start to use (lib32, lib64) instead of (lib, lib64).
g++ -m64 -fPIC a.cc .Since this option specifies dynamic linking ability and also avoiding any limit on the size of the global offset table. Although -fPIC option is environment dependent, however, SunOS, IRIX and Linux environments accept this.