2012-02-22 17 views
6

he estado tratando de recopilar 1.0.0g openssl con la siguiente rpath:Cómo compilar OpenSSL con rpath relativa

$ORIGIN/../lib64 

Cada vez que readelf -d apps/openssl, estoy consiguiendo resultados como los siguientes dependiendo de lo que la variación escape Probé :

\RIGIN/../lib64 
RIGIN/../lib64 
ORIGIN/../lib64 

Quiero configurar mi rpath sin usar herramientas externas como chrpath. ¿Es posible? Básicamente aceptaré cualquier cosa que no implique el uso de herramientas externas como chrpath (aunque ya habría terminado con eso).

Idealmente, me gustaría hacerlo pasando opciones en la línea de comandos (cualquier forma de -Wl,-rpath,$ORIGIN/../lib64).

No me importa editar el Makefile generado, que es lo que he estado intentando por última vez. ¡Si solo pudiera hacerlo imprimir un estúpido signo de dólar! Traté de modificar LIBRPATH en el bloque BUILDENV = sin suerte. Mis mejores resultados hasta el momento:

LIBRPATH=$$'ORIGIN/../lib64 # result: /../lib64 
LIBRPATH=$$$$'ORIGIN/../lib64 # result: 12345<pid>/../lib64 

He leído varias preguntas relacionadas con rPath y probado varios escapar y citando trucos, pero nada funcionó hasta ahora!

Respuesta

7

En su intento makefile:

-Wl,-rpath,${ORIGIN}/../lib64 

Estoy asumiendo que el ORIGEN es una variable de shell.

EDITAR

acabo encontrado una respuesta a su pregunta (mejor tarde que nunca): Es necesario para evitar que a partir de variables de interpolación, para ello es necesario utilizar $$ (doble signo de dolar):

-Wl,-rpath,'$$ORIGIN/../lib64' 

sé que funciona porque lo he probado con mi propia aplicación, disfrutar :)

+0

No es así y eso es parte de todo el problema. Necesito que la cadena literal '$ ORIGIN /../ lib64' se escriba en el ejecutable. No debe haber sustitución de ningún tipo. –

+0

¿Puedes aclarar qué versión de openssl estabas usando y qué línea de Makefile has cambiado? –

+0

OpenSSL tiene un 'Makefile.org' y un montón de makefiles recursivos. Y no respetan 'CFLAGS',' LDFLAGS', etc. Así que * "En tu archivo make intenta ..." * * no es tan fácil como parece. – jww

2

fui el camino de Chrpath. http://enchildfone.wordpress.com/2010/03/23/a-description-of-rpath-origin-ld_library_path-and-portable-linux-binaries/

