Building Static Binary Issue

[werkkrew]

Following the instructions you have on your Nyuu repo using your nexe build script, I get the following error coming from the resulting binary after building:

internal/bootstrap/loaders.js:111
    throw new Error(`No such module: ${module}`);
    ^

Error: No such module: parpar_gf
    at process.binding (internal/bootstrap/loaders.js:111:11)
    at Object.<anonymous> (/home/lib/par2.js:4:18)
    at Module._compile (internal/modules/cjs/loader.js:945:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:962:10)
    at Module.load (internal/modules/cjs/loader.js:798:32)
    at Function.Module._load (internal/modules/cjs/loader.js:711:12)
    at Module.require (internal/modules/cjs/loader.js:838:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/home/lib/parpar.js:3:12)
    at Module._compile (internal/modules/cjs/loader.js:945:30)

node is 12.12.0 nexe is 3.3.2 node sources in the next folder are 4.9.1 yencode-src is latest pulled from your yencode repo

I am trying to build a static binary for linux.

[animetosho]

nexe is 3.3.2

You need to use nexe 1.x.x. You can probably grab it using something like npm install nexe@1.1.3

yencode-src is latest pulled from your yencode repo

I don't think the nexe script is updated to work with the current Git version, so I'm surprised the script actually built anything for you. Latest NPM version (1.0.8) should work - it won't build for Node 12, but it looks like you're building for Node 4, so it should work.

I just tried the build script on a virtual Linux. I did find a small issue with OpenMP linking, which I'll fix, but it otherwise seems to work.

Note that ParPar doesn't have proper dynamic CPU dispatch coded for GCC/Clang compilers, so static binaries are limited to SSE2 instructions. Basically this means it may not perform as well as the NPM install.

[Uukrull]

I finally managed to get it compiled for macOS:

brew install node@12 llvm libomp
git clone https://github.com/animetosho/ParPar.git
cd ParPar
npm install nexe@1.1.3
npm install
cd nexe
mkdir -p node/8.17.0/
wget https://nodejs.org/dist/v8.17.0/node-v8.17.0.tar.gz
tar -xzf node-v8.17.0.tar.gz -C node/8.17.0/
mv node/8.17.0/node-v8.17.0 node/8.17.0/_
wget https://github.com/animetosho/node-yencode/archive/v1.0.8.tar.gz
tar -xzf v1.0.8.tar.gz
mv node-yencode-1.0.8 yencode-src

mac.patch:

diff --git a/nexe/build.js b/nexe/build.js
index de3611a..666382d 100644
--- a/nexe/build.js
+++ b/nexe/build.js
@@ -104,7 +104,7 @@ if(!findGypTarget('crcutil')) {
           "xcode_settings": {
             "OTHER_CFLAGS": ["-msse2", "-O3", "-Wall", "-fopenmp"+openMpLib],
             "OTHER_CXXFLAGS": ["-msse2", "-O3", "-Wall", "-fopenmp"+openMpLib],
-            "OTHER_LDFLAGS": ["-fopenmp"+openMpLib]
+            "OTHER_LDFLAGS": ["-lomp"]
           }
         }]
       ]

git apply mac.patch
CC="/usr/local/opt/llvm/bin/clang -Xpreprocessor -fopenmp" CXX="/usr/local/opt/llvm/bin/clang++ -Xpreprocessor -fopenmp" LDFLAGS="-L/usr/local/opt/llvm/lib" CPPFLAGS="-I/usr/local/opt/llvm/include" /usr/local/opt/node@12/bin/node build.js --fully-static

Tested and working with multi-threaded support on a VM and on a real Mac.

Multiply method used: XOR JIT (128 bit), 8 threads Generating 6144 KiB recovery data (6 slices) from 59.29 MiB of data Calculating: 100.00%

[animetosho]

Thanks for trying that and posting the info!

Usually the -fopenmp flag should link with libomp if necessary, though I've found various quirks across platforms and compilers, which makes it a bit difficult to put in defaults.
Did you try changing this line in build.js instead?

