Có hạn chế nào đối với các tệp thi hành được biên dịch bằng g ++ trên một bản phân phối Linux đang được sử dụng trên một bản phân phối Linux khác không?

Question

Có bất kỳ sự đồng nhất hoặc biến thể nào giữa các bản phân phối có thể ảnh hưởng đến các tệp nhị phân C++ được biên dịch bằng GCC 4.7.x trên một bản phân phối đang được sử dụng trực tiếp trên một bản phân phối khác không? Tôi hiểu rằng tình hình lý tưởng là để biên dịch từ nguồn trên bản phân phối thứ hai nhưng tôi thực sự không muốn lo lắng về việc biên dịch các phiên bản GCC mới và mã nguồn chương trình trên máy sản xuất của mình. Tôi là một người dùng Linux khá thiếu kinh nghiệm (do đó câu hỏi này!) Và vẫn thích IDE như trái ngược với biên dịch dòng lệnh, ssh là tất cả những gì tôi thực sự có thể sử dụng để truy cập vào máy sản xuất.

Bản thân mã không có gì thú vị nhưng nó sử dụng một số hoạt động của các cơ sở hệ điều hành máy xay như chặn ổ cắm và các loại tương tự.

Bất kỳ lời khuyên nào sẽ được đánh giá rất nhiều!

Answer 1

Trừ những chương trình được xây dựng trên chính xác cùng hệ điều hành (bao gồm cả phiên bản) và chính xác cùng một phần cứng không có bảo đảm.

Trong thực tế:

1. Nếu phần cứng là cùng một gia đình của chip nó nên làm việc.

   • Điều này là do hầu hết mọi người không bật tối ưu hóa phần cứng cụ thể (nhưng chúng có thể).
   • binaries Di chuyển trên chipset là rất khó để làm việc
   • Di chuyển mã nhị phân từ cũ cho các thành viên mới của một gia đình phần cứng có khả năng làm việc
   • Di chuyển mã nhị phân từ mới cho các thành viên cũ của một gia đình phần cứng là ít có khả năng (nhưng sẽ phụ thuộc vào các thiết lập tối ưu hóa và biên dịch (ir di chuyển 64-32 trúc bit là khó có khả năng làm việc).

2. Nếu hệ điều hành có số lượng lớn cùng sau đó nó nên (có thể) làm việc.

   • Phiên bản hệ điều hành mà nhị phân sẽ hoạt động trên sẽ phụ thuộc vào phiên bản trình biên dịch được sử dụng để tạo và hệ điều hành máy chủ.
   • Nếu trình biên dịch có thay đổi trong ABI nó tạo ra thì tất cả các phiên cược sẽ bị tắt. Nhưng thường một sự thay đổi trong ABI được tạo ra bởi trình biên dịch sẽ là một vấn đề lớn và do đó chỉ xảy ra tại các điểm chính trong bản đồ đường OS (không phải ở các bước tăng nhỏ).

3. Lời khuyên của tôi được tạo từ nguồn.

   • Không đặc biệt ra ngoài và cập nhật môi trường phát triển (sử dụng môi trường đi kèm với phân phối (nếu bạn cập nhật mặc định, chúng sẽ không phá vỡ tính tương thích ngược)).
   • Tòa nhà thật dễ dàng chỉ cần đọc tệp README. Nhưng thường nó liên quan đến việc chạy hai lệnh ./configure và make. Nếu bạn không muốn bất cứ điều gì đặc biệt bạn thường không cần phải làm bất cứ điều gì khác.

Answer 2

Nói chung, các tệp nhị phân được xây dựng trên phân phối mới hơn không hoạt động trên phiên bản cũ hơn, nhưng các tệp nhị phân được xây dựng trên phân phối cũ hơn sẽ hoạt động phân phối mới hơn. Bây giờ, nếu bạn xây dựng nhị phân trên RedHat EL4, nó sẽ hoạt động trên hầu hết các bản phân phối được hỗ trợ. (Bạn có thể cần phải sao chép libstdC++ nếu thiếu)

Answer 3

G ++ đã có một ABI ổn định trong một thời gian gây ra vấn đề. Điều có thể gây ra sự cố là sử dụng thư viện được liên kết động. Hệ thống chạy chương trình sẽ cần phải có các phiên bản tương thích của bất kỳ thư viện được chia sẻ nào mà tệp thực thi được biên dịch. Nếu bạn chỉ sử dụng liên kết tĩnh, bạn không nên gặp sự cố. Bạn có thể bật liên kết tĩnh bằng cách sử dụng tùy chọn -static.

Answer 4

Với liên kết tĩnh, hai điều kiện phải được đáp ứng:

1) Hệ thống mục tiêu và xây dựng hệ thống phải có cùng một kiến ​​trúc (với ngoại lệ: bạn có thể chạy mã nhị phân 32-bit trên nhiều host 64-bit)

2) (g) gói libc trên hệ thống mục tiêu không phải là một phiên bản cũ hơn trên hệ thống xây dựng (đôi khi bạn có thể nhận được ngay với sự khác biệt phiên bản nhỏ)

Nó trở nên phức tạp hơn với liên kết động.