2012-09-09 14 views
19

Utilizando la versión 7.4.2 de GHC con indicadores como -O3, sigo obteniendo un gran ejecutable. Entiendo que GHC hace vinculación estática, y las dependencias de la binaria es así:Reducir el tamaño del ejecutable producido por GHC

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 

hasta ahora se ve bastante bueno, sin embargo dentro del binario puedo ver las líneas:

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. 

y en realidad una muchas líneas de texto, incluidos los nombres de mis funciones, funciones definidas en otros módulos, etc. La pregunta es: ¿es posible eliminar esos textos y GHC puede eliminar el código no utilizado de las bibliotecas externas?

+4

debería echar un vistazo a la pregunta: http: //stackoverflow.com/questions/6115459/small-haskell-program-compiled-with-ghc-into-huge-binary? Lq = 1 - He marcado su pregunta como un posible duplicado de la misma. – epsilonhalbe

+0

no es realmente cierto. Despojé el archivo y no obtuve ninguna diferencia con la versión no eliminada. Así que todavía estoy buscando la manera de reducir el tamaño del binario. – jdevelop

+1

e intentó la vinculación dinámica: como puede ver en la respuesta de @ donstewart, esto hizo que la forma binaria sea más compacta que simplemente quitar los símbolos. Pero estoy lejos de ser un experto. – epsilonhalbe

Respuesta

1

Si usa el backend gcc, puede pasar el indicador -optc-Os al ghc para optimizar la salida para el tamaño. Quizás puedas reducir tu binario en algunos bytes. Pero también sugeriría usar enlaces dinámicos como se sugirió anteriormente, con todos sus pros y sus contras.

ACTUALIZACIÓN:

comprimir el ejecutable con UPX http://en.wikipedia.org/wiki/UPX o gzexe para reducir el tamaño del ejecutable.

+0

mediante el enlace dinámico es como mover el tamaño de un archivo a otro. ¿Qué sucede si deseo enviar mi aplicación a los usuarios finales? Necesitaré también empaquetar todas esas DLL, por lo que la vinculación estática funciona muy bien.Sin embargo, el tamaño del ejecutable todavía me pone triste. – jdevelop

+0

El enlace dinámico vale la pena, si puede asumir que su cliente ya tiene instalado el dll, de lo contrario entregará el dll con su aplicación y vinculará su propia versión (el enfoque de Windows) que tiene la misma implicación espacial que los enlaces estáticos. ¿Cuál es exactamente tu problema? ¿Uso de memoria cuando se está ejecutando la aplicación o el espacio de disco del entregable? Si es el último, puedes comprimir tu ejecutable con 'UPX' (http://en.wikipedia.org/wiki/UPX) o' gzexe'. –

+0

en realidad, no me gusta el hecho de que el ejecutable tenga muchos datos textuales extraños. – jdevelop

2

LLVM puede hacer más optimización en tiempo de enlace que la mayoría de los otros compiladores. Quizás GHC tiene un backend LLVM y puede recompilar y vincular algunas/todas sus dependencias con -O4.

Cuestiones relacionadas