var openMpLib = ''; // for clang, set to '=libomp'

[Uukrull]

The problem is the mac version uses libtool and gives an error with -fopenmp so I have to use the CXX="/usr/local/opt/llvm/bin/clang++ -Xpreprocessor -fopenmp" workaround

For those interested here is the compiled binary

[Uukrull]

Building for linux (Ubuntu Server 19.10):

git clone https://github.com/llvm-mirror/openmp.git
cd openmp
mkdir build
cd build
cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DLIBOMP_ENABLE_SHARED=OFF ..
make -j7
sudo make install
cd ../..
git clone https://github.com/animetosho/ParPar.git
cd ParPar
npm install nexe@1.1.3
npm install
cd nexe
wget https://nodejs.org/dist/v8.17.0/node-v8.17.0.tar.gz
mkdir -p node/8.17.0/
tar -xzf node-v8.17.0.tar.gz -C node/8.17.0/
mv node/8.17.0/node-v8.17.0 node/8.17.0/_
wget https://github.com/animetosho/node-yencode/archive/v1.0.8.tar.gz
tar -xzf v1.0.8.tar.gz
mv node-yencode-1.0.8 yencode-src
sed -i 's/"1"/"7"/g' build.js  #make -j7
node build.js --fully-static

It seems the omp lib isn't linked:

module.cc:(.text+0x532): undefined reference to `omp_set_num_threads' collect2: error: ld returned 1 exit status

Editing /out/node.target.mk and adding -lomp to LIBS:= solves the issue:

./node -s1M -r10% -o test.par2 * Multiply method used: XOR JIT (128 bit), 8 threads Generating 5120 KiB recovery data (5 slices) from 44.09 MiB of data Calculating: 100.00% PAR2 created. Time taken: 0.603 second(s)

[mbruel]

This doesn't seems to work for armv7 (RPI)... I've edited build.js to change the architecture to armv7 var vcBuildArch = "armv7"; // x86 or x64 Then I had a compilation issue within ./node/8.17.0/_/out/parpar_gf.target.mk as there is the -msse2 flag. I've removed it manually. rebuild and now here is my error:

  g++ '-DCRCUTIL_USE_MM_CRC32=0' -I../yencode/crcutil-1.0/code -I../yencode/crcutil-1.0/tests  -pthread -Wall -Wextra -Wno-unused-parameter -O3 -fno-omit-frame-pointer -fno-rtti -fno-exceptions -std=gnu++0x -MMD -MF /home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/.deps//home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/obj.target/crcutil/yencode/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.o.d.raw   -c -o /home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/obj.target/crcutil/yencode/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.o ../yencode/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.cc
In file included from ../yencode/crcutil-1.0/code/crc_casts.h:21,
                 from ../yencode/crcutil-1.0/code/gf_util.h:26,
                 from ../yencode/crcutil-1.0/code/crc32c_sse4.h:22,
                 from ../yencode/crcutil-1.0/code/crc32c_sse4.cc:19:
../yencode/crcutil-1.0/code/platform.h:200:31: warning: this use of "defined" may not be portable [-Wexpansion-to-defined]
 #if GCC_VERSION_AVAILABLE(4, 4)
                               ^
In file included from ../yencode/crcutil-1.0/code/crc_casts.h:21,
                 from ../yencode/crcutil-1.0/code/generic_crc.h:23,
                 from ../yencode/crcutil-1.0/code/multiword_64_64_cl_i386_mmx.cc:18:
../yencode/crcutil-1.0/code/platform.h:200:31: warning: this use of "defined" may not be portable [-Wexpansion-to-defined]
 #if GCC_VERSION_AVAILABLE(4, 4)
                               ^
In file included from ../yencode/crcutil-1.0/code/crc_casts.h:21,
                 from ../yencode/crcutil-1.0/code/gf_util.h:26,
                 from ../yencode/crcutil-1.0/code/crc32c_sse4.h:22,
                 from ../yencode/crcutil-1.0/code/crc32c_sse4.cc:19:
../yencode/crcutil-1.0/code/platform.h:200:31: warning: this use of "defined" may not be portable [-Wexpansion-to-defined]
 #if GCC_VERSION_AVAILABLE(4, 4)
                               ^
In file included from ../yencode/crcutil-1.0/code/crc_casts.h:21,
                 from ../yencode/crcutil-1.0/code/generic_crc.h:23,
                 from ../yencode/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.cc:43:
../yencode/crcutil-1.0/code/platform.h:200:31: warning: this use of "defined" may not be portable [-Wexpansion-to-defined]
 #if GCC_VERSION_AVAILABLE(4, 4)
                               ^
In file included from ../yencode/crcutil-1.0/code/crc_casts.h:21,
                 from ../yencode/crcutil-1.0/code/generic_crc.h:23,
                 from ../yencode/crcutil-1.0/code/multiword_64_64_cl_i386_mmx.cc:18:
../yencode/crcutil-1.0/code/platform.h:200:31: warning: this use of "defined" may not be portable [-Wexpansion-to-defined]
 #if GCC_VERSION_AVAILABLE(4, 4)
                               ^
  g++ '-DCRCUTIL_USE_MM_CRC32=0' -I../yencode/crcutil-1.0/code -I../yencode/crcutil-1.0/tests  -pthread -Wall -Wextra -Wno-unused-parameter -O3 -fno-omit-frame-pointer -fno-rtti -fno-exceptions -std=gnu++0x -MMD -MF /home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/.deps//home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/obj.target/crcutil/yencode/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.o.d.raw   -c -o /home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/obj.target/crcutil/yencode/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.o ../yencode/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.cc
sed: can't read /home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/.deps//home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/obj.target/crcutil/yencode/crcutil-1.0/code/crc32c_sse4.o.d.raw: No such file or directory
rm: cannot remove '/home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/.deps//home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/obj.target/crcutil/yencode/crcutil-1.0/code/crc32c_sse4.o.d.raw': No such file or directory
  g++ '-DCRCUTIL_USE_MM_CRC32=0' -I../yencode/crcutil-1.0/code -I../yencode/crcutil-1.0/tests  -pthread -Wall -Wextra -Wno-unused-parameter -O3 -fno-omit-frame-pointer -fno-rtti -fno-exceptions -std=gnu++0x -MMD -MF /home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/.deps//home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/obj.target/crcutil/yencode/crcutil-1.0/code/multiword_64_64_gcc_i386_mmx.o.d.raw   -c -o /home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/obj.target/crcutil/yencode/crcutil-1.0/code/multiword_64_64_gcc_i386_mmx.o ../yencode/crcutil-1.0/code/multiword_64_64_gcc_i386_mmx.cc
In file included from ../yencode/crcutil-1.0/code/crc_casts.h:21,
                 from ../yencode/crcutil-1.0/code/generic_crc.h:23,
                 from ../yencode/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.cc:43:
../yencode/crcutil-1.0/code/platform.h:200:31: warning: this use of "defined" may not be portable [-Wexpansion-to-defined]
 #if GCC_VERSION_AVAILABLE(4, 4)
                               ^
make[1]: *** [crcutil.target.mk:79: /home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/obj.target/crcutil/yencode/crcutil-1.0/code/crc32c_sse4.o] Error 1
make[1]: *** Waiting for unfinished jobs....
sed: can't read /home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/.deps//home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/obj.target/crcutil/yencode/crcutil-1.0/code/multiword_64_64_cl_i386_mmx.o.d.raw: No such file or directory
rm: cannot remove '/home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/.deps//home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/obj.target/crcutil/yencode/crcutil-1.0/code/multiword_64_64_cl_i386_mmx.o.d.raw': No such file or directory
make[1]: *** [crcutil.target.mk:79: /home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/obj.target/crcutil/yencode/crcutil-1.0/code/multiword_64_64_cl_i386_mmx.o] Error 1
make[1]: *** Waiting for unfinished jobs....
In file included from ../yencode/crcutil-1.0/code/crc_casts.h:21,
                 from ../yencode/crcutil-1.0/code/generic_crc.h:23,
                 from ../yencode/crcutil-1.0/code/multiword_64_64_gcc_i386_mmx.cc:17:
../yencode/crcutil-1.0/code/platform.h:200:31: warning: this use of "defined" may not be portable [-Wexpansion-to-defined]
 #if GCC_VERSION_AVAILABLE(4, 4)
                               ^
sed: can't read /home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/.deps//home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/obj.target/crcutil/yencode/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.o.d.raw: No such file or directory
make[1]: *** [crcutil.target.mk:79: /home/pi/apps/ParPar/nexe/node/8.17.0/_/out/Release/obj.target/crcutil/yencode/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.o] Error 2
rm 5353994ccc851d0b6dd4665a400cf5ed68f1b7a7.intermediate
make: *** [Makefile:88: node] Error 2
make: *** [Makefile:88: node] Error 2
....> ERROR: The release executable has not been generated. This indicates a failure in the build process. There is likely additional information above.

Here is the content of ./node/8.17.0/_/out/crcutil.target.mk shouldn't it looking for armv7 versions instead of i386 or amd64?

# This file is generated by gyp; do not edit.

TOOLSET := target
TARGET := crcutil
DEFS_Debug := \
    '-DCRCUTIL_USE_MM_CRC32=0' \
    '-DDEBUG' \
    '-D_DEBUG' \
    '-DV8_ENABLE_CHECKS'

# Flags passed to all source files.
CFLAGS_Debug := \
    -pthread \
    -Wall \
    -Wextra \
    -Wno-unused-parameter \
    -g \
    -O0

# Flags passed to only C files.
CFLAGS_C_Debug :=

# Flags passed to only C++ files.
CFLAGS_CC_Debug := \
    -fno-rtti \
    -fno-exceptions \
    -std=gnu++0x

INCS_Debug := \
    -I$(srcdir)/yencode/crcutil-1.0/code \
    -I$(srcdir)/yencode/crcutil-1.0/tests

DEFS_Release := \
    '-DCRCUTIL_USE_MM_CRC32=0'

# Flags passed to all source files.
CFLAGS_Release := \
    -pthread \
    -Wall \
    -Wextra \
    -Wno-unused-parameter \
    -O3 \
    -fno-omit-frame-pointer

# Flags passed to only C files.
CFLAGS_C_Release :=

# Flags passed to only C++ files.
CFLAGS_CC_Release := \
    -fno-rtti \
    -fno-exceptions \
    -std=gnu++0x

INCS_Release := \
    -I$(srcdir)/yencode/crcutil-1.0/code \
    -I$(srcdir)/yencode/crcutil-1.0/tests

OBJS := \
    $(obj).target/$(TARGET)/yencode/crcutil-1.0/code/crc32c_sse4.o \
    $(obj).target/$(TARGET)/yencode/crcutil-1.0/code/multiword_64_64_cl_i386_mmx.o \
    $(obj).target/$(TARGET)/yencode/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.o \
    $(obj).target/$(TARGET)/yencode/crcutil-1.0/code/multiword_64_64_gcc_i386_mmx.o \
    $(obj).target/$(TARGET)/yencode/crcutil-1.0/code/multiword_64_64_intrinsic_i386_mmx.o \
    $(obj).target/$(TARGET)/yencode/crcutil-1.0/code/multiword_128_64_gcc_amd64_sse2.o \
    $(obj).target/$(TARGET)/yencode/crcutil-1.0/examples/interface.o

# Add to the list of files we specially track dependencies for.
all_deps += $(OBJS)

# CFLAGS et al overrides must be target-local.
# See "Target-specific Variable Values" in the GNU Make manual.
$(OBJS): TOOLSET := $(TOOLSET)
$(OBJS): GYP_CFLAGS := $(DEFS_$(BUILDTYPE)) $(INCS_$(BUILDTYPE))  $(CFLAGS_$(BUILDTYPE)) $(CFLAGS_C_$(BUILDTYPE))
$(OBJS): GYP_CXXFLAGS := $(DEFS_$(BUILDTYPE)) $(INCS_$(BUILDTYPE))  $(CFLAGS_$(BUILDTYPE)) $(CFLAGS_CC_$(BUILDTYPE))

# Suffix rules, putting all outputs into $(obj).

$(obj).$(TOOLSET)/$(TARGET)/%.o: $(srcdir)/%.cc FORCE_DO_CMD
    @$(call do_cmd,cxx,1)

# Try building from generated source, too.

$(obj).$(TOOLSET)/$(TARGET)/%.o: $(obj).$(TOOLSET)/%.cc FORCE_DO_CMD
    @$(call do_cmd,cxx,1)

$(obj).$(TOOLSET)/$(TARGET)/%.o: $(obj)/%.cc FORCE_DO_CMD
    @$(call do_cmd,cxx,1)

# End of this set of suffix rules
### Rules for final target.
LDFLAGS_Debug := \
    -pthread \
    -rdynamic

LDFLAGS_Release := \
    -pthread \
    -rdynamic

LIBS := \
    -static

$(obj).target/libcrcutil.a: GYP_LDFLAGS := $(LDFLAGS_$(BUILDTYPE))
$(obj).target/libcrcutil.a: LIBS := $(LIBS)
$(obj).target/libcrcutil.a: TOOLSET := $(TOOLSET)
$(obj).target/libcrcutil.a: $(OBJS) FORCE_DO_CMD
    $(call do_cmd,alink_thin)

all_deps += $(obj).target/libcrcutil.a
# Add target alias
.PHONY: crcutil
crcutil: $(obj).target/libcrcutil.a

# Add target alias to "all" target.
.PHONY: all
all: crcutil

[animetosho]

Oh yeah, the nexe script wasn't designed to work with non-x86 compiles. I'll get around to seeing if it can be fixed for ARM.
ARM doesn't really have the ISA extension issues that x86 does, so you could also take the pkg approach to building.

var vcBuildArch = "armv7"; // x86 or x64

That variable is actually for building with Visual C++ (I haven't tested any ARM builds with MSVC and have no idea if they work).

The -msse2 flag should get replaced with -mfpu=neon on ARMv7 (and removed for AArch64).
The crcutil library includes a bunch of x86 specific stuff, but it shouldn't be trying to build it for ARM. I'll look at it when I get some more time.

[animetosho]

Okay, I think this fixes it. Am retrying it with a full build, but it takes hours on a Raspberry Pi 3.

You'll need to change the line in build.js:

var isaBaseFlag = ',"-msse2"'; // set to blank for non-x86 targets

to:

var isaBaseFlag = '';

I'll improve the detection routine eventually, but this should suffice for now.

[mbruel]

Hello, it builds! tooks like 40min on RPI4... nice job! ;) and as I said already, the perf are not so bad on RPI4:

pi@raspberrypi:~/ngPost $ ~/apps/parpar -s 1M -r8% -o Joker.par2 Joker.2019.VOSTFR.720p.AMZN.WEB-DL.AAC.x264-ETRG.mkv 
Multiply method used: Shuffle (64 bit), 4 threads
Generating 84 MiB recovery data (84 slices) from 1040.6 MiB of data
Calculating: 100.00%
PAR2 created. Time taken: 42.677 second(s)

I'll probably embed ParPar compiled version with ngPost in the next release. Thanks for the support

[mbruel]

hum but it doesn't look really stable. getting some segmentation faults sometimes. it seems more likely to happen when parpar binary is not in the current directory. can't reproduce the segfault using gdb... it happened on my RPI doing parpar --help or adding a wrong option for example. Also generating the par2. it seems that after one point it succeed to do the job (not crash) then it won't crash again with the same args... weird

[animetosho]

I can't seem to reproduce your issue. I've attached the output binary of my build on Raspian 10 (may not be fully static due to using glibc, but may work in your environment):

parpar.xz.zip

(Github won't accept .xz attachments, so you'll need to unpack the above twice)

For segfaults, you can try enabling core dumps, generating the segfault and then loading the dump in GDB. Though, to me, it sounds like you'll probably get crashes in different random places, so it likely won't give any useful info (also, by default, the builds have debugging symbols stripped, to reduce size, so output will be even less useful).

[edc71]

can you supply a linux 64 bit version.. tried building on vm and wsl.. always get the following error

Warning Cannot include addon %1 into executable. The addon must be distributed with executable as %2. Q:\ParPar-master\node_modules\yencode\build\Release\yencode.node path-to-executable/yencode.node

[animetosho]

You mean x86-64? The current recommended installation procedure is documented in the readme - I currently only provide Windows binaries.

[edc71]

I mean linux executable 64 bit.. I am a node.js noob. And since there are nyuu builds around for linux 64 bit Id expect it isnt that hard to build parpar for linux too

[animetosho]

ParPar currently doesn't have proper dynamic dispatch for GCC/Clang compilers, so binaries built for Linux aren't portable and hence need to be built for each machine.
I plan to fix this up eventually, but at the moment you can't compile a fully functioning portable Linux build, which is why the recommended installation routine on Linux is via NPM.

There's also a second issue - glibc doesn't seem to like static linking, so I'll need to investigate that too.

Most Linux distros now have NPM in their repositories, so it's a simple matter of installing that, and then using the command written in the readme.

[Uukrull]

@edc71 You can try this version I compiled. I tested it on Ubuntu, Debian and Arch Linux and worked on all of them.

It's profiled with -fprofile-generate/use and the only modification I did was a more user friendly output for the time taken info:

diff --git a/bin/parpar.js b/bin/parpar.js
index b65bb84..3fc9657 100755
--- a/bin/parpar.js
+++ b/bin/parpar.js
@@ -471,7 +471,12 @@ var inputFiles = argv._;
            }
            if(!argv.quiet) {
                var endTime = Date.now();
-               process.stderr.write('\nPAR2 created. Time taken: ' + ((endTime - startTime)/1000) + ' second(s)\n');
+               var totalTime = (endTime - startTime) / 1000;
+               process.stderr.write('\nPAR2 created. Time taken: ' +
+                   ('00' + Math.trunc(totalTime / 3600)).slice(-2) + ':' +
+                   ('00' + Math.trunc(totalTime % 3600 / 60)).slice(-2) + ':' +
+                   ('00' + Math.trunc(totalTime % 60)).slice(-2) + '.' +
+                   ((totalTime - Math.floor(totalTime)).toFixed(3)).slice(2) + '\n');
            }
        }); 

[edc71]

@Uukrull Tnx for that one.. much appreciated.

[mbruel]

I can't seem to reproduce your issue. I've attached the output binary of my build on Raspian 10 (may not be fully static due to using glibc, but may work in your environment):

parpar.xz.zip

(Github won't accept .xz attachments, so you'll need to unpack the above twice)

For segfaults, you can try enabling core dumps, generating the segfault and then loading the dump in GDB. Though, to me, it sounds like you'll probably get crashes in different random places, so it likely won't give any useful info (also, by default, the builds have debugging symbols stripped, to reduce size, so output will be even less useful).

Hi man, sorry for the delay, I did a pause on ngPost and thus on this too... as someone opened an issue on RPI, I've tested your parpar version. It seems more stable than the one I made but I didn't do many tests... just 3 times within ngPost.... So I've included it in ngPost_v4.4.1-armhf.AppImage and will probably integrate it for all OS in the next release when I'll have done some work to custom easily all the arguments and maybe make an auto settings feature depending on the size of the inputs.

[heartbleeded]

I can confirm that parpar got crashed from time to time on my Raspberry Pi 4b+. Both that link provided by @animetosho above and the one statically linked in ngPost_v4.4.1-armhf.AppImage.

Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux
Description:    Raspbian GNU/Linux 10 (buster)

[animetosho]

The builds here are several years old so I can't realistically help much. Could you try a current version and see if you still get issues?
If so, could you provide more info on when it's crashing, and an example command + output?