2013-04-27 24 views
10

Giúp tôi giải quyết điểm số.Xây dựng các tệp nhị phân Linux cho nhiều nền tảng

Tôi có một phần mềm được viết bằng C++ có nghĩa là chạy trên nhiều bản phân phối Linux nhất có thể và tôi cần tìm ra một chiến lược hiệu quả. Tôi đang cố gắng để tàu nhị phân trong trường hợp này không phải mã nguồn (có thể là tốt để biết). Nó đã là một sản phẩm thương mại và tôi có vấn đề sở hữu trí tuệ ngăn cản tôi mở nguồn sản phẩm nhưng cũng có nghĩa là tôi phải đối phó với vô số các vấn đề về GPL.

Dòng lý luận hiện tại là chọn một mẫu số chung ít nhất và xây dựng mọi thứ. Điều đó có hai tác động chính mà tôi thấy phản tác dụng.

  1. Hỗ trợ C++ trong các phiên bản cũ của GCC thiếu một số tính năng C++ hiện đại hơn.
  2. Mẫu số chung nhỏ nhất đòi hỏi Red Hat Enterprise Linux 4 (RHEL4)

Tôi chắc chắn không cần tính năng toàn bộ C++ 11 thiết nhưng tôi muốn mang lại C++ hỗ trợ lên đến đó của Visual C++ 2010. Tôi đang perusing ý tưởng sử dụng Clang/libC++ như trái ngược với GCC/libstdC++ nếu có thể. Có vẻ như RHEL4 dường như không hỗ trợ nhiều nền tảng cho việc xây dựng các ứng dụng C++, hơn thế nữa, tôi có chút hiểu biết về tính ổn định của ABI trên các phiên bản Linux khác nhau nhưng tôi lo ngại rằng RHEL4 gặp nhiều rắc rối hơn giá trị. Việc cố gắng xây dựng cho tất cả các bản phân phối dựa trên một số ít không phải là một chiến lược khả thi. Tôi đang theo giả định rằng phần mềm biên dịch cho các bản phân phối Linux khác nhau được thực hiện tốt nhất bằng cách biên dịch phần mềm cho nền tảng đích với các công cụ trên nền tảng đích. Tôi cũng hiện đang hoạt động theo giả định rằng bạn sẽ chạy vào các vấn đề di động rộng lớn qua các nền tảng Linux nếu bạn không nắm lấy điều này. Không phải để nói về nhiều thư viện mà bạn có thể hoặc không thể liên kết với vì sự bất ổn của C++ ABI trên các nền tảng/bản phân phối.

Nhưng tôi có thể sai, tôi muốn nghe từ những người thường xuyên xử lý vấn đề này. Điều gì sẽ làm việc và tại sao? hoặc quan trọng hơn, những gì sẽ không hoạt động?

+3

Nếu tôi trả tiền cho phần mềm điều gì xảy ra nếu tôi báo cáo lớn trên Linux bạn không có - chắc chắn hỗ trợ sản phẩm bạn phải thử nghiệm sản phẩm trên phiên bản Linux được hỗ trợ - do đó bạn phải có VM cho mỗi người và xây dựng ở đó – Mark

+0

@ Đánh dấu chính xác suy nghĩ của tôi, đó là công việc đang diễn ra. –

+0

http://stackoverflow.com/questions/2157636 | http://stackoverflow.com/questions/16250831 | http://stackoverflow.com/questions/15386027 –

Trả lời

7

Bạn có thể cố gắng tập trung vào một vài nền tảng chính thay vì phân phối riêng lẻ. Những gì tôi có nghĩa là bằng cách xây dựng trên những gì tôi gọi là "distro cơ bản" (Debian và RedHat) và hy vọng cho tốt nhất trên những người khác.