Es bastante complicado contrarrestar la expansión del shell `$$ ORIGIN`` en openssl. Tarde o temprano, se expande debido al signo de dólar. Si realmente quieres ir por este camino, puedes hacerlo. He encontrado lo siguiente para trabajar con openssl 1.0.1g en Linux. En Makefile.shared, busque esta línea:

DO_GNU_APP=LDFLAGS="$(CFLAGS) -Wl,-rpath,$(LIBRPATH)" 

Reemplácela con lo siguiente. Este quoting-fu neutraliza la expansión de $. El doble $$ es la forma de obtener un solo signo de dólar en archivos make.

DO_GNU_APP=LDFLAGS="$(CFLAGS) -Wl,-rpath,'"'$$'"ORIGIN/../lib64'" 

Después de compilar:

readelf -d apps/openssl | grep RPATH 
0x000000000000000f (RPATH)    Library rpath: ['$ORIGIN/../lib64'] 
+0

'DO_GNU_APP = LDFLAGS ...' - I * think * esto permitirá que 'libssl.so' cargue aún el' libcrypto.so' incorrecto. – jww

+0

*** Plus One *** ... logró obtener un RPATH * relativo con * una variable de shell. ¿'Ldd' honra la variable de shell? ¿Se expande? Voy a marcar esta pregunta porque nunca he visto eso antes ... – jww

+0

$ ORIGIN es un token ldd especial. Una muy mal elegida si me preguntas, porque el signo de dólar es un personaje especial que se expande por shells, si no por makefiles. Esta es la razón por la cual es tan complicado pegar $ ORIGIN en el ejecutable. Es mejor usar chrpath. Este tipo de ruta relativa hace que su ubicación de openssl sea independiente y le permite mantener múltiples versiones en diferentes ubicaciones. –

0

no me importa editar el Makefile generado, que es lo que he estado tratando de última ...

No estoy seguro de que pueda establecerlo con una variable de shell y una ruta relativa. I no piensa que ldd amplía $ORIGIN en $ORIGIN/../lib64. En este caso, creo que necesita usar ldconfig a agregar$ORIGIN/../lib64 a las rutas de búsqueda de la biblioteca. Ver finding ldd search path en Server Fault para más detalles.

Como no estoy seguro, le daré las instrucciones de todos modos. No necesita cambiar los Makefiles. De hecho, no tuve suerte en el pasado porque las cosas se sobrescriben, y otras cosas como CFLAGS y LDFLAGS se ignoran.

Ver también Build OpenSSL with RPATH? Su pregunta y la pregunta citada son preguntas diferentes que convergen en respuestas similares (no hay duplicados entre ellas). Pero proporciona la posición del desarrollador OpenSSL en RPATHs. Era un correo electrónico privado, así que compartí los detalles relevantes en lugar de todo el mensaje.

Si logra incrustar $ORIGIN/../lib64 en la sección ELF y funciona, informe. A continuación, estoy usando /usr/local/ssl/lib para mi RPATH. Debe sustituir $ORIGIN/../lib64 por /usr/local/ssl/lib.


OpenSSL soporta RPATH 's fuera de la caja para los objetivos de BSD (pero otros no). De Configurar:

# Unlike other OSes (like Solaris, Linux, Tru64, IRIX) BSD run-time 
# linkers (tested OpenBSD, NetBSD and FreeBSD) "demand" RPATH set on 
# .so objects. Apparently application RPATH is not global and does 
# not apply to .so linked with other .so. Problem manifests itself 
# when libssl.so fails to load libcrypto.so. One can argue that we 
# should engrave this into Makefile.shared rules or into BSD-* config 
# lines above. Meanwhile let's try to be cautious and pass -rpath to 
# linker only when --prefix is not /usr. 
if ($target =~ /^BSD\-/) 
    { 
    $shared_ldflag.=" -Wl,-rpath,\$(LIBRPATH)" if ($prefix !~ m|^/usr[/]*$|); 
    } 

La forma más fácil de hacerlo por OpenSSL 1.0.2 parece seradd it to linker flags during configuration

./config -Wl,-rpath=/usr/local/ssl/lib 

También puede editar la línea Configurar y codificar el rpath. Por ejemplo, estoy trabajando en Debian x86_64. Así que abrí el archivo Configure en un editor, copiado linux-x86_64, lo nombró linux-x86_64-rpath, e hizo el siguiente cambio de añadir la opción -rpath:

"linux-x86_64-rpath", "gcc:-m64 -DL_ENDIAN -O3 -Wall -Wl,-rpath=/usr/local/ssl/lib:: 
-D_REENTRANT::-Wl,-rpath=/usr/local/ssl/lib -ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL: 
${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64", 

arriba, campos 2 y 6 fueron cambiados. Corresponden a $cflag y $ldflag en el sistema de compilaciones de OpenSSL.

A continuación, configure con la nueva configuración:

$ ./Configure linux-x86_64-rpath shared no-ssl2 no-ssl3 no-comp \ 
    --openssldir=/usr/local/ssl enable-ec_nistp_64_gcc_128 

Finalmente, después de make, compruebe la configuración atrapados:

$ readelf -d ./libssl.so | grep -i rpath 
0x000000000000000f (RPATH)    Library rpath: [/usr/local/ssl/lib] 
$ readelf -d ./libcrypto.so | grep -i rpath 
0x000000000000000f (RPATH)    Library rpath: [/usr/local/ssl/lib] 
$ readelf -d ./apps/openssl | grep -i rpath 
0x000000000000000f (RPATH)    Library rpath: [/usr/local/ssl/lib] 

resultados Una vez que realice make install, entonces ldd producirá esperados :

$ ldd /usr/local/ssl/lib/libssl.so 
    linux-vdso.so.1 => (0x00007ffceff6c000) 
    libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x00007ff5eff96000) 
    ... 

$ ldd /usr/local/ssl/bin/openssl 
    linux-vdso.so.1 => (0x00007ffc30d3a000) 
    libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0 (0x00007f9e8372e000) 
    libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x00007f9e832c0000) 
    ...