2010-07-09 47 views
21

Tôi đang viết một ứng dụng đa nền tảng không tương thích với GNU GPL. Vấn đề chính mà tôi đang phải đối mặt là ứng dụng được liên kết động với glibc và libstdC++, và hầu như mọi cập nhật lớn mới cho các thư viện đều không tương thích ngược. Do đó, tai nạn ngẫu nhiên được nhìn thấy trong ứng dụng của tôi.Liên kết Tĩnh với glibc và libstdC++

Để giải quyết sự cố, tôi phân phối các tệp nhị phân của ứng dụng được biên dịch trên một số hệ thống khác nhau (với các phiên bản thời gian chạy C/C++ khác nhau). Nhưng tôi muốn làm mà không có điều này. Vì vậy, câu hỏi của tôi là, giữ giấy phép và tất cả mọi thứ trong tâm trí, tôi có thể liên kết chống lại glibc và libstdC++ tĩnh? Ngoài ra, điều này sẽ gây ra vấn đề với rtld?

+1

Những người bảo trì glibc và libstdC++ thực hiện một công việc tuyệt vời để duy trì tính tương thích nhị phân ngược. Các bản phát hành chính phá vỡ nó theo thiết kế, nhưng những điều đó xảy ra không quá thường xuyên. Bạn có thể giải quyết vấn đề của bạn bằng cách xây dựng các tệp nhị phân trên một hệ thống không hiện đại, hoặc bằng cách sử dụng một số công cụ LSB từ Tổ chức Linux (xem tại đây) (http://www.linuxfoundation.org/collaborate/workgroups/lsb); công cụ miễn phí; và có, tôi đã làm việc cho họ, vì vậy tôi thiên vị). –

Trả lời

9

Chỉ định tùy chọn -static-libgcc cho trình liên kết sẽ khiến nó liên kết với phiên bản tĩnh của thư viện C, nếu có trên hệ thống. Nếu không, nó sẽ bị bỏ qua.

+8

Bạn cũng cần '-static-libstdC++', xem [giải thích] (http://www.trilithium.com/johan/2005/06/static-libstdc/) – ACyclic

+6

Đây là câu trả lời * hoàn toàn * không có thật: '-static -libgcc' có * không có gì * để làm với thư viện hệ thống C. –

+0

@themoondothshine bạn nên * nghiêm túc * sửa câu trả lời này. Như đã chỉ ra bằng cách sử dụng tiếng Nga 'libgcc! = Libc' (và điều đó bất kể có nói 'libc == glibc' hay không). 'libgcc' là một thư viện thời gian chạy để hỗ trợ mã do trình biên dịch tạo ra. Đọc về nó [ở đây] (https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html). – 0xC0000022L

18

Bạn không cần.

Sao chép các thư viện gốc mà bạn đã liên kết với một thư mục (../lib trong ví dụ này) trong thư mục ứng dụng của bạn.

Giống như:

my_app_install_path

  1. .bin
  2. lib
  3. tài liệu

Đổi tên bạn ứng dụng cho cái gì đó như app.bin. Thay thế ứng dụng của bạn cho một kịch bản lệnh shell nhỏ đặt biến môi trường LD_LIBRARY_PATH thành đường dẫn thư viện (và nối các nội dung LD_LIBRARY_PATH trước đó, nếu có). Bây giờ ld sẽ có thể tìm thấy các thư viện động mà bạn đã liên kết và bạn không cần phải biên dịch chúng một cách tĩnh để thực thi.

Hãy nhớ tuân thủ LGPL thêm thuộc tính đã cho vào thư viện và chỉ trong tài liệu nơi nguồn có thể được tải xuống.

+0

@Vitor: Đây là giải pháp tốt nhất mà tôi nghĩ! Tuy nhiên, tôi phân phối tất cả các phụ thuộc của bên thứ ba (ví dụ: zlib, libssh, openssl, yada yada ...) làm thư viện được chia sẻ với gói. Yêu cầu duy nhất tôi áp đặt lên người dùng là họ có thời gian chạy C/C++ chuẩn được cài đặt trên hệ thống của họ. Nếu những gì bạn nói hoạt động, tôi đã có cơ sở hạ tầng: Ứng dụng về cơ bản là một dịch vụ, vì vậy tất cả các tập lệnh đều đã sẵn sàng! – themoondothshine

+0

@Vitor: Tôi có một câu hỏi khác: Các phiên bản RTLD mới hơn có thể tải động tất cả các thư viện ngay cả khi chúng được biên dịch trên các hệ thống thực sự cũ không? Đó là, tôi sẽ không phải lo lắng về vấn đề thời gian chạy ld gây ra nếu tôi gửi libstdC++ và glibc với ứng dụng của tôi, phải không? – themoondothshine

+0

@themoondothshine Không bao giờ có vấn đề với ld không thể tải tất cả thư viện. Tôi đã làm điều này trong 3 năm qua để gửi gói GIS nguồn đóng trên Linux. –

-1

Tôi phải đặt câu hỏi về việc bạn đang làm gì với chức năng thư viện kém?

Tôi cũng có một số phần mềm nền tảng chéo. Nó chạy tốt trên các hệ thống Linux của tất cả các loại. Xây dựng với phiên bản phần mềm lâu đời nhất mà bạn muốn hỗ trợ. Các thư viện glibc và libstdC++ thực sự rất tương thích ngược.

Tôi đã xây dựng trên CentOS 4 và chạy trên RHEL 6 beta. Không vấn đề gì. Tôi có thể xây dựng trên Debian ổn định và chạy nó trên thử nghiệm.

Bây giờ, đôi khi tôi gặp sự cố với một số thư viện nếu tôi cố gắng xây dựng, hãy nói Debian cũ và thử chạy trên CentOS 5.4. Đó thường là do các lựa chọn cấu hình phân phối khác nhau, như chọn luồng hoặc không phân luồng.

+0

Hãy để tôi cho bạn biết chính xác những gì đã xảy ra: Tôi đã từng biên dịch các tệp nhị phân của tôi trên CentOS 3.9 (với phiên bản cũ của glibc - 2.3.something). Bây giờ, nhị phân này đã bắt đầu đâm vào CentOS 5.4 và các bãi lõi chỉ không trỏ đến bất cứ đâu. Cuối cùng tôi đã đi đến các nhà phát triển của CentOS và họ đã ngạc nhiên khi ứng dụng làm việc trong gần một tháng mà không có sự cố trên CentOS 5.4. Họ đã đề nghị tôi sử dụng hệ thống MockBuild của Fedora, nhưng tôi đã quyết định tự biên dịch trên nhiều nền tảng. Vì vậy, những gì tôi đang làm với các chức năng thư viện không phải là vấn đề vì nó có khả năng tương thích ngược. – themoondothshine

+1

Điều đó không đúng. Gần đây chúng tôi có một khách hàng chạy hệ thống dựa trên glibc-2.7 khiến cho tất cả chương trình C++ được xây dựng chống lại glibc-2.1X không chạy được, một số biểu tượng bị thiếu trong libstdC++. So.X (ít nhất iostream), bên cạnh CentOS là RedHat, và cả hai với thư viện không được chia sẻ mới nhất (không giống như bản phân phối khác), vì vậy nó không thuyết phục tôi nhiều lắm. – daisy

8

glibc nằm trong LGPL. Theo phần 6. của LGPL 2.1, bạn có thể phân phối chương trình của mình được liên kết với thư viện miễn là bạn tuân thủ một trong năm tùy chọn. Đầu tiên là cung cấp mã nguồn của thư viện, cùng với mã đối tượng (nguồn là tùy chọn, không bắt buộc) của chương trình riêng của bạn, do đó nó có thể được liên kết lại với thư viện. Bạn có thể cung cấp một đề nghị bằng văn bản giống nhau. Mã của riêng bạn không phải nằm trong LGPL và bạn không phải giải phóng nguồn.

libstdC++ nằm trong GPL, nhưng với major exception. Về cơ bản bạn có thể phân phối theo giấy phép bạn chọn mà không cung cấp nguồn cho mã của riêng bạn hoặc libstdC++. Điều kiện duy nhất là bạn biên dịch bình thường, không có sửa đổi độc quyền hoặc bổ sung cho GCC.

IANAL và bạn nên cân nhắc tư vấn nếu bạn cần tư vấn pháp lý thực sự.

Các vấn đề liên quan