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

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

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

  1. debuginfo 패키지 설치
  2. , 및 유사한 항목을 사용 vim하여 rpm을 다시 빌드하고 설치합니다 .CFLAGSCXXFLAGSLDFLAGS-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
...

관련 정보