Rất có thể, các tệp nhị phân Debian (được liên kết tĩnh) sẽ chạy tốt trên Ubuntu và Mint và các bản phân phối có nguồn gốc Debian khác. RedHat nhị phân có thể sẽ chạy trên Centos, Scientific Linux và SuSE Linux. Nếu bạn quan tâm đến các bản phân phối ít phổ biến hơn (Giả sử bạn có rất nhiều khách hàng chạy một số Linux không phổ biến), và cả Debian hoặc RedHat của bạn đều không thể thực hiện được, hoặc thiết lập một VM của bản phân phối đó và xây dựng một tệp thực thi đặc biệt cho hương vị đó.

Tôi đã thực hiện phương pháp này trong quá khứ và hoạt động tốt.

+1

Nhưng bạn khuyên bạn nên có các tệp nhị phân riêng cho Debian và RHEL? –

4

Cách tốt nhất để làm điều đó làm cho phần mềm của bạn có mã nguồn mở free software (ví dụ: giấy phép GPLv3 +), sau đó nếu phần mềm của bạn đủ thú vị, nó sẽ được đóng gói trong bản phân phối (bởi người bảo trì phân phối).

Bạn luôn muốn cung cấp các gói phân phối (ví dụ: .deb tệp cho Ubuntu hoặc Debian) vì đây là những tệp dễ cài đặt nhất.

Nếu bạn vẫn muốn thực hiện phần mềm độc quyền (nhưng hãy tự hỏi nếu bạn sẽ có thể bán, hoặc thậm chí phân phối miễn phí, thành công phần mềm của bạn), bạn có thể thực hiện các bước sau:

  • biên dịch một trình biên dịch GCC gần đây (ví dụ 4.8) bằng cách cho phép một stdc tĩnh ++ & một libgcc tĩnh (hầu hết phân phối được cung cấp GCC không làm điều đó).

  • liên kết chương trình của bạn có thể tĩnh (nhưng bạn có thể không thực hiện được điều này, ví dụ: /etc/nsswitch.conf các chức năng liên quan, bao gồm getaddrinfo và các dịch vụ DNS có liên quan).

Thậm chí bằng cách liên kết tất cả các C++ thứ liên quan tĩnh bạn vẫn phụ thuộc vào libc.so.6 và sau đó bạn có thể có một số vấn đề versioning Gnu libc (do đó một số nhị phân được biên soạn cho một phiên bản libc 2.17 sẽ không luôn luôn chạy với một libc 2.16 hoặc ngược lại). Cũng lưu ý rằng GNU libc thường được gắn với một số phiên bản hạt nhân (bạn không thể sử dụng một libc gần đây trên một số hạt nhân khá cũ). Bạn có thể xem xét một số libc thay thế như MUSL libc

BTW, bạn thường có thể sử dụng một số chroot môi trường mục tiêu -ed (trong đó bạn có thể cài đặt một số phân phối khác, ví dụ. Với debootstrap)

+1

Tôi có lẽ nên thêm rằng nó đã là một gói phần mềm thương mại khả thi nhưng hiện tại không có kế hoạch nào để mở nguồn nó. Đó là một vấn đề sở hữu trí tuệ lớn, bây giờ, nó phải là một nguồn đóng. Nhưng cảm ơn vì sự thấu hiểu của bạn, một số điều này sẽ hữu ích trong việc chọn chiến lược về sau. –

2

Nếu có ai đó tò mò, chúng tôi đã giải quyết được vấn đề bằng cách xây dựng một chuỗi công cụ GCC 4.8 trên đỉnh của RHEL 4.8 dist mà tiếp tục là đại lý xây dựng của chúng tôi.

Điểm mấu chốt của nó được vạch ra here. Vấn đề là đơn giản hơn một chút vì chúng ta không cần một trình biên dịch chéo đầy đủ chức năng. Chỉ cần một chuỗi công cụ GCC 4.8 trên máy chủ đích.

Tính tương thích vẫn là một nỗi đau vì phiên bản Linux cũ này hầu như không hỗ trợ SMB và/hoặc công nghệ khác. Chúng tôi đã kết thúc với một kịch bản Bash đặt kết quả đầu ra xây dựng trong một máy chủ FTP và điều này làm việc khá tốt. Nó giải quyết những cơn đau lớn.