2011-12-30 48 views
17

điều này rất khó hiểu. Tôi đã dành rất nhiều thời gian đọc bài viết về điều này trên stack, vv Vẫn còn bối rối.Khả năng tương thích của * .dll * .a * .lib * .def giữa VisualStudio và gcc

Tôi đang sử dụng Qt và C++ để mã hóa. Trong Qt, tôi đang sử dụng tùy chọn gcc cho trình biên dịch.
Vấn đề là nhiều thư viện của bên thứ ba mà tôi đã thử dường như không hoạt động.

Tôi mới sử dụng các tệp .dll, .a, .lib, .def và thư viện.

Câu hỏi 1:

Theo kinh nghiệm hạn chế của tôi (Tôi đã thử 7 hoặc 9 thư viện cho đến nay), nhà cung cấp các thư viện hiếm khi cho bạn biết liệu .dll đã được thực hiện với VisualStudio hoặc gcc. Điều này làm tăng thêm sự nhầm lẫn. Họ hầu như không bao giờ làm cho nó rõ ràng những gì trình biên dịch thư viện tương thích với. Vì vậy, tôi sẽ đánh giá cao một số lời khuyên cuộc sống thực về cách đối phó với cơn ác mộng này. Hầu như tất cả các thư viện tôi đã thử là các dự án OpenSource. Tôi sẽ không nêu tên ở đây, nhưng đây là những dự án nổi tiếng. Tôi chắc chắn rằng vấn đề là tôi thiếu kiến ​​thức ...

MinGW và gcc Thế giới

question2:
Theo như tôi có thể nói, năng động C++ thư viện cho vũ trụ gcc MinGW yêu cầu này, ngay ?
* .h
* .dll
* .a

Câu hỏi 3:
Thật không may, file .a thường thiếu và thư viện không hoạt động. Điều này rất khó hiểu. Nếu tập tin .a bị thiếu, tôi có may mắn không?

Câu hỏi 4:
Tôi có thể tạo tệp .a cho MinGW/gcc nếu * .dll được tạo bằng gcc không?

Câu hỏi 5: Tôi có thể tạo tệp .a cho MinGW/gcc nếu * .dll được tạo bằng VisualStudio không?

Câu hỏi 6:
Có thể một * .dll (được tạo bằng MinGW/gcc) quá cũ và không còn tương thích với MinGW/gcc mới hơn không?

Câu hỏi 7:
Các dự án Qt sử dụng MinGW/gcc không bao giờ cần tệp * .lib, phải không? Đó là một điều duy nhất của VisualStudio, phải không?

Câu hỏi 8:
Tôi không cần tệp * .def để sử dụng * .dll trong dự án Qt sử dụng MinGW/gcc, phải không?

VisualStudio Thế giới

Câu hỏi 9:
Theo như tôi có thể nói, năng động C++ thư viện cho VisualStudio yêu cầu sau đây:
* .h
* .dll
* .lib

Phải không? Một lần nữa, vấn đề là tệp * .lib hầu như luôn bị thiếu. Ngoài ra, không có hướng dẫn rõ ràng về trình biên dịch thư viện nào tương thích. Vậy làm thế nào tôi có thể biết rằng nó chỉ dành cho VisualStudio hay không?

Câu hỏi 10:
Nếu tệp .lib bị thiếu, tôi có gặp may không?

Câu hỏi 11:
Tôi có thể tạo tệp .lib cho VisualStudio nếu * .dll được tạo bằng VisualStudio không? Làm sao?

Câu hỏi 12:
Tôi có thể tạo tệp .lib cho VisualStudio nếu * .dll được tạo bằng MinGW/gcc không? Làm sao?

Câu hỏi 13:
Có thể là * .dll (được tạo bằng VisualStudio) quá cũ và không còn tương thích với VisualStudio mới hơn?

Câu hỏi 14:
Nếu trong QtCreator tôi chọn trình biên dịch VisualStudio, có tương thích 100% với thư viện động được biên dịch bởi REAL VisualStudio bởi người khác không? Tôi tin rằng các tùy chọn trình biên dịch VisualStudio trong Qt Creator là một trình biên dịch VisualStudio giả mạo.

Câu hỏi 15:
Nếu trong QtCreator tôi chọn trình biên dịch MinGW/gcc, tôi có thể sử dụng với thư viện động Qt được biên dịch bởi REAL VisualStudio bởi người khác không?

Câu hỏi 16:
Tôi không cần tệp * .def để sử dụng * .dll trong dự án Qt sử dụng MinGW/gcc, phải không?

Câu hỏi 17: Tôi có thể chuyển đổi * lib (làm việc với tệp * .dll và * .h) được thực hiện bằng REAL VisualStudio thành tệp * .a để tôi có thể sử dụng tệp * .a với chưa sửa đổi * .dll, và * .h tập tin trong một dự án Qt gcc?

