Como fazer um aplicativo Linux portátil?

6

Eu gostaria de fazer uma versão "portátil" do Emacs 24.3. Eu estou usando alguns sistemas Debian 7, onde não tenho acesso root. Como o Debian 7 está faltando o Emacs 24, eu gostaria de construir uma versão portátil dele, que eu possa carregar comigo em um pen drive USB. Minhas perguntas específicas são:

  1. Posso tornar o prefixo de instalação flexível ou está conectado por configure --prefix=... ?
  2. Como posso agrupar todos os .so -files necessários com a instalação?
por Arne 27.07.2014 / 23:44

3 respostas

4

Eu tenho algumas maneiras de fazer isso, as mais fáceis primeiro:

Tornar o prefixo de instalação flexível é difícil - basta fazer o prefixo de instalação em seu diretório pessoal ou em algum lugar que você possa acessar em qualquer uma das máquinas e usar

make install DESTDIR=/path/to/place/where/binaries/should/be/installed

para instalá-los em algum lugar diferente do prefixo.

Eu pessoalmente tenho meus binários em $HOME/bin , então meus comandos ficariam assim:

./configure --prefix=$HOME

Alguns programas (eu sei que o FFmpeg é um) podem ser compilados com todas as bibliotecas compiladas no programa, evitando bibliotecas compartilhadas. No caso do ffmpeg (e possivelmente outros) os flags de configuração são --disable-shared --enable-static .

Você pode usar ldd (name-of-binary-file) para verificar quais objetos compartilhados precisa e copiá-los para o seu pen drive.

Editar 1

Acabei de fazer uma maneira de obter apenas os nomes das bibliotecas vinculadas, o que é muito útil.

ldd binary-name|sed 's/=>.*//'|sed 's/\t//'|sed 's/\ (0x.*//'

irá obter uma lista de todas as bibliotecas ligadas a.

Além disso, você obterá apenas os arquivos com caminhos codificados:

ldd binary-name|sed 's/=>.*//'|sed 's/\t//'|sed 's/\ (0x.*//'|grep --color=never /

Isso funciona porque apenas as bibliotecas com caminhos codificados têm barras em seus nomes normalmente. Dá uma ideia do que você deve procurar ao fazer a próxima possibilidade.

Editar 2

Você pode usar LD_PRELOAD e / ou LD_LIBRARY_PATH para carregar símbolos de bibliotecas especificadas manualmente, negando, assim, o problema dos "caminhos codificados permanentemente" mencionado abaixo.

Se suas bibliotecas tiverem caminhos que são codificados internamente, ouvi falar de uma ferramenta chamada chrpath que pode alterar os caminhos de execução. Eu tive sucesso (limitado) em simplesmente abrir meus binários em um editor hexadecimal e mudar os caminhos para as bibliotecas compartilhadas, contanto que eles sejam mais curtos do que os que foram originalmente compilados. Eles devem terminar com o caractere terminador de cadeia. (Em C isto é quase sempre 00 ). Para ter certeza de que você terá espaço suficiente para alterar o caminho, eu (no sistema eu o compilei) defino o prefixo para algo ridiculamente longo com links simbólicos, assim se suas bibliotecas estiverem em /usr/lib :

sudo mkdir /OH_THIS_IS_A_VERY_VERY_VERY_VERY_VERY_LONG_DIRECTORY_NAME/
sudo ln -s /usr/lib /OH_THIS_IS_A_VERY_VERY_VERY_VERY_VERY_LONG_DIRECTORY_NAME/lib
mkdir destdir
./configure --prefix=/OH_THIS_IS_A_VERY_VERY_VERY_VERY_VERY_LONG_DIRECTORY_NAME
make
make install DESTDIR=$PWD/DESTDIR

( $PWD é o diretório atual, a propósito.)

Isso lhe dará muito espaço para mudar os caminhos. Se você tiver espaço sobrando após o caminho real, pode continuar adicionando 00 até chegar ao final do espaço usual. Eu só tive que recorrer a isso com binários que eu compilei para um telefone Android, que tinha o caminho de ncurses codificado no binário.

