gcc memo

Gcc memo

Run path.
Which dynamic (shared) library shall I look up at the execution time.
64 bit address.
How can I build a 64 bit executable?
How can I know I am in the 64 bit address environment?

Run path.

Which dynamic (shared) library shall I look up at the execution time.

At the compile time, gcc employs -L and -l options 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 gcc options.
There are two ways to determine a library path for execution time.
- Compile time: There are also two ways to tell this to gcc (ld).
  - Using Environment variable LD_RUN_PATH. For example,
```
	setenv LD_RUN_PATH /usr/X11R6/lib64 (for csh)
	export LD_RUN_PATH=/usr/X11R6/lib64 (for bash)
	       
```
  - Using command line option --rpath or -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
- Execution Time: When you do not use above compile time options, you can specify the library path through 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.
(However, this link related issue is one large difficulty of 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.)

64 bit address.

How can I build a 64 bit executable?

Put -m64 option 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).
- Debian Linux : lib64, lib, (/amd64/usr/lib64, /amd64/lib64, /amd64/lib) in opteron system
- SuSE Linux : /usr/lib64
- IRIX64 : lib64
- SunOS : sparcv9, lib64
Also, -fPIC option (generate position independent code) helps in many cases. Try
```
     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.

How can I know I am in the 64 bit address environment?

It seems no chance for me except runtime detection. There are many headers which tell the size, e.g. inttypes.h, sys/types.h, limits.h, stdint.h. bits/wordsize.h (this seems not so common yet) tells it but only somehow. In environment dependent way,
- Linux: macro __WORDSIZE (= 32 or 64)
- IRIX: macro _MIPS_SZPTR (= 32 or 64)
- SunOS: macro _LP64 (defined of not, if defined long and pointer are 64 bit.)
- Just that! --- Marvin.
In runtime environment, just use sizeof(int) and sizeof(int *). I think this is a (presumably the) good way.
- Linux : (only int pointer size) include <stdint.h> and type intptr_t has the same size of pointer of int. It is usually LP64 model, then actually it is long int.