+3

Tôi tin rằng sự phức tạp này đặc biệt đối với Windows. Bạn sẽ không có nó khi sử dụng Qt trên Linux! –

+2

Bạn có thể muốn chia nhỏ câu hỏi này thành nhiều câu hỏi (cụ thể là "tôi có thể tạo X nếu tôi có Y") ... có thể nhiều người có thể trả lời một số câu hỏi này và nếu bạn hỏi riêng họ (vì họ đẹp không liên quan đến Qt) về liên kết cửa sổ, bạn có thể nhận được phản hồi nhanh hơn. Tất cả những gì được nói, câu trả lời ngắn nhất tôi có thể cung cấp cho bạn là * không sử dụng MinGW nếu bạn không phải * - VisualStudio là chuẩn được hỗ trợ trên nền tảng và bạn sẽ có trải nghiệm tốt hơn trong thời gian dài (nếu một số cơn đau trong ngắn hạn với phụ thuộc thư viện nguồn mở). –

+3

-1: để hỏi 16 câu hỏi cùng một lúc. –

Trả lời

3

Một DLL về cơ bản là một ứng dụng được biên dịch - chỉ ở dạng thư viện hàm chứ không phải tệp EXE. Bất kỳ ứng dụng nào khác cũng có thể sử dụng các hàm trong DLL đó bằng cách chỉ khai báo hàm, dll chứa hàm, các tham số và các giá trị trả về và như vậy.

DLL phải tồn tại trên hệ thống nếu ứng dụng được biên dịch bằng "thư viện được liên kết động", vì vậy bạn phải bao gồm các DLL cần thiết trong trình cài đặt của mình hoặc hy vọng chúng đã tồn tại trên máy tính đích. Sử dụng DLL làm cho kích thước của ứng dụng của bạn nhỏ hơn tổng thể.

Tạo DLL cũng giống như tạo bất kỳ ứng dụng nào khác - bạn chỉ nhắm mục tiêu xây dựng dưới dạng DLL chứ không phải là EXE hoặc bất kỳ thứ gì.

Để tạo bất kỳ ứng dụng nào - DLL, EXE hoặc cách khác - bạn cần mã nguồn và tiêu đề cần thiết. Các tệp .h chứa các khai báo cho các hàm và kiểu dữ liệu và các lớp và không có gì - chúng hiếm khi chứa mã. Một .def rất giống với .h, nhưng thường là một tập hợp các lệnh cho một trình liên kết.

Khi bạn biên dịch, a .h hoặc .c hoặc bất kỳ thứ gì chuyển thành tệp .obj - một tệp đối tượng. Nhiều tệp đối tượng được liên kết với nhau để tạo tệp DLL hoặc EXE của bạn.

Tệp .lib là thư viện tĩnh - về cơ bản là một loạt tệp .obj (hoặc một .obj) đã được kết hợp cho giai đoạn liên kết.

Định dạng tệp .obj và .lib có thể dành riêng cho trình biên dịch và chúng hiếm khi tương thích giữa các trình biên dịch. Bạn phải có mã nguồn gốc hoặc một .obj hoặc .lib được tạo riêng cho trình biên dịch của bạn.

Khi bạn chọn tạo một EXE với "thư viện được liên kết động", nó sẽ mong đợi các tệp DLL mà nó có thể sử dụng. Khi bạn chọn "các thư viện liên kết tĩnh", trình liên kết sẽ định vị các tệp .lib cần trước khi tạo EXE và bạn sẽ không cần các tệp DLL đó.

15

Có thể nó có giá trị bắt đầu ngay từ đầu và không nhảy trước chính chúng ta và mô tả vấn đề cốt lõi. Từ câu trả lời này cho một số câu hỏi có thể được bắt nguồn.

Bắt đầu là ABI (giao diện nhị phân ứng dụng). Điều này xác định những thứ như

  • cách gọi hàm, ví dụ: tham số nào đi vào sổ đăng ký nào hoặc vị trí nào trên ngăn xếp chúng đặt
  • cách ngoại lệ được ném
  • cách bố trí các đối tượng, ví dụ: nơi "con trỏ vtable" đi, những gì đệm được sử dụng
  • lớn như thế nào xây dựng trong các kiểu dữ liệu là
  • cách tên hàm là "nham nhở" vào những biểu tượng
  • cách loại thông tin được đặt ra
  • sự bố trí các lớp học thư viện chuẩn
  • , vv

