¿Compilación cruzada con nombres de ruta relativos para la portabilidad/incrustabilidad binaria? (GCC)

Question

Digamos que estoy creando un paquete de aplicaciones con algunos scripts, tal vez un daemon, o incluso un binario auxiliar ... Al compilar dicho binario ... ¿es factible ./configure/hacerlo con solo relativo ¿caminos? Por ejemplo, un Makefile más consciente incluirá disposiciones tales como ...

--bindir=DIR   user executables [EPREFIX/bin] 
--sbindir=DIR   system admin executables [EPREFIX/sbin] 
--libexecdir=DIR  program executables [EPREFIX/libexec] 
--sysconfdir=DIR  read-only single-machine data [PREFIX/etc] 
--sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] 
--localstatedir=DIR modifiable single-machine data [PREFIX/var] 
--libdir=DIR   object code libraries [EPREFIX/lib] 
--includedir=DIR  C header files [PREFIX/include] 
--oldincludedir=DIR C header files for non-gcc [/usr/include] 
--datarootdir=DIR  read-only arch.-independent data root [PREFIX/share] 
--datadir=DIR   read-only architecture-independent data [DATAROOTDIR] 
--infodir=DIR   info documentation [DATAROOTDIR/info] 
--localedir=DIR  locale-dependent data [DATAROOTDIR/locale] 
--mandir=DIR   man documentation [DATAROOTDIR/man] 
--docdir=DIR   documentation root [DATAROOTDIR/doc/hiawatha] 
--htmldir=DIR   html documentation [DOCDIR] 
--dvidir=DIR   dvi documentation [DOCDIR] 
--pdfdir=DIR   pdf documentation [DOCDIR] 
--psdir=DIR   ps documentation [DOCDIR] 

Esto es grande, se puede instalar todo a /opt/local en lugar de /usr/local. Tal vez incluso volverse loco, y cambiar el nombre de los archivos binarios a través de sed .. lo entiendo ..

Pero lo que queda claro en mi pequeño cerebro, es si la capacidad de establecer de forma arbitraria caminos de tal manera que se extiende la capacidad de asignar los directorios relativos al ejecutable, de una manera similar a ...

--prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] 
--prefix=./  aka [../relative/to/binary]  

Así, por ejemplo, no importa donde se inició la bin partir, sería siempre saber que es .conf archivo iba a ser hasta una carpeta, en la carpeta correspondiente ../etc, o posiblemente incluso al lado de ella, en el mismo directorio, ./. Del mismo modo, podría garantizar el acceso de escritura a los archivos de registro y pid, etc., sin preguntarse acerca de la estructura de directorio/permisos de su destino ...

Esto habilitaría una estructura de directorio /bin /etc /lib /var completamente portátil, dentro de una RUTA a la que puedo garantizarle apariencia de predictibilidad ... pero no creo que simplemente "funcione" de esa manera ... ¿Y no estoy seguro de si simplemente "enlazar estáticamente" o no? realmente crea binarios que se pueden mover a otro sistema (aunque, para este escenario, a los que tienen las mismas libreras de soporte en los mismos lugares, para no confundir el problema) ¿Es posible realizar una compilación cruzada en este ¿manera? ¿Y puedes construir para múltiples arquitecturas en el mismo ciclo de compilación? (Por ejemplo, i386 AND x86_64 al mismo tiempo)

Tal vez podría utilizar una recomendación de un buen manual GNU/GCC (CC, CFLAGS, LDFLAGS, -l, -I y CPP 101, etc.) pero eso no fue escrito para (y por) maestros de Matemáticas - ¿en los 70?

Answer 1

En generalidad completa, no, eso no funcionará. Hay elementos en/etc, por ejemplo, que se espera sean compartidos por todo el sistema y no funcionarán correctamente si intenta mantener una copia privada para una aplicación.

Dicho esto, es probable que su aplicación no esté utilizando todos los recursos compartidos en el sistema. Usar un local/bin y/sbin, o un enlace simbólico a los reales desde una ruta relativa dentro del directorio de su aplicación debería estar bien./var parece menos probable como algo que tu aplicación necesita saber directamente - ¿hay algo que te impida almacenar registros a tu manera o usar syslogd?