정적 링크와 동적 링크를 비교할 때 실행 파일에 무엇이 포함되고 실행 시 어떤 resolver가 추가로 필요하다고 설명하나요?

결론부터 말하면 정적 링크는 link editor가 필요한 object·archive 구현을 실행 image에 결합해 실행 시 해당 archive를 다시 찾지 않게 하는 방식이고, 동적 링크는 실행 파일에 shared object 의존성과 dynamic symbol·relocation 정보를 남겨 runtime linker의 추가 처리를 필요로 합니다. 예를 들어 main.o가 parse를 참조하고 libparse.a의 한 member가 정의를 제공하면 link editor가 그 member를 선택하고 image 안의 section 배치와 내부 relocation을 정리합니다. 이때 정적이라는 말은 해당 라이브러리 결합 경계를 뜻하지, startup code나 syscall 사용이 사라진다는 뜻은 아닙니다. 반대로 libparse.so를 선택하면 실행 파일에는 NEEDED 같은 의존성 정보와 동적 lookup에 필요한 심볼이 남습니다. loader가 실행 파일과 의존 object를 매핑한 뒤 runtime linker가 실제 load bias를 반영해 symbol을 찾고 relocation을 적용합니다. 라이브러리가 없거나 ABI가 맞지 않으면 link 성공 뒤 load 단계에서 실패할 수 있습니다. 같은 호출의 상태를 시간순으로 보면 archive 경로는 main.o 참조 → link 시 member 선택 → image 내부 주소 확정이고, shared object 경로는 main.o 참조 → 의존성 기록 → load → lookup/relocation → 호출입니다. 동적 링크도 relocation을 하며, 반대로 정적 링크에도 link 시점에 처리할 relocation이 있을 수 있습니다. section 이름만 보고 결론내리지 않고 readelf -d의 의존성, readelf -r의 relocation, 대상 ABI의 lookup 규칙을 함께 봅니다. gABI 일반 문서는 이 구조를 설명하지만 특정 CPU의 relocation 식과 모든 loader의 symbol 우선순위까지 보장하지 않으므로 플랫폼 범위를 명시해야 합니다.