첫날

몇 가지 오류가 발생했고 일부 충돌이 있어 빌드가 실패했습니다. 그래서 연결 과정에서 치명적인 오류를 일으키는 .o 파일을 만드는 것이 불가능하다고 생각합니다. 누구든지 단계별 문제 해결 팁을 얻을 수 있습니까?

Red Hat 6을 새로 설치하여 이 작업을 성공적으로 수행했으므로 누군가 커널을 업데이트했지만 커널 라이브러리는 업데이트하지 않은 것 같습니다. 어디서 확인해야 하는지 팁이 필요합니다

들어가 rpm -qa보니 2개의 코어가 있는 것으로 나타났습니다. 이전 코어로 부팅하고 LiS 컴파일을 시도했지만 도움이 되지 않았습니다.

나는 다음과 같이 내 문제를 분석합니다.

1. 커널 라이브러리와 커널 버전이 일치하는지 확인하는 방법은 무엇입니까?
   아이디어: dlevel, 커널, gcc, glib, glibc...
2. 빌드 문제를 해결하기 위한 체크리스트와 같은 일반적인 단계가 있습니까? 그러니 하나씩 확인하시면 됩니다. LiS 설치는 여러 라이브러리에 대한 최소 수준 요구 사항을 제공하므로 모든 요구 사항을 충족한다고 확신하며 이제 패치를 통과한 것 같습니다.
3. 파일 버전을 낮출 수 있나요? 그럼 각 라이브러리가 요구 사항을 충족하도록 만들면 될까요? 그리고 100% 호환됩니다.

2일차 진행

@schaiba의 몇 가지 팁에 따라 컴파일 중에 로깅을 수행하는 방법을 살펴보았습니다.

그리고 빌드 패키지를 입력하고 두 번째 폴더에서 빌드 strconf를 추적하고 cc 컴파일에 --verbose를 추가한 후 다음 메시지를 받았습니다.
충돌하는 라이브러리를 무시합니다 /usr/lib64/libc.so. 작은 파일이므로 vi로 열려고 했습니다. 따라서 유사한 명령문이 포함된 텍스트 파일인 것으로 나타났습니다 OUTPUT FORMAT (elf32-i386). lib64는 x86_64여야 하므로 이는 분명히 잘못된 것입니다.
그런 다음 다음을 통해 libc.so가 어디에서 오는지 확인하기로 결정했습니다.

rpm -qf libc.so  

그것이 glibc-devel-....에 있다는 것을 알았습니다. 저는 Red Hat 6.4 저장소를 가지고 있고 지금 하고 있습니다.

yum update glibc-devel

그러면 장난꾸러기 libc.so는 OUTPUT FORMAT(elf64-x86-64)strconf 모듈 컴파일이 됩니다. 빌드를 마쳤습니다.

하지만 이제 다른 질문이 생겼습니다. 여전히 충돌하는 libc.so 경고가 무시되고 있으며, 제가 구축한 LiS가 실제로 다른 응용 프로그램에서 사용되고 있는데 해당 응용 프로그램에 몇 가지 문제가 있는 것 같습니다.

어떤 제안이 있으십니까?

인터넷에 대한 또 다른 조사에 따르면 LiS 패키지는 32비트 기본이므로 32비트에서 컴파일해야 하는 코드 부분이 있을 수 있으므로 2가지 새로운 질문이 발생합니다.

1. 동일한 라이브러리의 두 버전을 모두 사용할 수 있도록 빌드 파일을 어떻게 수정합니까?

2. Linux 시스템에서 두 가지 버전의 devel을 공존시킬 수 있는 방법이 있습니까? 더 정확하게 말하면 /usr/lib64/libc.so의 2개 버전입니다.