AppImage apresentando “EXECV error No such file or directory”,

Olha, já estou quase desistindo, não tenho nenhum problema com a criação de DEB ou RPM, mais o AppImage, não vai de jeito nenhum, já perdi uns 3 fins de semana nisso, o problema não é a criação do arquivo em si, ele é gerado sem erros, no entanto, sempre que vou executá-lo recebo a mensagens “EXECV error No such file or directory”, eu imagino que problema esteja no arquivo AppRun, mais precisamente na linha exec, mais já tentei um monte de coisas em vão, eu queria muito fazer esse arquivo funcionar para deixar meu jogo mais universal.

1 curtida

Isso significa que o interpretador do executável não está presente, se possível abre um tópico com isso, o problema não está em criar o AppImage

Se eu iniciar o script AppRun.sh, o jogo vai rodar normalmente, inclusive uso o mesmo script para o DEB, RPM até o Tar. zst do manjaro, não entendi o que vc quiz dizer com o interpretador do executável.

> #!/bin/bash
> HERE="$(dirname "$(readlink -f "${0}")")"
> exec "${HERE}/usr/bin/elisiaII/nw" "[email protected]"

Vc não usa o exec, ele faz o nwassuma o controle do AppRun e no geral isso deveria ser responsabilidade do AppImage, outro detalhe é sempre exporte as variáveis que alteram o ambiente

#!/bin/bash
export HERE="$(dirname "$(readlink -f "${0}")")"
"${HERE}/usr/bin/elisiaII/nw" "[email protected]"

E por fim esse erro acontece em duas situações, numa situação “normal” significa que o AppImage não possui o interpredador ELF do sistema, a outra é quando o o arquivo não está presente

Pra fazer um Debug coloque:

#!/bin/bash
export HERE="$(dirname "$(readlink -f "${0}")")"

"${HERE}/usr/bin/elisiaII/nw" "[email protected]"

echo "----------------------"
ls "${HERE}/usr/bin/elisiaII/"

Se o ls der erro, tem um problema estrutural no AppImage, ${HERE} representa a pasta raiz do AppImage

Esse AppRun.sh deve ser chamado de apenas AppRun para funcionar (mesmo sem extensão, o cabeçalho #!/bin/sh e a permissão de execução devem ser o suficiente).

Tem outras opções de debug aqui também, como fazer strace ./Elisia2.AppImage (ou seja qual for o nome aí).

1 curtida

E tem esse detalhe, o carregador do AppImage chama AppRun e não AppRun.sh

Quando eu removi o “sh” do AppRun, consegui finalmente executar o programa, mais agora surgiu outro problema, ele está tentando salvar onde não deveria.

1 curtida

Quando você instala via pacote nativo ele pede usuário root?

Quando eu gero DEB ou RPM, sim, ele pede root para instalar.

Eu falo pra salvar

não, eu dou a permissão na pasta SAVE antes de criar os pacotes, e ele mantém esses atributos (execeto no manjaro onde tenho que colocar no install do pacote) depois da instalação, mais no APPIMAGE, ele parece querer salvar no TMP ao invés de acessar o diretório padrão do save dentro de OPT/save.

TEm algum jeito de obrigar o appimage a se manter nos diretórios padrões ao invés de ir ao TMP ?

Esse esquema é fundamentalmente incompatível com a ideia dos AppImages, pois tudo na pasta do aplicativo é uma imagem somente-leitura. Mesmo instruindo a AppImage a ir para outro lugar, não deixa de ser uma imagem somente-leitura.

Pra falar a verdade, salvar dentro da pasta do aplicativo é uma gambiarra imensa (como você percebeu, tendo que pré-criar pasta com as permissões inseguras 777) – o correto seria salvar dentro da pasta do usuário, de preferência em pastas padrão como $HOME/.config, $HOME/.local/share, etc.).

Se não quiser modificar o aplicativo, a segunda melhor opção é um script instalador.

Então a solução seria criar uma pasta de save por exemplo nos Documentos do usuário e mudar o código para salvar lá ? eu achei estranho ele tentar salvar no TMP de qualquer forma, ele deveria ter tentado salvar em OPT/www/save, mais vou dar uma olhada se entendo isso melhor.

De qualquer forma, valeu por tudo, já ajudou pra caramba.

Algo nesse estilo (apesar de no geral, os programas utilizarem a pasta ~/.config/programa – você pode inclusive utilizar a pasta ~/.config/KADOKAWA/RPGMV/, que pelo visto já é criada pela Game Engine do Elisia).

Pelo que deduzi aqui, a engine tenta salvar numa pasta relativa a onde está o executável.

Nos pacotes nativos, o jogo está no /opt, então ele vai buscar em /opt/www/.... As AppImages, por sua vez, montam a imagem somente leitura numa pasta com nome aleatório dentro do /tmp, então a busca ocorre em /tmp/PASTA_ALEATORIA/www/...

De qualquer jeito, não é uma boa ideia – quem não já tem os pacotes instaláveis, vai precisar de root para criar a pasta de /opt/elisiaII/www/save, o que meio que mata o sentido de um pacote portátil.

Pois é, vou mudar no arquivo javascript de configuração, eu já mudei mais da metade deles mesmo, mais um não faz diferença, deve dar certo, obrigado por tudo até agora, ajudou muito.

Só uma ressalva: no Linux, as especificações permitem que o usuário mova a $HOME/.config para outra pasta, através da variável $XDG_CONFIG_HOME (geralmente utilizada para a configuração ir junto com o programa numa instalação realmente portável).

Portanto, a função deveria ser mais ou menos assim (exemplo em Python)

import os

def localizarSave():
  pastaConfig = os.getenv("XDG_CONFIG_HOME")
  if pastaConfig == None:
    pastaConfig = os.path.join(os.getenv("HOME"),".config")
  return os.path.join(pastaConfig, "saveElisia")

def carregarSave():
  # chame o localizarSave e siga a vida

Assim, quem tiver um XDG_CONFIG_HOME personalizado (para, por exemplo, o jogo salvar num pendrive) vai conseguir usá-lo.

No geral não faça isso vc está abrindo um buraco na segurança do sistema, não sei como você configura, mas tem algumas coisas que você pode tentar

Não, existe uma pasta específica pra isso, mais informações nesse artigo

Tem algumas coisas que você pode tentar, a primeira (e mais óbvia é usar o parâmetro do nw.js:

#!/bin/bash

# Suportando o padrão XDG

[ -z "${XDG_CONFIG_HOME}" ] && {
  export XDG_CONFIG_HOME="${HOME}/.config"
}

# A pasta onde o Elisia II deveria salvar os arquivos de save:
export APP_DATA="${XDG_CONFIG_HOME}/elisiaII"

mkdir -p "${APP_DATA}"

export HERE="$(dirname "$(readlink -f "${0}")")"
"${HERE}/usr/bin/elisiaII/nw" --user-data-dir "${APP_DATA}" "[email protected]"

Se não funcionar tem outros jeitos, mas o Node tá sacaneando, por padrão ele já deveria salvar nessa pasta

1 curtida

Vou agradecer muito pela ajuda, segui os conselhos de vocês, criei um Script simples, que vai forçar o salvamento na pasta .config/KADOKAWA/RPGMV/SAVE , como foi dito ela é padrão e é criada quando o jogo é executado, com isso parece que os problemas foram todos resolvidos, pelo menos por hoje, agora não preciso mais ficar criando DEB, RPM PKG, só fazer um AppImage e pronto.