Liên kết libstdc ++ tĩnh: bất kỳ lỗi nào?

Tôi cần triển khai ứng dụng C ++ được xây dựng trên Ubuntu 12.10 với libstdc ++ của GCC 4.7 cho các hệ thống chạy Ubuntu 10.04, đi kèm với phiên bản libstdc ++ cũ hơn đáng kể.

Hiện tại, tôi đang biên dịch -static-libstdc++ -static-libgcc, theo đề xuất của bài đăng trên blog này: Liên kết tĩnh libstdc ++ . Tác giả cảnh báo không sử dụng bất kỳ mã C ++ nào được tải động khi biên dịch tĩnh libstdc ++, đây là điều tôi chưa kiểm tra. Tuy nhiên, mọi thứ dường như vẫn diễn ra suôn sẻ cho đến nay: Tôi có thể sử dụng các tính năng C ++ 11 trên Ubuntu 10.04, đó là những gì tôi đã làm.

Tôi lưu ý rằng bài báo này là từ năm 2005, và có lẽ đã thay đổi nhiều kể từ đó. Lời khuyên của nó vẫn còn hiện tại? Có bất kỳ vấn đề tiềm ẩn nào tôi nên biết không?

Bài đăng trên blog đó là khá không chính xác.

Theo như tôi biết thì những thay đổi về C ++ ABI đã được đưa ra với mọi bản phát hành chính của GCC (tức là những thay đổi có thành phần số phiên bản thứ nhất hoặc thứ hai khác nhau).

Không đúng. Các thay đổi C ++ ABI duy nhất được giới thiệu kể từ GCC 3.4 đã tương thích ngược, có nghĩa là C ++ ABI đã ổn định trong gần chín năm.

Để làm cho vấn đề tồi tệ hơn, hầu hết các bản phân phối Linux lớn đều sử dụng ảnh chụp nhanh GCC và / hoặc vá các phiên bản GCC của chúng, khiến bạn hầu như không thể biết chính xác phiên bản GCC nào mà bạn có thể xử lý khi phân phối tệp nhị phân.

Sự khác biệt giữa các phiên bản vá lỗi của bản phân phối của GCC là nhỏ và ABI không thay đổi, ví dụ như Fedora's 4.6.3 20120306 (Red Hat 4.6.3-2) ABI tương thích với các bản phát hành FSF 4.6.x ngược dòng và gần như chắc chắn với bất kỳ 4.6 nào. x từ bất kỳ bản phân phối nào khác.

Trên GNU / Linux, các thư viện thời gian chạy của GCC sử dụng lập phiên bản ký hiệu ELF để dễ dàng kiểm tra các phiên bản ký hiệu mà các đối tượng và thư viện cần và nếu bạn libstdc++.socung cấp các ký hiệu đó thì nó sẽ hoạt động, không thành vấn đề nếu đó là một phiên bản vá lỗi hơi khác từ một phiên bản khác của bản phân phối của bạn.

nhưng không có mã C ++ nào (hoặc bất kỳ mã nào sử dụng hỗ trợ thời gian chạy C ++) có thể được liên kết động nếu điều này hoạt động.

Điều này cũng không đúng.

Điều đó nói rằng, liên kết tĩnh đến libstdc++.alà một lựa chọn cho bạn.

Lý do nó có thể không hoạt động nếu bạn tải động một thư viện (bằng cách sử dụng dlopen) là các ký hiệu libstdc ++ mà nó phụ thuộc vào có thể không được ứng dụng của bạn cần khi bạn (tĩnh) liên kết nó, vì vậy những ký hiệu đó sẽ không có trong tệp thực thi của bạn. Điều đó có thể được giải quyết bằng cách liên kết động thư viện được chia sẻ với libstdc++.so(dù sao cũng là điều nên làm nếu tùy thuộc vào nó.) Sự xen kẽ biểu tượng ELF có nghĩa là các biểu tượng có trong tệp thực thi của bạn sẽ được sử dụng bởi thư viện được chia sẻ, nhưng những người khác thì không hiện trong tệp thực thi của bạn sẽ được tìm thấy trong bất kỳ libstdc++.sotệp nào liên kết đến. Nếu ứng dụng của bạn không sử dụng, dlopenbạn không cần quan tâm đến điều đó.

Một tùy chọn khác (và tùy chọn tôi thích hơn) là triển khai phiên bản mới hơn libstdc++.socùng với ứng dụng của bạn và đảm bảo nó được tìm thấy trước hệ thống mặc định libstdc++.so, điều này có thể được thực hiện bằng cách buộc trình liên kết động tìm đúng chỗ, hoặc sử dụng $LD_LIBRARY_PATHbiến môi trường khi chạy- thời gian hoặc bằng cách đặt một RPATHtrong tệp thực thi tại thời điểm liên kết. Tôi thích sử dụng hơn RPATHvì nó không dựa vào môi trường được thiết lập chính xác để ứng dụng hoạt động. Nếu bạn liên kết ứng dụng của mình với '-Wl,-rpath,$ORIGIN'(lưu ý các dấu nháy đơn để ngăn trình bao cố gắng mở rộng $ORIGIN) thì tệp thực thi sẽ có một RPATHtrong số $ORIGINđó yêu cầu trình liên kết động tìm kiếm các thư viện được chia sẻ trong cùng thư mục với tệp thực thi. Nếu bạn đặt cái mới hơnlibstdc++.sotrong cùng thư mục với tệp thực thi, nó sẽ được tìm thấy tại thời điểm chạy, vấn đề đã được giải quyết. (Một tùy chọn khác là đưa tệp thực thi vào /some/path/bin/và libstdc ++ mới hơn. Vì vậy, vào /some/path/lib/và liên kết với '-Wl,-rpath,$ORIGIN/../lib'hoặc bất kỳ vị trí cố định nào khác liên quan đến tệp thực thi và đặt RPATH liên quan đến $ORIGIN)

