▶ Compile 관련 사항(AIX)

   주의 : 컴파일러, 링커에서는 OBJECT_MODE=32_64 를 허용하지 않는다. 환경변수를 이와 같이 설정하면 다음과 같은 에러가 발생한다.
          1501-254 OBJECT_MODE=32_64 is not a valid setting for the compiler.

   주의 : 디폴트 모드를 결정하기 위해 OBJECT_MODE를 사용하고 있는 것을 일반 사용자가 모르고 있다면 심각한 문제가 발생할 수 있다. 예를 들어 OBJECT_MODE가 64bit로 설정되어 있을 때 사용자가 64bit로 설계되지 않은 프로그램을 컴파일한다면 자동으로 64bit 코드가 생긴다. 따라서 컴파일하기 전 사용자는 반드시 OBJECT_MODE를 검사해야 하고 자기가 의도한 모드로 설정되어 있는지 확인해야 한다.

   주의 : (ar, dump, lorder, nm, ranlib, size, strip) 명령어는 모두 OBJECT_MODE 환경변수를 참고한다. 그러나 -X 옵션으로 지정한 값이 더 우선순위가 높다.

   주의 : libc.a 같은 표준 C 라이브러리는 컴파일러 드라이버가 디폴트로 링크할 수 있도록 /etc/vac.cfg 환경파일에 이미 정의해 두었다. 따라서 특별한 경우를 제외하고는 일부러 -lc 로 libc.a 라이브러리를 지정할 필요가 없다.

   주의 : 만약 기존의 libfoo.a 라이브러리가 없었다면 위 명령은 libfoo.a 라이브러리를 새로 만들고 여기에 foo1.o, foo2.o, foo3.o 오브젝트의 복사본을 넣는다. 그러나 기존의 libfoo.a 라이브러리가 이미 있었다면 이 명령은 라이브러리 내에 함수 정의나 변수가 겹치는지 검사하지 않은 채로 기존의 라이브러리 뒤에 오브젝트 파일을 추가한다. -v 옵션은 verbose 옵션이며 ar 명령이 진행되는 상태를 보여준다.

   주의 : 지금까지 설명한 라이브러리와 오브젝트는 모두 정적(static)파일이며 공유되지 않는 형태이다. 공유 오브젝트 파일이나 라이브러리는 이와 다른 방식으로 만들게 되며 다루는 방식도 다르다.

   주의 : AIX에서도 다른 UNIX OS처럼 파일확장자가 "so"인 공유 오브젝트를 지원하며 이 파일은 실시간 링킹에 사용된다.

   주의 : 공유 오브젝트나 라이브러리는 모든 사용자가 읽을 수 있어야 한다. 그렇지 않으면 전용 공유 오브젝트 (private shared object)로 다루게 된다.

   주의 : /tmp/libc.a 파일을 제거하면 이 파일에 대한 참조정보는 실행파일의 XCOFF 헤더에 정적으로 저장되어 있으므로 다음과 같은 에러가 발생한다.
          exec(): 0509-036 Cannot load program ./a.out because of the following errors:
          0509-150 Dependent module /tmp/libc.a(shr.o) could not be loaded.
          0509-022 Cannot load module /tmp/libc.a(shr.o).
          0509-026 System error: A file or directory in the path name does not exist.

   주의 : 공유 오브젝트나 라이브러리를 만들 때 그리고 실행파일을 만들 때 optional path component 값이 없는 편이 좋다. 연관성 있는 모듈을 찾을 때 엉뚱한 파일을 찾을 위험성이 있기 때문이다.

   주의 : 공유 오브젝트와 라이브러리는 실행파일의 XCOFF 로더 헤더섹션에 다른 선택적 경로정보(optional path component)를 가지고 있으면 안 된다.

   주의 : 런타임 링킹이 아니라면, 링커 명령에서 지정한 오브젝트나 라이브러리의 순서는 중요하지 않다.

   주의 : 링커옵션 -bnoipath는 결과 모듈에 파일경로 이름이 포함되지 않도록 한다. 디폴트 옵션은 -bipath이며, 파일경로에 관한 정보를 포함한다.

   주의 : root가 아닌 사용자가 setuid, setgid가 설정된 실행파일을 수행하면 실행파일의 헤더섹션에 기록되어 있는 디렉토리만 검색하고 LIBPATH값에 저장된 디렉토리 값은 무시한다. LIBPATH값을 지정해줘도 역시 이 값을 무시한다.

   주의 : 공유 오브젝트와 라이브러리는 XCOFF 로더 헤더 섹션에 LIBPATH 환경변수에서 지정한 추가 경로값 정보를 가지고 있으면 안 된다.

   주의 : 실행파일을 수행할 때 시스템 로더가 공유 오브젝트를 찾지 못하면, 다음과 비슷한 에러메시지가 나올 것이다.
          exec(): 0509-036 Cannot load program ex1 because of the following errors:
          0509-022 Cannot load library libone.so.
          0509-026 System error: A file or directory in the path name does not exist.

   주의 : 실행파일과 호환되지 않는 버전의 공유 오브젝트를 사용하면 이런 경우가 발생할 수 있다.
          exec(): 0509-036 Cannot load program ./example because of the following errors:
          0509-023 Symbol func1 in ex1 is not defined.
          0509-026 System error: Cannot run a file that does not have a valid format.

   주의 : 공유 오브젝트가 아닌 오브젝트나 아카이브 멤버는 -bdynamic 옵션에 상관없이 정적으로 링크된다.

   주의 : 실행파일을 만들 때 런타임 링커 (-brtl 옵션 사용)를 지정하지 않은 경우에만 lazy loading이 동작한다. 참조하는 모듈정보가 모두 함수호출일 때만 모듈을 lazy loading 방식으로 로드할 수 있다. 만약 모듈 내의 변수를 참조하는 경우라면, 모듈은 정상적인 방법으로 로드된다.

   주의 : 공유 오브젝트나 공유 아카이브 멤버를 정적으로 링크하는 방법은 64bit 개발환경에서 지원하지 않는다.

   주의 : 실행파일을 만들 때 런타임 링커 (-brtl 옵션 사용)를 지정하지 않은 경우에만 lazy loading이 동작한다. 참조하는 모듈정보가 모두 함수호출일 때만 모듈을 lazy loading 방식으로 로드할 수 있다. 만약 모듈 내의 변수를 참조하는 경우라면, 모듈은 정상적인 방법으로 로드된다.

   주의 : AIX에서는 런타임 링킹을 사용한다고 하더라도, 연기된(deferred) 심볼19을 제외한 모든 심볼은 프로그램을 로드할 때 해석해야 한다. 그러나 다른 UNIX OS에서는 함수심볼 해석을 실제 함수를 호출할 때까지 연기하는 경우가 있다.(변수참조는 로드할 때 해석된다.) 이 경우 심볼을 참조하는 모듈이 로드된 다음 함수정의가 로드된다.

   주의 : 컴파일러 드라이버도 -G 옵션이 있다. 오브젝트 파일로 런타임 링킹 공유 오브젝트를 만들 때 컴파일러의 -G 옵션을 사용하지 마시오.

   주의 : 프로그램을 실행하면 의존하는 모듈인 func1.so를 시스템 로더가 찾을 수 없기 때문에 프로그램은 다음과 같은 에러메시지를 내보내며 수행되지 않는다
          exec(): 0509-036 Cannot load program ./a.out because of the following errors:
          0509-150 Dependent module func1.so could not be loaded.
          0509-022 Cannot load module func1.so.
          0509-026 System error: A file or directory in the path name does not exist.

   주의 : -brtl 옵션없이 실행파일을 컴파일하면, 의존 모듈 목록에 func2.so가 포함되지 않는다.

   주의 : 실행파일 헤더에 기록된 런타임 링킹 공유 오브젝트의 순서는 실행파일을 만들 때 링커 명령어에서 오브젝트를 지정한 순서와 동일하다.
          $ cc main.c func1.so func2.so func3.so -brtl

   주의 : AIX에서 dlopen()이 넘긴 핸들은 dlopen()의 인스턴스에 한정되어 있다. 따라서 dlclose()는 핸들이 참조하는 오브젝트의 인스턴스만을 close할 수 있다.

   주의 : dlerror() 서브루틴은 thread-safe 가 아니다.

   주의 : 에러 메시지는 타겟이 되는 공유 오브젝트를 사용하는 중이며 시스템 공유 라이브러리 세그먼트로 파일이 로드 되었음을 보여주고 있다.
          # make libone.so
          cc -O -c source1.c
          cc -berok -G -o libone.so source1.o
          ld: 0711-851 SEVERE ERROR: Output file: libone.so
          The file is in use and cannot be overwritten.
          make: 1254-004 The error code from the last command is 12.

   주의 : slibclean 명령을 사용하려면 root 권한이 있어야 한다.

   주의 : -bexpall 링커 옵션을 사용하면 2번과 4번 과정은 필요 없다. 그러나 이 옵션을 사용하면 심볼 반출 상황에 대해 정확히 통제할 수 없다.

   주의 : 어떤 심볼을 반출할 지의 여부를 정확하게 통제하지 않아도 된다면, 2번째 과정을 건너뛰고 3번째 과정에서 다음과 같은 명령을 사용하면 된다.
          $ cc -o shrobj.o source1.o source2.o -bexpall -bM:SRE -bnoentry

   주의 : 여러 상호 의존하는 공유 오브젝트를 만드는 것보다는 가능하면 파일 한 개로 자신을 포함한 공유 오브젝트를 만드는 편이 좋다. 이 편이 좀더 간단하고 어플리케이션의 성능저하를 막을 수 있다.

   주의 : 두 경우 모두, 필요로 하는 공유 오브젝트와 라이브러리가 실제 서비스 환경에서 /product/lib (혹은 /usr/lib 나 /lib)디렉토리에 있어야 한다.

   주의 : 관계된 모듈의 파일 경로에 대해 쓸데없는 의존관계가 발생할 수 있기 때문에, 공유 오브젝트, 라이브러리를 만들 때나 실행파일을 만들 때 다른 선택적 경로값(optional path component)을 두지 않는 편이 좋다.

   주의 : 관계된 모듈의 파일 경로에 대해 쓸데없는 의존관계가 발생할 수 있기 때문에, 공유 오브젝트, 라이브러리를 만들 때나 실행파일을 만들 때 다른 선택적 경로값(optional path component)을 두지 않는 편이 좋다.

   주의 : 다른 사용자의 라이브러리 읽기 허가를 제한하면, 라이브러리 내의 모든 공유 아카이브 멤버도 읽기 허가가 제한된(private) 상태가 된다.

   주위 : Solaris, HP/UX, Linux에서는 에러 메시지 없이 컴파일되는데 AIX에서 다음과 같은 에러 메시지를 내보내며 컴파일이 안 된다.
          "test.c", line 3.5: 1506-009 (S) Bit-field test1 must be of type signed int, unsigned int or int.
          비트필드로 'unsigned char'를 사용할 수 없기 때문에 대신 'unsigned int'를 사용해야 한다.