Hầu hết các nền tảng xác định một C ABI nhưng không định nghĩa một C++ ABI. Kết quả là trình biên dịch xác định ABI của riêng mình (cho tất cả mọi thứ ngoại trừ các công cụ C thường có ở đó). Điều này tạo ra các tệp đối tượng không tương thích giữa các trình biên dịch khác nhau (đôi khi ngay cả giữa các phiên bản của cùng một trình biên dịch). Thông thường, điều này thể hiện chính nó bằng những cái tên kỳ lạ bằng cách nào đó không được xác định: ABI khác nhau cố ý sử dụng tên mangling khác nhau để ngăn chặn vô tình liên kết một tệp thực thi sẽ không hoạt động. Để làm việc xung quanh những đặt cược tốt nhất của bạn là xây dựng tất cả các thành phần bằng cách sử dụng cùng một trình biên dịch.

Nếu bạn muốn xác định trình biên dịch mà thư viện đang xây dựng, bạn có thể xem nội dung của nó bằng các công cụ thích hợp. Tôi nhận ra rằng bạn hỏi cho Windows nhưng tôi chỉ biết các công cụ UNIX (họ có thể có sẵn với MinGW):

  • nm nhìn vào những cái tên biểu tượng (thường là cùng với ít hoặc grep)
  • ar xây dựng hoặc kiểm tra thư viện
  • ident để tìm chuỗi đặc biệt nhúng trong đối tượng
  • chuỗi để thích tất cả các chuỗi
  • C++ filt để demangle biểu tượng vào C++ của họ tuyên bố

Nhìn vào các ký hiệu thường mang lại các nhận dạng của trình biên dịch đã tạo ra chúng. Nếu bạn đã nhìn thấy chúng thường xuyên, bạn thậm chí có thể nói với ABI từ các biểu tượng.

Có nhiều hơn nữa trong lĩnh vực này nhưng tôi đã hết sức chịu đựng ... :-) Trong mọi trường hợp, tôi nghĩ rằng điều này trả lời một số câu hỏi ở trên.

7

Tôi tình cờ gặp câu hỏi này khi tìm kiếm công cụ để sử dụng để tạo tệp .a bằng cách sử dụng Code :: Blocks C++ compiler cho windows. Code: Blocks sử dụng trình biên dịch gcc MinGW.Đó là đủ cao trên google để xác nhận tính necromancy của tôi tôi nghĩ.

Thư viện liên kết động (dll's) là một nhóm hỗn hợp. Một số có thể được biên dịch theo cách khiến chúng rất khó sử dụng ngoài ngôn ngữ lập trình và trình biên dịch chúng được tạo ra.

Thường thì dll được tạo bằng giao diện C sạch. Khi đó là trường hợp câu trả lời cho các câu hỏi của bạn mà tôi nghĩ rằng tôi có thể trả lời là:

1: đó không phải là một câu hỏi.

2, 9: yes

3, 10: không có

4, 11: yes. MinGW bao gồm một công cụ (dlltool.exe) mà có một tập tin .dll và .def và tạo ra một tập tin .a MS VisualStudio cũng bao gồm một công cụ (mà tôi nghĩ được gọi là lib.exe) để làm điều tương tự. Và nếu bạn bắt đầu sử dụng trình biên dịch khác, có thể bạn sẽ thấy chúng có một công cụ. Các trình biên dịch Borlands có công cụ implib.exe.

5, 12: yes (giống như 4)

6, 13: ghế ... Tôi không nghĩ rằng có một ngày hết hạn trên dll nhưng họ phải được biên soạn cho hệ điều hành đúng đắn.

8, 16: bạn cần .def để làm cho .a hoặc lib, nếu bạn không có nó, nó thực sự là posible để tạo ra rằng từ .dll

0

câu hỏi 1: bạn nên nhập .h tệp và liên kết .a tệp bằng lệnh liên kết và sao chép .dll gần đầu ra .exe của bạn.

câu hỏi 2: bạn có thể làm .a tập tin bằng cách .def tập tin

set PATH=C:\Program Files\CodeBlocks\MinGW\bin;%PATH% 

dlltool.exe -d libfftw3-3.def -l libfftw3-3.a 

câu hỏi 3: không có. bạn có thể tạo tệp .def theo cách thủ công và sau khi tạo tệp .a.

câu hỏi 4,5: yes

câu hỏi 6: Tôi nghĩ rằng đó là phụ thuộc vào hệ thống phần cứng và hoạt động của bạn chứ không phải trên trình biên dịch của bạn.

câu hỏi 7: Tôi không biết.

câu hỏi 8: bạn chỉ .h.a.dll cần không .def

câu hỏi 9: .lib file là dành cho visual studio.

câu hỏi 10: không cần bạn .def.dll để thực hiện .lib và bạn có thể tự mình làm . def nếu bạn không có.

set PATH=C:\Program Files\Microsoft Visual Studio 12.0\VC\bin;%PATH% 

lib /machine:x86 /def:libfftw3-3.def 

hoặc

lib /machine:x64 /def:libfftw3-3.def 

Câu hỏi 11: yes i đã nói với bạn ở trên.

câu hỏi 12: yes

câu hỏi 13: không.

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