2014-12-09 2 views
6

Windows (x86_64-w64-mingw32) 용 Linux (x86_64-pc-linux-gnu)에서 응용 프로그램을 크로스 컴파일하기 위해 GCC 4.9.2를 사용하려고합니다.정의되지 않은 참조 GCC에서 LTO를 사용하여 정적 라이브러리를 교차 컴파일

정적 라이브러리를 링크하는 대상을 빌드 할 때 링크 타임 최적화를 사용하면 대상이 라이브러리에서 사용하는 모든 심볼에 대해 링커에서 정의되지 않은 참조 오류가 발생합니다.

예를 들어, bar.cpp

int bar (void) {return 42;} 

에서 bar.a을 구축하고 오류

에서

x86_64-w64-mingw32-g++ -flto -o foo.o -c foo.cpp 
x86_64-w64-mingw32-g++ -flto -o bar.o -c bar.cpp 
x86_64-w64-mingw32-gcc-ar rc bar.a bar.o 
x86_64-w64-mingw32-gcc-ranlib bar.a 
x86_64-w64-mingw32-g++ -flto -fuse-linker-plugin foo.o bar.a -o foo 

결과 명령 줄을 사용하여 foo.cpp에

extern int bar (void); 
int main (int, char**) {bar();} 

와 연결

/tmp/ccc3Twsc.lto.o:foo.o:(.text+0x15): undefined reference to `bar()' 
collect2: error: ld returned 1 exit status 

위부터 :

  • 나는
  • 모든 파일이 동일한 옵션을 사용하여 컴파일 된 외부 의존성이없는
  • AR/ranlib가에 대한 GCC-래퍼를 사용하고

내가 가진 -fuse-linker-plugin, gcc-ar vs ar, 기호 표시 옵션, 최적화 등의 다양한 조합을 사용하여 시도했지만 LTO를 끄지 않고 올바르게 링크 할 수는 없습니다.

모든 대상은 네이티브 컴파일러 (x86_64 Linux)에서 올바르게 빌드됩니다.

여기에 분명한 사실이 있습니까?

답변

1

Win7 64 비트에서 Mingw32-gcc 4.9.2에서이 링크 문제를 재현 할 수 있습니다. 그러나 해결 방법으로 -ffat-lto-objects을 추가하여 성공적으로 연결되었습니다 :

+4

주셔서 감사합니다. 불행히도 -ffat-lto-objects를 사용하면 링커에서 표준 연결 방법으로 폴백 할 수 있으며 많은 편의 라이브러리를 사용하여 내 용도로 LTO를 다소 부정 할 수 있습니다. – dcro

+3

또한 'ar'이 LTO/GIMPLE 객체 섹션을 이해하지 못하기 때문에'gcc-ar' ('ar'과 반대)은 필수 조건이 될 것입니다. 'gcc- {ar, ranlib, nm}'은 관련 섹션을 보존/이해하는 임시 래퍼입니다. – dcro

관련 문제