Dễ dàng kiểm tra các ký hiệu chưa được giải quyết trong các thư viện được chia sẻ?

Question 1

Tôi đang viết một thư viện đối tượng chia sẻ C ++ khá lớn và đã gặp phải một vấn đề nhỏ khiến việc gỡ lỗi trở nên khó khăn:

Nếu tôi xác định một hàm / phương thức trong tệp tiêu đề và quên tạo sơ khai cho nó (trong quá trình phát triển), vì tôi đang xây dựng dưới dạng thư viện đối tượng được chia sẻ chứ không phải là tệp thực thi, không có lỗi nào xuất hiện tại thời điểm biên dịch cho tôi biết tôi có quên thực hiện chức năng đó. Cách duy nhất tôi phát hiện ra điều gì đó không ổn là trong thời gian chạy, khi cuối cùng một ứng dụng liên kết với thư viện này gặp lỗi 'ký hiệu không xác định'.

Tôi đang tìm một cách dễ dàng để kiểm tra xem tôi có tất cả các ký hiệu tôi cần tại thời điểm biên dịch hay không, có lẽ một số thứ tôi có thể thêm vào Makefile của mình.

Một giải pháp mà tôi đã đưa ra là chạy thư viện đã biên dịch nm -C -Uđể có được danh sách tất cả các tài liệu tham khảo không xác định được gỡ rối. Vấn đề là điều này cũng xuất hiện với danh sách tất cả các tài liệu tham khảo nằm trong các thư viện khác, chẳng hạn như GLibC, tất nhiên sẽ được liên kết với thư viện này khi ứng dụng cuối cùng được kết hợp với nhau. Có thể sử dụng đầu ra của nmđể grepthông qua tất cả các tệp tiêu đề của tôi và xem có tên nào tương ứng không .. nhưng điều này có vẻ điên rồ. Chắc chắn đây không phải là một vấn đề phổ biến và có một cách tốt hơn để giải quyết nó?

Question 2

Kiểm tra tùy chọn trình liên kết -z defs/ --no-undefined. Khi tạo đối tượng dùng chung sẽ khiến liên kết bị lỗi nếu có các ký hiệu chưa được giải quyết.

Nếu bạn đang sử dụng gcc để gọi trình liên kết, bạn sẽ sử dụng -Wltùy chọn trình biên dịch để chuyển tùy chọn đến trình liên kết:

gcc -shared ... -Wl,-z,defs

Ví dụ, hãy xem xét tệp sau:

#include <stdio.h>

void forgot_to_define(FILE *fp);

void doit(const char *filename)
{
    FILE *fp = fopen(filename, "r");
    if (fp != NULL)
    {
        forgot_to_define(fp);
        fclose(fp);
    }
}

Bây giờ, nếu bạn xây dựng nó thành một đối tượng được chia sẻ, nó sẽ thành công:

> gcc -shared -fPIC -o libsilly.so silly.c && echo succeeded || echo failed
succeeded

Nhưng nếu bạn thêm -z defs, liên kết sẽ không thành công và cho bạn biết về biểu tượng bị thiếu của bạn:

> gcc -shared -fPIC -o libsilly.so silly.c -Wl,-z,defs && echo succeeded || echo failed
/tmp/cccIwwbn.o: In function `doit':
silly.c:(.text+0x2c): undefined reference to `forgot_to_define'
collect2: ld returned 1 exit status
failed

Question 3

Trên Linux (có vẻ như bạn đang sử dụng) ldd -r a.outsẽ cung cấp cho bạn chính xác câu trả lời mà bạn đang tìm kiếm.

CẬP NHẬT: một cách đơn giản để tạo ra a.outđể kiểm tra:

 echo "int main() { return 0; }" | g++ -xc++ - ./libMySharedLib.so
 ldd -r ./a.out

Question 4

Còn testsuite thì sao? Bạn tạo các tệp thực thi giả liên kết đến các ký hiệu bạn cần. Nếu liên kết không thành công, điều đó có nghĩa là giao diện thư viện của bạn chưa hoàn chỉnh.

Question 5

Tôi đã có cùng một vấn đề một lần. Tôi đang phát triển một mô hình thành phần trong C ++, và tất nhiên, các thành phần sẽ tải động trong thời gian chạy. Tôi nghĩ đến ba giải pháp, đó là những giải pháp tôi đã áp dụng:

Dành một chút thời gian để xác định một hệ thống xây dựng có thể biên dịch tĩnh. Bạn sẽ mất một chút thời gian để thiết kế nó, nhưng nó sẽ giúp bạn tiết kiệm được nhiều thời gian để bắt những lỗi thời gian chạy khó chịu này.
Nhóm các chức năng của bạn trong các phần nổi tiếng và dễ hiểu, để bạn có thể nhóm các chức năng / sơ khai để đảm bảo rằng mỗi chức năng tương ứng đều có sơ khai. Nếu bạn dành thời gian để ghi lại nó tốt, bạn có thể viết một tập lệnh kiểm tra các định nghĩa (ví dụ: thông qua các nhận xét doxygen của nó) và kiểm tra tệp .cpp tương ứng cho nó.
Thực hiện một số tệp thực thi thử nghiệm tải cùng một bộ thư viện và chỉ định cờ RTLD_NOW thành dlopen (nếu bạn dưới * NIX). Họ sẽ báo hiệu các ký hiệu còn thiếu.

Hy vọng rằng sẽ giúp.