Uma última coisa que acabei de encontrar: você pode tornar a localização de ld-linux.so.* não codificada adicionando isso (adapte-se aos locais dos seus sistemas, execute algo como locate ld-linux e encontre um semelhante ao abaixo:

-Wl,--dynamic-linker=/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

para sua variável LDFLAGS .

    
por 27.07.2014 / 23:53
1

Eu tive o mesmo problema que o seu (um Linux com algumas "securizações"). Eu executei uma versão já instalada, no mesmo sistema operacional Linux (todas as árvores /usr/share/emacs e /usr/libexec e todos os arquivos /usr/bin/emacs* ) e coloquei na máquina protegida.

Depois de executar emacs24-x , ele solicitou uma biblioteca compartilhada ( .so ) Não consigo lembrar qual ...

Também o transportei na máquina de destino e encapsulei a chamada emacs24-x (com os parâmetros de função "$@" ), em uma função que adiciona a localização .so na variável LD_LIBRARY_PATH (cercada por () para evitar acumulação).

Depois, recebi as mensagens listadas acima, sobre as localizações /usr/share e libexec .

Eu modifiquei TODAS as referências a /usr/share/emacs e /usr/libexec nos executáveis, usando um editor binário (como madedit por exemplo) e em uma dúzia de arquivos ASCII nas árvores copiadas, substituindo cada "/ usr / share "por" / tmp / share "e /tmp/libexec ).

Na minha função "emacs", eu adicionei os links mkdir /tmp/share e dois links simbólicos (depois de testar eles já não existiam) para se conectar às árvores copiadas do emacs.

Depois disso, executando

emacs <myfile>

funciona perfeitamente para mim. Eu tenho uma versão Emacs portátil real (sem ter configurado isso).

    
por 10.05.2016 / 21:14
1

Eu consegui fazer uma versão portátil do Emacs 24 no CentOS 7. A mesma abordagem deve funcionar no Debian. A primeira coisa que fiz foi instalar uma máquina virtual com uma nova cópia do SO, para garantir que eu tivesse raiz e pudesse instalar quaisquer bibliotecas e ferramentas necessárias.

Minha tentativa inicial de criar uma instalação portátil envolveu instalar o pacote emacs em uma máquina virtual e copiar o binário e as bibliotecas na pasta personalizada e, em seguida, definir LD_LIBRARY_PATH na pasta com as bibliotecas. Isso foi o suficiente para que o Emacs fosse iniciado no sistema de destino, mas infelizmente, parece que o Emacs usa valores codificados para algumas de suas definições de configuração, e não consegui encontrar uma solução para o seguinte erro sobre o diretório de conjuntos ausente:

Warning: arch-dependent data dir (/usr/libexec/emacs/24.3/x86_64-redhat-linux-gnu/) does not exist.
Warning: arch-independent data dir (/usr/share/emacs/24.3/etc/) does not exist.
Warning: Lisp directory '/usr/share/emacs/24.3/lisp' does not exist.
Warning: Lisp directory '/usr/share/emacs/24.3/leim' does not exist.
Error: charsets directory not found:
/usr/share/emacs/24.3/etc/charsets
Emacs will not function correctly without the character map files.
Please check your installation!

Eu não tenho acesso para criar um link ou uma pasta em /usr/share no sistema de destino, então isso interrompeu meu progresso.

Minha segunda tentativa envolveu o download do código-fonte do Emacs (mais do que um show!) na VM e a criação da minha própria cópia com o comando ./configure --prefix=<DIR> . Eu encontrei instruções para obter e construir o Emacs no link , que usa comandos do Debian. Meu fluxo de trabalho foi:

git clone https://github.com/mirrors/emacs.git
cd emacs
git pull
./autogen.sh
# Here, I tell make to install emacs to ~/bin/centos
./configure --prefix=~/bin/centos
make bootstrap
make install

Eu tive que fazer alguns desvios para instalar dependências de bibliotecas específicas do CentOS ( sudo yum install texinfo ncurses-devel.x86_64 ).

Agora posso copiar minha pasta ~/bin/centos - que contém todos os binários e bibliotecas necessárias para executar o Emacs - no mesmo local em outros sistemas CentOS 7, adicionar ~/bin/centos/bin ao meu PATH e o Emacs está pronto para vai. Eu tive que copiar meus arquivos .emacs e .emacs.d para manter minhas configurações e temas. É basicamente uma instalação Emacs independente e portátil no meu diretório home em sistemas onde eu não tenho privilégios para instalar o pacote Emacs do sistema.

Se você der ao comando configure uma pasta em uma unidade USB (como ./configure --prefix=/media/usb/bin ) e sempre montar a unidade USB no mesmo local, será possível simplesmente montar a unidade USB, definir seu PATH variável e execute o Emacs. Parece não haver uma maneira de especificar um arquivo .emacs ou .emacs.d personalizado ao invocar emacs em si, mas você poderia usar apenas um link simbólico de ~/.emacs para /media/usb/.emacs ou similar.

    
por 18.12.2014 / 05:50