![Fedora 버전을 업그레이드할 때 기본 소프트웨어 빌드에 어떤 유형의 문제가 발생할 수 있습니까? 해결책은 무엇입니까? [폐쇄]](https://linux55.com/image/185018/Fedora%20%EB%B2%84%EC%A0%84%EC%9D%84%20%EC%97%85%EA%B7%B8%EB%A0%88%EC%9D%B4%EB%93%9C%ED%95%A0%20%EB%95%8C%20%EA%B8%B0%EB%B3%B8%20%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%20%EB%B9%8C%EB%93%9C%EC%97%90%20%EC%96%B4%EB%96%A4%20%EC%9C%A0%ED%98%95%EC%9D%98%20%EB%AC%B8%EC%A0%9C%EA%B0%80%20%EB%B0%9C%EC%83%9D%ED%95%A0%20%EC%88%98%20%EC%9E%88%EC%8A%B5%EB%8B%88%EA%B9%8C%3F%20%ED%95%B4%EA%B2%B0%EC%B1%85%EC%9D%80%20%EB%AC%B4%EC%97%87%EC%9E%85%EB%8B%88%EA%B9%8C%3F%20%5B%ED%8F%90%EC%87%84%5D.png)
저는 많은 소프트웨어 테스트를 수행하므로 소스에서 다양한 프로젝트를 빌드해야 합니다. 최근에 31에서 Fedora 33으로 업그레이드했는데 본질적으로 "누락된" 종속성으로 인해 이전에 구축한 소프트웨어를 실행할 수 없거나 소프트웨어를 구축하려고 할 때 오류가 발생하는 것과 관련된 일련의 문제에 직면하고 있습니다. 패키지 또는 라이브러리가 누락되었습니다. 대부분 실행 후 ./configure또는 make많은 시간이 지나면 실제로는 아니며 의도적으로 제거되지도 않았습니다. 다른 경우에는 패키지 업데이트(예: Python 3.6 -> 3.9)로 인해 특정 스크립트 등에 문제가 발생할 수 있습니다.
가끔 혼란스러운 점은(파이썬 문제 외에도) 실제로 많은 라이브러리를 제거하지 않았고 어떤 이유로든 라이브러리가 더 이상 인식되지 않는 것 같아서 해당 라이브러리가 있는 빌드 시스템을 수동으로 표시하거나 다시 설치해야 한다는 것입니다. 의존성 등등...
Fedora 또는 기타 Linux 배포판을 업그레이드한 후 이러한 유형의 문제를 해결하기 위한 일반적인 권장 사항이 있습니까? 나는 이것이 다소 일반적이라고 생각합니다.할 수 있는물론 각각의 개별적인 문제를 사례별로 다룰 것이며, 이를 집합적인 문제로 간주하고 Linux 여정을 계속하면서 향후 업그레이드를 통해 이 문제를 더 잘 해결할 수 있기를 바랍니다.
답변1
소스 코드에서 중요하지 않은 소프트웨어를 컴파일하는 것은 복잡한 작업이 될 수 있지만 현재 대부분의 세부 사항을 숨기는 자동화된 기술이 꽤 많이 있습니다. 그러나 프로세스에서 문제가 발생했을 때, 효과적으로 문제를 해결하려면 프로세스를 이해할 수 있어야 합니다.
불행하게도, 실패한 컴파일 프로세스 문제를 해결하는 지식과 기술은 점점 "실제 소프트웨어 개발자만이 가지고 있는 것"으로 이해되고 있는 것 같습니다. 실제로는 테스터에게도 해당됩니다. 매우 필요하고 때로는 시스템 관리자에게 매우 유용합니다. 실제로 오픈소스 소프트웨어의 기본 아이디어는 다음과 같이 가정합니다.모든 사람원하는 경우 패키지를 다시 컴파일할 수 있어야 합니다.
./configure라이브러리가 부족하다고 불평할 때 일반적으로 실제로 필요한 라이브러리를 찾고 있는 경우는 다음과 같습니다.이 라이브러리의 -devel 패키지.
./configure본질적으로 패키지 컴파일을 위한 전제 조건을 찾고 확인하기 위해 여러 테스트를 실행하는 쉘 스크립트입니다. 이는 autoconf다양한 하드웨어 아키텍처 및 UNIX와 유사한 운영 체제에서 소스 코드 패키지의 컴파일을 단순화하기 위한 툴킷에 의해 생성됩니다 .
때로는 라이브러리 개발 프로젝트 또는 Linux 배포판에서 개발 헤더( 파일 *.h) 를 /usr/include/. 라이브러리 개발자가 소스 수준에서 이전 버전과 호환되지 않는 변경을 수행하는 경우 배포판이 이전 버전과 최신 버전 의 라이브러리 등을 지원할 수 있도록 라이브러리 버전 번호를 포함해야 할 수도 있습니다 . 이러한 변경 사항이 패키지 스크립트를 생성하는 데 사용된 버전 보다 최신인 경우 새 위치를 자동으로 감지하지 못할 수 있습니다./usr/include//usr/include/library_name//usr/include/library_name//usr/include/library_name2autoconf./configure
autoconf완벽하지는 않으며 이를 보완하거나 대체할 수 있는 다른 메커니즘이 있습니다. 또 다른 일반적인 경우 pkg-config: 이를 지원하는 모든 라이브러리 패키지에는 문제의 라이브러리를 사용하는 소프트웨어를 구축할 때 중요한 컴파일러 옵션, 종속성 및 동작을 문서화하는 -devel파일이 패키지(또는 이에 상응하는 것)에 포함 됩니다.*.pc
이 make단계에서는 일반적으로 실제 라이브러리 패키지와 해당 -devel패키지가 있어야 합니다. 빌드 패키지를 사용할 때 make해당 패키지의 여러 부분은 일반적으로 소스 코드에서 바이너리로 컴파일됩니다.대상 파일분리된 이러한 파일은 함께 연결되어 실행 파일을 형성합니다.
컴파일 하위 단계에서는 패키지 *.h에서 제공하는 파일 만 필요할 수 있지만 -devel링크 하위 단계에서는 실제 라이브러리 패키지가 있어야 합니다.
운영 체제 주요 버전(X+n)에서 실행하기 위해 운영 체제 주요 버전 X용으로 컴파일된 일부 소프트웨어가 필요한 경우 공유 라이브러리 문제가 발생할 수 있습니다.
- 라이브러리가 이전 버전과 호환되지 않는 변경을 겪었습니다.
- 이름 충돌이나 기타 문제를 해결하기 위해 라이브러리가 다르게 패키지되었습니다.
- 이전 라이브러리는 배포판에서 완전히 제거되었으며 이제 기능은 다른 라이브러리에서 제공되거나 완전히 다른 방식으로 제공됩니다.
이런 종류의 문제를 해결하려면 소프트웨어에 실제로 필요한 이전 라이브러리를 찾아서 일반적으로 라이브러리가 검색되지 않는 디렉터리에 넣은 다음 환경을 사용하여 라이브러리를 지정하는 래퍼 스크립트를 사용하여 이전 프로그램을 시작해야 할 수도 있습니다. LD_LIBRARY_PATH사용자 정의 검색 경로와 같은 변수이 앱에만 해당. 응용 프로그램이 런타임에 공유 라이브러리를 찾는 방법을 변경하는 방법에 대한 자세한 내용은 ld.so(8)매뉴얼 페이지, 특히 해당 장을 참조하십시오 .ENVIRONMENT
이렇게 하면 Linux 버전을 계속 실행할 수 있습니다.시드 마이어의 알파 센타우리(저작권 1999) 현재 Debian 10 시스템. 너무 초라하지는 않다고 말하고 싶습니다.
답변2
Fedora 또는 기타 Linux 배포판을 업그레이드한 후 이러한 유형의 문제를 해결하기 위한 일반적인 권장 사항이 있습니까?
- 재건축하거나
- 스냅/플랫팩으로 포장 또는
- chroot에서 실행하거나
- 가상 머신에서 실행
나는 이것이 다소 일반적이라고 생각하며 사례별로 각각의 개별 문제를 확실히 해결할 수 있지만 이것은 집합적인 문제로 간주하고 Linux 여행을 계속하면서 변경하고 싶은 사항을 고려하겠습니다. 나중에 업그레이드할 때 이 문제를 해결해 보세요.
불행하게도 이것이 Linux의 특성입니다. 새로운 배포판이 출시될 때마다 다시 빌드해야 하는 빠르게 움직이는 대상입니다. 이는 Fedora에서 제공하지 않는 소프트웨어(예: ffmpeg/mpv)를 사용하여 자주 수행하는 작업입니다.