Trong một thời gian dài, việc thêm các gói vào các hệ thống Linux có nguồn gốc từ RedHat đã được gọi là “Địa ngục RPM”, vì lý do chính đáng. Đặc biệt là trước khi tiện ích yum ra đời, việc kiếm RPM để làm đúng việc thường là một nhiệm vụ rắc rối. Hôm nay tôi lại được nhắc nhở về điều này khi đang cố gắng biên dịch một phần mở rộng PostgreSQL trên hai hệ thống CentOS gần như giống hệt nhau.
PostgreSQL cung cấp một API có tên PGXS cho phép bạn xây dựng các phần mở rộng máy chủ vừa tận dụng thư viện mã của máy chủ vừa giao tiếp với nó. Chúng tôi sử dụng PGXS để cài đặt tiện ích repmgr của mình và việc có API được xác định rõ đó cho phép chương trình được phát triển bên ngoài từ lõi máy chủ chính. Nhiều phần bổ trợ PostgreSQL phổ biến dựa vào PGXS để tự xây dựng. Trên thực tế, đóng góp các mô-đun đi kèm với bản thân PostgreSQL thường được xây dựng theo cách này. Lấy một người đóng góp tương tự mô-đun và hack vào nó từ đó có một con đường tốt để xây dựng một phần mở rộng PostgreSQL mới.
PGXS dựa trên pg_config tiện ích có trong PATH của bạn. pg_config đi kèm với gói postgresql-devel, ngày nay thực sự được đặt tên là postgresql90-devel . Rất tiếc, nó không nằm trong đường dẫn cho bất kỳ ai theo mặc định. Vì vậy, bước đầu tiên bạn cần xây dựng bằng PGXS là làm cho nó ở đó. Một cái gì đó như thế này sẽ hoạt động cho hầu hết các hệ thống UNIX:
Dưới đây là cách xây dựng repmgr trông như thế nào trên hệ thống đang hoạt động:
Điều này bao gồm - m64 -mtune =generic , là các tùy chọn gcc có thể nói là xây dựng cho nền tảng 64 bit, nhưng hãy để trình biên dịch tìm ra chính xác nền tảng mà bạn đang sử dụng so với các hạn chế khác. Ngày nay, kết quả thường được tối ưu hóa cho x86_64 nếu bạn có hệ thống 64-bit. Tính năng tự động phát hiện hữu ích hơn khi các lựa chọn là i386, i468, i586 và i686.
Vào hệ thống rắc rối. Tôi nghĩ rằng tôi sẽ đặt PostgreSQL ở đây giống hệt nhau, nhưng bản dựng không hoạt động chút nào:
Gì? Điều này đang cố gắng tạo mã 32 bit:“-m32 -march =i386 -mtune =generic”. Do đó, khi nó cố gắng liên kết với tất cả các thư viện 64-bit trên máy chủ như libpq và libtermcap, nó không thể. Điều này đang xảy ra trên thế giới như thế nào?
Bạn có thể xem thông tin đi vào lệnh xây dựng PGXS đến từ đâu bằng cách sử dụng pg_config . Đây là cách kiểm tra phần liên quan đến CFLAGS , phần chứa thông tin kích thước bit được đặt tại:
Bây giờ tôi đang bực mình. Điều này nói lên bản dựng cho 64 bit, nhưng nó vẫn đang tìm kiếm thông tin 32 bit. Điều đó đến từ đâu?
Một số người đào sâu vào giao diện PGXS đang cố gắng lần theo dấu vết này cuối cùng đã cho phép tôi đến /usr/pgsql-9.0/lib/pgxs/src/Makefile.global và đây là những gì manh mối bắt đầu hiển thị. Đó tệp được liệt kê các tùy chọn trình biên dịch 32-bit! Họ đến từ đâu?
Tại thời điểm này, tôi bắt đầu xem xét chính xác những RPM đã được cài đặt trên mỗi máy chủ,
vì có gì đó phải khác nhau giữa chúng. Dưới đây là một lệnh hữu ích cần biết:
RHEL5 có khả năng chạy các ứng dụng 32 và 64 bit song song, bạn chỉ cần cẩn thận biên dịch chúng. Vì vậy, việc các gói tương thích cơ sở dữ liệu compat-postgresql-libs là điều bình thường và postgresql90-libs bao gồm cả hai kiến trúc. Bạn có thể có cả ứng dụng 32 và 64 muốn nói chuyện với cùng một máy chủ. Điều này thường gây khó chịu, chẳng hạn như khi bạn muốn xóa một gói và nó cho biết yêu cầu của bạn khớp với nhiều hơn một và không làm gì cả – bạn cần –allmatches để khắc phục điều đó.
Chúng ta thấy gì trên máy chủ không biên dịch? Không hoàn toàn giống như vậy:
postgresql90-devel là gì gói cho cả i386 và x86_64 đang làm gì ở đó? Điều đó chẳng có ý nghĩa gì cả!
Bây giờ, sau khi kiểm tra để thử và hiểu điều này, nếu bạn có một trong hai gói -devel và cố gắng cài đặt gói còn lại, nó sẽ tạo ra một loạt lỗi phù hợp cho các tệp xung đột, như sau:
Người đóng gói hoàn toàn biết rằng họ đã ghi đè lên cùng một Makefile.global. Làm thế nào tôi kết thúc với cả hai? Sau khi xóa sạch mọi thứ, tôi đã tìm ra cách chính xác:
Nó chắc chắn là không ổn! yum hoàn toàn hạnh phúc khi kết hợp chúng, và tôi hẳn đã làm điều đó mà không nhận ra trước đây. Nó chỉ ra rằng nếu bạn để cả hai cài đặt như vậy, bản sao bạn còn lại có thể không báo cáo lại thông tin đúng cho PGXS – không có gì ngạc nhiên khi nó bị nhầm lẫn. Đó là cách tôi kết thúc với vấn đề của mình. Tôi đang sử dụng Makefile.global được cài đặt bởi phiên bản i386, nhưng mọi thứ khác trên hệ thống là x86_64.
Vậy làm thế nào để dọn dẹp? Với sự kết hợp của các tệp ở đây, bạn không thể thực sự tin tưởng rằng chỉ cần xóa tệp không mong muốn là đủ. Sau đó, bạn có thể không còn bản sao của tất cả mọi thứ đã tích hợp. Chỉ có lựa chọn an toàn là xóa cả hai, sau đó chỉ cần cài đặt một x86_64, bây giờ chúng tôi biết chính xác phiên bản có sẵn từ thử nghiệm ở trên:
Với sự sắp xếp này, bây giờ tiện ích mở rộng PGXS của tôi đã xây dựng tốt và quá trình phát triển
trên repmgr lại tiếp tục diễn ra, sau một ngày mất thời gian để tìm ra tất cả.
Bài học cho ngày hôm nay:hãy cẩn thận khi cài đặt postgresql90-devel gói qua yum, và đừng để nó đặt cả hai kiến trúc của tệp đó vào đó. Chỉ sử dụng nền tảng phù hợp với nền tảng của postgresql90 chính của bạn bưu kiện. Và nếu bạn đang cố gắng tạo tiện ích mở rộng PGXS trên hệ thống RHEL / CentOS và bạn thấy phần không tương thích đang bỏ qua thư viện, hãy bắt đầu bằng cách xem (các) gói phát triển PostgreSQL mà bạn đã cài đặt.
Chúng tôi có thể sẽ nhận được sự kết hợp xấu cụ thể này bị chặn bởi các bản cập nhật trong tương lai cho các gói PostgreSQL 9.0. Dù sao thì tôi cũng nghĩ thật thú vị khi chia sẻ vì không có nhiều ví dụ điển hình về việc thực hiện cách khắc phục sự cố như thế này trên RPM. Tôi đã từng viết một bài có tiêu đề Cài đặt PostgreSQL 8.2 RPM trên RHEL 5 / CentOS 5 để tìm hiểu thêm về một số thông tin cơ bản ở đây. Nhưng đó là những ngày đơn giản hơn, trước khi các nền tảng 64-bit phổ biến và trước khi bạn có thể cài đặt nhiều phiên bản PostgreSQL thông qua RPM cùng một lúc. Biết cách sử dụng RPM phù hợp để liệt kê các gói được cài đặt với kiến trúc liên quan của chúng là một mẹo quan trọng hiện nay để điều hướng bạn thoát khỏi địa ngục RPM.