Một bổ sung cho câu trả lời xuất sắc của Jonathan Wakely, tại sao dlopen () lại có vấn đề:

Do nhóm xử lý ngoại lệ mới trong GCC 5 (xem PR 64535 và PR 65434 ), nếu bạn dlopen và dlclose một thư viện được liên kết tĩnh với libstdc ++, bạn sẽ bị rò rỉ bộ nhớ (của đối tượng nhóm) mỗi lần. Vì vậy, nếu có bất kỳ cơ hội nào bạn sẽ sử dụng dlopen, có vẻ như là một ý tưởng thực sự tồi khi liên kết tĩnh libstdc ++. Lưu ý rằng đây là một rò rỉ thực sự trái ngược với rò rỉ lành tính được đề cập trong PR 65434 .

Phần bổ sung cho câu trả lời của Jonathan Wakely về RPATH:

RPATH sẽ chỉ hoạt động nếu RPATH được đề cập là RPATH của ứng dụng đang chạy . Nếu bạn có một thư viện liên kết động với bất kỳ thư viện nào thông qua RPATH của chính nó, RPATH của thư viện sẽ bị ghi đè bởi RPATH của ứng dụng tải nó. Đây là một vấn đề khi bạn không thể đảm bảo rằng RPATH của ứng dụng giống với RPATH của thư viện của bạn, ví dụ: nếu bạn mong đợi các phần phụ thuộc của mình nằm trong một thư mục cụ thể, nhưng thư mục đó không phải là một phần của RPATH của ứng dụng.

Ví dụ: giả sử bạn có một ứng dụng App.exe có phần phụ thuộc được liên kết động vào libstdc ++. So.x cho GCC 4.9. App.exe có sự phụ thuộc này được giải quyết thông qua RPATH, tức là

App.exe (RPATH=.:./gcc4_9/libstdc++.so.x)

Bây giờ, giả sử có một thư viện khác Dependency.so, có phụ thuộc được liên kết động vào libstdc ++. So.y cho GCC 5.5. Sự phụ thuộc ở đây được giải quyết thông qua RPATH của thư viện, tức là

Dependency.so (RPATH=.:./gcc5_5/libstdc++.so.y)

Khi App.exe tải Dependency.so, nó sẽ không thêm vào hoặc thêm vào trước RPATH của thư viện . Nó không tham khảo nó ở tất cả. RPATH duy nhất được coi là của ứng dụng đang chạy hoặc App.exe trong ví dụ này. Điều đó có nghĩa là nếu thư viện dựa vào các ký hiệu có trong gcc5_5 / libstdc ++. So.y nhưng không phải trong gcc4_9 / libstdc ++. So.x, thì thư viện sẽ không tải được.

Đây chỉ là một lời cảnh báo, vì tôi đã từng gặp phải những vấn đề này trong quá khứ. RPATH là một công cụ rất hữu ích nhưng việc triển khai nó vẫn còn một số lỗi.

Bạn cũng có thể cần đảm bảo rằng bạn không phụ thuộc vào glibc động. Chạy lddtrên tệp thực thi kết quả của bạn và lưu ý bất kỳ phụ thuộc động nào (libc / libm / libpthread là những nghi ngờ đã sử dụng).

Bài tập bổ sung sẽ là xây dựng một loạt các ví dụ C ++ 11 có liên quan bằng cách sử dụng phương pháp này và thực sự thử các tệp nhị phân kết quả trên hệ thống 10.04 thực. Trong hầu hết các trường hợp, trừ khi bạn làm điều gì đó kỳ lạ với tải động, bạn sẽ biết ngay chương trình có hoạt động hay không hay nó bị treo.

Tôi muốn thêm vào câu trả lời của Jonathan Wakely phần sau.

Chơi xung quanh -static-libstdc++linux, tôi đã phải đối mặt với vấn đề dlclose(). Giả sử chúng ta có một ứng dụng 'A' được liên kết tĩnh libstdc++và nó tải được liên kết động với libstdc++plugin 'P' trong thời gian chạy. Tốt rồi. Nhưng khi 'A' dỡ 'P', lỗi phân đoạn xảy ra. Giả định của tôi là sau khi dỡ bỏ libstdc++.so, 'A' không còn có thể sử dụng các ký hiệu liên quan đến libstdc++. Lưu ý rằng nếu cả 'A' và 'P' được liên kết tĩnh libstdc++hoặc nếu 'A' được liên kết động và 'P' tĩnh, sự cố sẽ không xảy ra.

Tóm tắt: nếu ứng dụng của bạn tải / dỡ các plugin có thể liên kết động đến libstdc++, ứng dụng cũng phải được liên kết động với nó. Đây chỉ là quan sát của tôi và tôi muốn nhận được ý kiến ​​của bạn.