Program Club

x86_64에서 정적 라이브러리를 컴파일 할 때 gcc가 암시 적으로 -fPIC 플래그를 제공하지 않는 이유

proclub 2020. 12. 9. 20:54
반응형

x86_64에서 정적 라이브러리를 컴파일 할 때 gcc가 암시 적으로 -fPIC 플래그를 제공하지 않는 이유


정적 라이브러리에 대해 정적으로 연결되는 공유 객체를 컴파일하는 데 많은 문제가있었습니다. 이 문제는 x84_64 플랫폼에서만 나타납니다. x86_32에서 동일한 컴파일 작업을 할 때 아무런 문제가 없습니다.

아마도 이것은 OS 특정 GCC 구성 일이지만 내 연구에 따르면 GCC가 x86_64 플랫폼에서 작동하는 방식이 나타납니다. 어쨌든 Ubuntu 10.04 x86_64에서 gcc 4.4.3을 사용하고 있습니다.

문제는 어떻게 해결됩니까? ... 모든 정적 라이브러리 종속성이 -fPIC로 컴파일되었는지 확인합니다.

질문 1 : -fpic과 -fPIC의 차이점은 무엇입니까 (분명히 -fPIC가 x86에서 더 많은 명령을 생성 함)? x86_64 컨텍스트에서 나중 유형이 더 관련성이 높은 이유는 무엇입니까?

질문 2 : 정적 코드에 링크 할 때 링크 타임에 함수를 바이너리에 하드 와이어 링하는 것으로 가정합니다. "위치 독립 코드"기계가 제공하는 간접 수준이 필요한 이유는 무엇입니까?

질문 3 : 이제 x86이 정적 아카이브에 대해 공유 객체를 링크하기 위해 -fpic / -fPIC가 필요하지 않은 경우 x86_64에서 왜 필요한가요?

질문 4 : 필요한 경우에도 왜 암시 적으로 제공되지 않습니까? 큰 변화는 안된다고 생각 했어


  1. 질문 3544035를 참조하십시오 . 또한 논의 여기있다 .
  2. 정적 라이브러리의 용도에 따라 다릅니다. 프로그램으로 만 연결하려는 경우 PIC 코드가 필요하지 않습니다 (예를 들어 libtool은 편리한 라이브러리를 호출합니다. 왜냐하면 코드 없이는 거의 할 수 있기 때문에 컴파일 프로세스를 합리적인 크기로 만드는 데 도움이됩니다). 그렇지 않고 공유 라이브러리를 링크하려는 경우 정적 라이브러리에 PIC 코드가 필요합니다.
  3. 질문 3146744여기를 참조 하십시오.
  4. 그것은 당신의 코드를 부풀리기 때문에 기본값이 아닙니다. 한 가지 확인해야 할 점은 단일 객체 파일을 컴파일 할 때 GCC에서 공유 라이브러리를 만들지 여부를 알지 못한다는 것입니다. 대부분의 소규모 프로젝트에서는 두 개의 개체 파일을 함께 연결하기 만하면되며 예를 들어 PIC 코드가 필요하지 않습니다.

또한 제 조언은 다음과 같습니다. 만약 당신이 그것에 대해 걱정할 필요가 있다면, 당신은 그것을 잘못하고있는 것입니다 (또는 당신은 어려운 방법을 배우고 싶어합니다. 이것은 경험에서 더 많은 것을 얻을 수 있기 때문에 좋습니다). 컴파일 시스템 (libtool, cmake, 무엇을 사용하든)은이를 수행해야합니다.

참고 URL : https://stackoverflow.com/questions/3961446/why-does-gcc-not-implicitly-supply-the-fpic-flag-when-compiling-static-librarie

반응형