☰

RPM debuginfo 패키지와 -g와 같은 옵션을 사용하여 패키지를 다시 빌드하는 것의 차이점은 무엇입니까?

tag-icon • tag-icon package-management rpm debugging
RPM debuginfo 패키지와 -g와 같은 옵션을 사용하여 패키지를 다시 빌드하는 것의 차이점은 무엇입니까?

RPM에서 debuginfo 패키지를 사용하는 방법을 명확히 하고 싶습니다. 이 패키지가 있는데 vim충돌이 발생했다고 가정해 보겠습니다 . 이 충돌을 디버깅하고 싶지만 줄 번호 정보에 액세스할 수 없다는 오류가 gdb발생합니다 . gdb내 생각에는 두 가지 옵션이 있습니다.

  1. 디버깅 정보 패키지 설치
  2. vimCFLAGS, CXXFLAGS및 유사한 명령을 LDFLAGS사용 하여 rpm을 다시 빌드하고 설치합니다.-g3

최근에 옵션 #1을 시도했지만 여전히 gdb에 누락된 기호에 대한 일부 오류가 발생하여 debuginfo 패키지가 무엇인지, 이를 사용하는 방법에 대해 몇 가지 가정을 했을 때 문제가 발생했습니다. 위에 나열된 옵션 1과 옵션 2의 차이점을 설명해 주시겠습니까? 아니면 제가 틀렸다면 올바르게 수행하는 방법은 무엇입니까?

답변1

최근에 옵션 #1을 시도했지만 여전히 gdb에 누락된 기호에 대한 일부 오류가 발생하여 debuginfo 패키지가 무엇인지, 이를 사용하는 방법에 대해 몇 가지 가정을 했을 때 문제가 발생했습니다.

충돌은 애플리케이션 자체가 아니라 glibc 또는 vim이 의존하는 다른 라이브러리에서 발생할 수 있습니다. 이는 모든 관련 라이브러리에 대해 debuginfo 패키지를 설치해야 함을 의미합니다.

이는 또한 소스에서 vim을 빌드하면 동일한 문제가 발생할 가능성이 높다는 것을 의미합니다. 일부 디버깅 기호를 확인할 수 없습니다. 또한 패키지를 직접 빌드하는 경우 컴파일 플래그는 Fedora가 사용하는 것과 다르므로 동일한 충돌이 발생할 수도 있고 발생하지 않을 수도 있습니다.

답변2

@Artem이 맞습니다. 모든 전이적 종속성에 대한 debuginfo가 필요합니다.

그것들을 모두 찾는 것은 고통스러울 수 있습니다. ABRT( )를 사용하면 dnf install abrt쉽게 이를 달성 할 수 있습니다. 충돌이 발생하면 ABRT가 이를 기록합니다. 내 시스템의 예를 들면 다음과 같습니다.

$ abrt     
071eb9c 1x /usr/libexec/mysqld 2020-06-24 00:55:09
7552a02 1x mariadb 2020-06-26 15:37:45
$ abrt backtrace 071eb9c
Problem has no backtrace
Start retracing process? [y/N] y
Upload core dump and perform remote retracing? (It may contain sensitive data). If your answer is 'No', a stack trace will be generated locally. Local retracing requires downloading potentially large amount of debuginfo data [y/N] n
Local retracing
Analyzing coredump 'coredump'
Cleaning cache...
Cache cleaning has finished
...

관련 정보