0 votos

MacOS ya no ejecuta el archivo ejecutable, después de la actualización a Catalina/Monterey

Desde que actualicé a Monterey (desde Mojave), ya no puedo ejecutar un servidor local que estaba instalado en /Applications.

La aplicación no tiene extensión, el tipo de archivo es "Unix Executable File". Funcionaba perfectamente antes de la actualización.

Ahora cuando intento ejecutarlo desde el shell falla con

-bash: ./ManicTimeServer: cannot execute binary file

¿Qué ocurre? ¿Por qué la aplicación ya no funciona?

Y, principalmente, ¿cómo puedo hacer que vuelva a funcionar?


Información adicional:

  • ls -la ManicTimeServer devuelve -rwxr-xr-x@ (no el adicional xattr )

  • xattr ManicTimeServer devuelve

com.apple.lastuseddate#PS

  • stat ManicTimeServer devuelve

16777220 96934799 -rwxr-xr-x 1 myusername staff 0 138736 "Nov 30 17:37:52 2021" "Sep 22 09:26:35 2021" "Nov 30 17:38:24 2021" "Sep 22 09:26:35 2021" 4096 272 0 ManicTimeServer

  • file ManicTimeServer devuelve ManicTimeServer: ELF 64-bit LSB pie executable, x86-64, versión 1 (GNU/Linux), enlazado dinámicamente, intérprete /lib64/ld-linux-x86-64.so.2, para GNU/Linux 2.6.32, BuildID[sha1]=1cfaaf19b37c906e12f121854b3a6b45c6c9bdf7, stripped

  • otool -L ManicTimeServer devuelve

ManicTimeServer: no es un archivo de objetos

1voto

Este es un binario de Linux, no funcionará en MacOS.

0voto

How2iphone Puntos 182

Los siguientes comandos pueden ayudar a entender la razón del problema.

Por ejemplo, para /usr/bin/curl muestra qué tipo de binario es, si es un binario ejecutable. Se puede encontrar información adicional sobre los tipos de archivos binarios aquí

% archivo /usr/bin/curl

/usr/bin/curl: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/curl (for architecture x86_64):    Mach-O 64-bit executable x86_64
/usr/bin/curl (for architecture arm64e):    Mach-O 64-bit executable arm64e

Este comando dará detalles sobre el propio archivo. Su comentario muestra el signo "@" después de los indicadores de permisos comunes, lo que significa que hay atributos extendidos asignados. Yo comprobaría este para verificar/actualizar los atributos.

% stat /usr/bin/curl

16777220 1152921500312765277 -rwxr-xr-x 1 root wheel 0 406336 "Jan  1 10:00:00 2020" "Jan  1 10:00:00 2020" "Jan  1 10:00:00 2020" "Jan  1 10:00:00 2020" 4096 448 0x80020 /usr/bin/curl

El siguiente comando mostrará si faltan bibliotecas para la aplicación.

% otool -L /usr/bin/curl

/usr/bin/curl:
    /usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.120.1)

Actualización 1 Según la salida proporcionada el archivo que está tratando de ejecutar ES binario de Linux, se puede ver desde la biblioteca que se utiliza en el binario "/lib64/ld-linux-x86-64.so.2". Estás absolutamente seguro de que esta es la misma aplicación que se estaba ejecutando porque parece que alguien hizo una magia para que Mac OS aceptara los binarios de Linux o había algún tipo de envoltura de máquina virtual o algo similar. Generalmente ejecutar binarios de Linux con MacOS no es posible.

0voto

Jose Chavez Puntos 645

Aconsejaría tratar de ejecutar el ManicTimeServer.dll como el archivo ManicTimeServer es sólo un pequeño stub para Linux que comprueba si tienes instalado .NET Core o no - y luego se ejecuta desde el archivo DLL.

Por ejemplo, intente ejecutar algo como

dotnet ./ManicTimeServer.dll

o:

mono ./ManicTimeServer.dll

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X