分析

Question

无法使用以下命令构建Electron App的可执行文件：

electron-packager . electron-tutorial-app --overwrite --asar=true --platform=linux --arch=x64 --prune=true --out=release-builds

作为共享库文件（application / x-sharedlib）的构建文件未在Ubuntu 18 OS上执行。

有没有办法做到这一点？

Answer 1

当使用electron-packager来打包带有Electron版本4.0.x的Linux应用程序时，这是一个问题，而以前的Electron版本（例如3.1.x）没有问题。

由于某种原因，在Electron 4.0.x中，生成的应用程序文件是共享库，而不是可执行文件。

在“终端”窗口中，在应用程序文件路径上运行file命令将提供：

ELF 64位LSB共享对象，x86-64，版本1（SYSV）动态链接，用于GNU / Linux 3.2.0的解释器/lib64/ld-linux-x86-64.so.2， BuildID [sha1] = b9e8ba37118dad1bf605affef41026f813215bc6，已剥离

它曾经是：

ELF 64位LSB可执行文件x86-64版本1（SYSV）动态链接，对于GNU / Linux 2.6.32的解释器/lib64/ld-linux-x86-64.so.2，剥了

幸运的是，尽管很麻烦，但仍然可以通过从“终端”窗口启动应用程序来运行该应用程序，例如，将应用程序文件图标拖到终端提示符上，然后按Enter。

Answer 2

TL; DR：生成的文件实际上是新格式的可执行文件。他们没有错。 Nautilus /文件管理器错误地将它们识别为可执行文件。有一些解决方案，例如创建* .desktop文件以启动应用程序。

这种现象是Electron生成Linux二进制文件方式改变的副作用。提交9294facf将二进制格式从ELF更改为PIE。所做的更改很小，仅影响单个文件（BUILD.gn）。该更改已从4.0.0版开始出现在Electron中。

文件管理器利用file命令来决定如何处理文件（例如，打开图像查看器，文本编辑器或执行文件）。 file无法区分共享库和PIE可执行文件，因此对PIE文件进行了错误分类（请参阅相应的bug report）。

解决方案

由于该问题仅存在于图形文件管理器中，因此您可以简单地从终端或脚本中运行可执行文件。对于非技术性最终用户而言，这有些涉及，而不是OP想要的。

等待file将PIE识别为可执行文件。反过来，这可能会导致Nautilus等文件管理器正确启动PIE。目前尚不清楚是否或何时会发生这种情况。如果发生这种情况，它将可能仅包含在将来的发行版中。

创建一个桌面文件以启动该应用程序。无论如何，这是启动桌面应用程序的常见方式。

创建一个名为myapp.desktop的文件，其内容如下。

[Desktop Entry]
Name=My Application
Exec=/path/to/binary
Terminal=false
Type=Application
StartupNotify=true
Encoding=UTF-8

然后，通过发出chmod +x myapp.desktop标记桌面文件可执行文件。双击该文件应会按预期启动该应用程序。

其他信息

电子包装项目中相应的讨论：https://github.com/electron-userland/electron-packager/issues/901。（要点：此问题不是由电子包装机引起的，请向上游看

电子项目中的相应问题是https://github.com/electron/electron/issues/15406。（要点：他们想在Linux上启用PIE。不是我们的错误，请向上游看）

Answer 3

对于Linux（Ubuntu）：

对于全局（如果需要）

npm install -g electron@3.1.6

执行electron-packager命令-对于Linux：

电子包装机。 electronic-tutorial-app --overwrite --asar --platform = linux --arch = all --prune = true --out = release-builds

这将导致4个Linux文件夹（arch = all）。根据您的操作系统选择一个可以运行的可执行文件。