Giảm kích thước của tệp thực thi được tạo bởi GHC

Question

Sử dụng phiên bản GHC 7.4.2 với cờ như -O3, tôi vẫn nhận được tệp thực thi rất lớn. Tôi hiểu rằng GHC thực hiện liên kết tĩnh, và phụ thuộc của nhị phân trông giống như:

linux-vdso.so.1 (0x00007fff49bff000) 
    libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007fe658d6c000) 
    librt.so.1 => /usr/lib/librt.so.1 (0x00007fe658b64000) 
    libutil.so.1 => /usr/lib/libutil.so.1 (0x00007fe658961000) 
    libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fe65875d000) 
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fe658541000) 
    libcurl.so.4 => /usr/lib/libcurl.so.4 (0x00007fe6582e3000) 
    libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007fe658074000) 
    libm.so.6 => /usr/lib/libm.so.6 (0x00007fe657d7a000) 
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fe657b65000) 
    libc.so.6 => /usr/lib/libc.so.6 (0x00007fe6577be000) 
    /lib/ld-linux-x86-64.so.2 (0x00007fe658fca000) 
    libssh2.so.1 => /usr/lib/libssh2.so.1 (0x00007fe657595000) 
    libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007fe65732b000) 
    libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007fe656f22000) 
    libz.so.1 => /usr/lib/libz.so.1 (0x00007fe656d0c000 

cho đến nay có vẻ khá tốt, tuy nhiên bên trong nhị phân tôi có thể nhìn thấy những dòng:

GHCi runtime linker: fatal error: I found a duplicate definition for symbol 
* Specifying the same object file twice on the GHCi command line 

    ....BlockedIndefinitelyOnMVar.......BlockedIndefinitelyOnSTM........AsyncException..base....GHC.IO.FD.......FD......GHC.IO.FD.setSize. 

và thực sự là một nhiều dòng văn bản, bao gồm tên hàm, hàm được định nghĩa trong các mô-đun khác và v.v. Câu hỏi đặt ra là - có thể loại bỏ các văn bản đó và có thể GHC loại bỏ mã không sử dụng khỏi các thư viện bên ngoài không?

Answer 1

Nếu bạn sử dụng phụ trợ gcc, bạn có thể chuyển cờ -optc-Os tới ghc để tối ưu hóa đầu ra cho kích thước. Có lẽ bạn có thể giảm số nhị phân của mình xuống một số byte. Nhưng tôi cũng khuyên bạn nên sử dụng liên kết động như được đề xuất trước đây, với tất cả ưu và nhược điểm của nó.

UPDATE:

Nén thực thi của bạn với UPX http://en.wikipedia.org/wiki/UPX hoặc gzexe để giảm kích thước của file thực thi.

Answer 2

LLVM có thể tối ưu hóa nhiều hơn vào thời gian liên kết so với hầu hết các trình biên dịch khác. Có lẽ GHC có một backend LLVM và bạn có thể biên dịch lại và liên kết một số/tất cả các phụ thuộc của bạn với -O4.