[sabnzbd] par2 issue with libgomp.so.1

[jms667]

Hello,
Probably since I have upgraded to sabnzbd1.2.3 (running on a xpenology box), corrupted files are not repaired with PAR2 anymore. Executing par2 comand will lead to the following error msg :

error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory

But libgomp.so.1 is located in /lib directory.
I have posted in sabnzb forum, but dev it's not a sabnzbd issue but more probably a packaging issue. Please see this post : https://forums.sabnzbd.org/viewtopic.php?f=2&t=22568

I have the same issue with sabnzbd-testing.

Thanks for your help.

Setup

Package Name: sabnzbd 1.2.3-22 AND sabnzbd-testing 2.0.0RC1-22
Package Version: sabnzbd 1.2.3-22 AND sabnzbd-testing 2.0.0RC1-22

NAS Model: XPEnology box
NAS Architecture: x86
DSM version: DSM 5.2-5967

Expected behavior

When corrupted downloaded files are detected, they should be repaired with PAR2.

Actual behavior

PAR2 repairing fails.
PAR2 command fails with the following error msg :

error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory

Steps to reproduce

1. Install sabnzbd OR sabnzbd-testing package
2. Launch PAR2 command

Package log

Check Package Center or /usr/local/{package}/var/

2017-04-07 18:59:15,606::DEBUG::[newsunpack:1194] Starting par2: ['/usr/local/sabnzbd/bin/nice', '-n15', '/usr/local/sabnzbd/bin/par2', 'r', '', '/volume1/data/Download-Temp/incomplete/13e
2017-04-07 18:59:15,650::DEBUG::[newsunpack:1510] PAR2 output was
/usr/local/sabnzbd/bin/par2: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory
2017-04-07 18:59:15,650::INFO::[newsunpack:1034] Par verify failed on /volume1/data/Download-Temp/incomplete/13eb7275007d3a2217068c7b3a004de6.01/13eb7275007d3a2217068c7b3a004de6.par2!

Additional log

NANOBOOT> ls -l /lib/libgomp.so.1
-r-xr-xr-x    1 root     root         50984 Apr 26  2016 /lib/libgomp.so.1
NANOBOOT>
NANOBOOT> /volume1/@appstore/sabnzbd/bin/par2
/volume1/@appstore/sabnzbd/bin/par2: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory
NANOBOOT>
NANOBOOT> /volume1/@appstore/sabnzbd-testing//bin/par2
/volume1/@appstore/sabnzbd-testing//bin/par2: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory
NANOBOOT>

[KaraokeStu]

Hi, I've got some further tests to do later on 2.0.0 so will take a look when I get a chance

[jms667]

Thanks KaraokeStu. Hope you will have time to check this because its really annoying.
Perhaps could you quickly launch par2 command in order to check if you will get the same error message ?

[KaraokeStu]

I'm running xpenology on jun's loader for dsm 6 and the par commands all work perfectly.

I'll test on the dsm 5 virtual box as soon as I get the chance

[jms667]

Hi, is there something new about this issue ?

A couple of days a go, I figured out that I had a second xpenology test vm running on my esx (running same DSM version as my 'production' one). I started it again and noticed that sabnzbd was running version 1.0.3-16. I did a copy of the par2 binary from testing DSM to production DSM. Now, execution of the par2 command is again working fine (no libgomp.so.1 error anymore) :

`NANOBOOT> /volume1/@appstore/sabnzbd/bin/par2
Not enough command line arguments.
par2cmdline version 0.4, Copyright (C) 2003 Peter Brian Clements.

par2cmdline comes with ABSOLUTELY NO WARRANTY.

This is free software, and you are welcome to redistribute it and/or modify
it under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your
option) any later version. See COPYING for details.


Usage:

  par2 c(reate) [options] <par2 file> [files] : Create PAR2 files
  par2 v(erify) [options] <par2 file> [files] : Verify files using PAR2 file
  par2 r(epair) [options] <par2 file> [files] : Repair files using PAR2 files

You may also leave out the "c", "v", and "r" commands by using "parcreate",
"par2verify", or "par2repair" instead.

Options:

  -b<n>  : Set the Block-Count
  -s<n>  : Set the Block-Size (Don't use both -b and -s)
  -r<n>  : Level of Redundancy (%%)
  -c<n>  : Recovery block count (Don't use both -r and -c)
  -f<n>  : First Recovery-Block-Number
  -u     : Uniform recovery file sizes
  -l     : Limit size of recovery files (Don't use both -u and -l)
  -n<n>  : Number of recovery files (Don't use both -n and -l)
  -m<n>  : Memory (in MB) to use
  -v [-v]: Be more verbose
  -q [-q]: Be more quiet (-q -q gives silence)
  --     : Treat all remaining CommandLine as filenames

If you wish to create par2 files for a single source file, you may leave
out the name of the par2 file from the command line.`

Since that modification, par repairing process is working fine again.
Hope it will help.

[Safihre]

Another user reporting the same error:
https://forums.sabnzbd.org/viewtopic.php?f=2&t=22657

[byronmccollum]

I have the same issue.

Synology> cd /volume1/@appstore/sabnzbd/bin/
Synology> ./par2
./par2: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory
Synology> 

DSM 5.2-5644
SABnzbd 2.0.0-24

[Safihre]

@KaraokeStu What could this be? Can you inspect the distributed packages to see if the file is actually present? Or could some platforms not have the right header files for some reason?

Second thing: par2cmdline itself now has merged the OpenMP changes and also applied some fixes, maybe we should switch to that?
https://github.com/Parchive/par2cmdline/releases

If you have time 😉

[KaraokeStu]

It does seem quite strange. If the standard par2cmdline now has the changes, I see no reason not to switch back. It'll be around 2 weeks, though, as I'll be on holiday!

[flobroed]

Same here... :(
Syno 210j, DSM 5.2-5967 Update 2 (there is no v6 for this filer, which makes the error even worse.), SABnzbd 2.0.0-24

@jms667 can you share that module? I really would like to have this functionality back on mine.

[jms667]

@flobroed : Sure, here it is
https://mega.nz/#!TNgyhYKZ!R_J7DByfdld6ioG02M_w1dCVqBVnocjj2zcErnpjNww
Just replace /volume1/@appstore/sabnzbd/bin/par2 with this one.

[flobroed]

Damn, no luck on my synology...

Anything I'm missing out?

xxx> /volume1/@appstore/sabnzbd/bin/par2 /volume1/@appstore/sabnzbd/bin/par2: line 1: can't open AZ: no such file /volume1/@appstore/sabnzbd/bin/par2: line 1:ELF: not found /volume1/@appstore/sabnzbd/bin/par2: line 1: Q3FWD not found /volume1/@appstore/sabnzbd/bin/par2: line 2: syntax error: unexpected ")"

[byronmccollum]

@flobroed I'm guessing different CPU architectures. The binary @jms667 linked is x86_64. I'd guess the DS210J is a different architecture.

[flobroed]

Is there any way to downgrade the sabnzb package? Anyone having an older package available?

[Safihre]

Does the system have any tools to compile available? You could just compile it yourself then:https://sabnzbd.org/wiki/installation/multicore-par2 (at the bottom)

[Safihre]

@KaraokeStu When you get back, could you also take a look at the Python package?
Users have reported crazy memory usages, not just for SABnzbd but also SickRage using 350MB idle (on DSM6) after doing some work. Or SAB using 600MB after downloading something and returning back to idle.
Looks like all the compiler settings for Python haven't been touched in years, maybe it's something there?

[flobroed]

Hi guys.
Thanks for the help. I managed to manually compile par2cmdline and it's working again. :)

xxx> ls -la par2*
lrwxrwxrwx 1 root root 19 Jun 3 14:41 par2 -> /usr/local/bin/par2
-rwxr-xr-x 1 sabnzbd root 334272 Apr 17 14:04 par2_backsave
lrwxrwxrwx 1 root root 4 Apr 17 14:04 par2create -> par2
lrwxrwxrwx 1 root root 4 Apr 17 14:04 par2repair -> par2
lrwxrwxrwx 1 root root 4 Apr 17 14:04 par2verify -> par2
xxx> par2 -V
par2cmdline version 0.7.2

If anyone stumbles upon this thread: During the compile I had an issue with aclocal, which had been provided as part of automake through ipkg. This was NOT working at all.

I resorted to also compiling libtool and automake from source and thus replacing the ipkg versions. Instruction for that can be found here: http://www.synology-forum.de/showthread.html?41226-hocr2pdf-auf-ds411-II/page2 (you just have to update the links for the respective websites, as the thread is 2 years old).

And here is the par2 for Marvel ARMv5TE Processors --> https://mega.nz/#!hOJ0UaSR!wR0QQDsAK3gTBeHKTpX-dNiQmI8UJIuJZp8_iT4hLDA (see http://www.synology-wiki.de/index.php/Welchen_Prozessortyp_besitzt_mein_System%3F for an overview of the filers which use that CPU).

Anyway: Would be nice to fix this for v5 users on DSM for good, as the version in the SABnzbd package is obviously broken.

Best regards from Germany.

[Safihre]

The version does work for many other people. It seems some specific tool chains are not working and need to be fixed!

[KaraokeStu]

This should now be resolved, I'm going to publish the new SPKs for the sabnzbd versions shortly.

@jms667 and @flobroed could you test on your architectures once you see the new version?

[jms667]

@KaraokeStu : Yes, no problem.

[KaraokeStu]

Builds are now published - thanks in advance everyone!

[KaraokeStu]

Just so you know on "par2 create" I'm still getting the libgomp.so and libstdc.so errors, however it does still work correctly - it is just unable to get the version information

[KaraokeStu]

It appears to be because I've build the binaries against the DSM 5.x toolchains, but am running them on the DSM 6.x live system. The code, however, does still work!

To create my par2 files...

/var/packages/sabnzbd-testing/target/bin/par2 create PlexMediaServer-0.9.16.6.1993-5089475-            x86.spk.par2 PlexMediaServer-0.9.16.6.1993-5089475-x86.spk
/var/packages/sabnzbd-testing/target/bin/par2: /lib/libgomp.so.1: no version information available (required by /var/packages            /sabnzbd-testing/target/bin/par2)
/var/packages/sabnzbd-testing/target/bin/par2: /lib/libgomp.so.1: no version information available (required by /var/packages            /sabnzbd-testing/target/bin/par2)
/var/packages/sabnzbd-testing/target/bin/par2: /lib/libstdc++.so.6: no version information available (required by /var/packag            es/sabnzbd-testing/target/bin/par2)
/var/packages/sabnzbd-testing/target/bin/par2: /lib/libstdc++.so.6: no version information available (required by /var/packag            es/sabnzbd-testing/target/bin/par2)
/var/packages/sabnzbd-testing/target/bin/par2: /lib/libstdc++.so.6: no version information available (required by /var/packag            es/sabnzbd-testing/target/bin/par2)

Block size: 59708
Source file count: 1
Source block count: 2000
Redundancy: 5%
Recovery block count: 100
Recovery file count: 7

Opening: PlexMediaServer-0.9.16.6.1993-5089475-x86.spk
Computing Reed Solomon matrix.
Constructing: done.
Wrote 5970800 bytes to disk
Writing recovery packets
Writing verification packets
Done

And to verify:

/var/packages/sabnzbd-testing/target/bin/par2 verify PlexMediaServer-0.9.16.6.1993-5089475-            x86.spk.par2
/var/packages/sabnzbd-testing/target/bin/par2: /lib/libgomp.so.1: no version information available (required by /var/packages            /sabnzbd-testing/target/bin/par2)
/var/packages/sabnzbd-testing/target/bin/par2: /lib/libgomp.so.1: no version information available (required by /var/packages            /sabnzbd-testing/target/bin/par2)
/var/packages/sabnzbd-testing/target/bin/par2: /lib/libstdc++.so.6: no version information available (required by /var/packag            es/sabnzbd-testing/target/bin/par2)
/var/packages/sabnzbd-testing/target/bin/par2: /lib/libstdc++.so.6: no version information available (required by /var/packag            es/sabnzbd-testing/target/bin/par2)
/var/packages/sabnzbd-testing/target/bin/par2: /lib/libstdc++.so.6: no version information available (required by /var/packag            es/sabnzbd-testing/target/bin/par2)
Loading "PlexMediaServer-0.9.16.6.1993-5089475-x86.spk.par2".
Loaded 4 new packets
Loading "PlexMediaServer-0.9.16.6.1993-5089475-x86.spk.vol000+01.par2".
Loaded 1 new packets including 1 recovery blocks
Loading "PlexMediaServer-0.9.16.6.1993-5089475-x86.spk.vol001+02.par2".
Loaded 2 new packets including 2 recovery blocks
Loading "PlexMediaServer-0.9.16.6.1993-5089475-x86.spk.vol003+04.par2".
Loaded 4 new packets including 4 recovery blocks
Loading "PlexMediaServer-0.9.16.6.1993-5089475-x86.spk.vol007+08.par2".
Loaded 8 new packets including 8 recovery blocks
Loading "PlexMediaServer-0.9.16.6.1993-5089475-x86.spk.vol015+16.par2".
Loaded 16 new packets including 16 recovery blocks
Loading "PlexMediaServer-0.9.16.6.1993-5089475-x86.spk.vol031+32.par2".
Loaded 32 new packets including 32 recovery blocks
Loading "PlexMediaServer-0.9.16.6.1993-5089475-x86.spk.vol063+37.par2".
Loaded 37 new packets including 37 recovery blocks
Loading "PlexMediaServer-0.9.16.6.1993-5089475-x86.spk.par2".
No new packets found

There are 1 recoverable files and 0 other files.
The block size used was 59708 bytes.
There are a total of 2000 data blocks.
The total size of the data files is 119408640 bytes.

Verifying source files:

Target: "PlexMediaServer-0.9.16.6.1993-5089475-x86.spk" - found.

All files are correct, repair is not required.

[jms667]

After upgrading to 2.0.1-26, I still have the same error output running par2 binary.
NANOBOOT> ./par2 ./par2: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory
Is it 'normal' ? How can I check that sabnzbd will process par2 repairing correctly without downloading new corrupted stuff ?

[KaraokeStu]

See now that's a new issue for me... I'll look into this further - what architecture are you using?

[KaraokeStu]

To test, try finding a file that's at least 100MB.

Then type par2 create test.par2 testfile.xyz where testfile.xyz is your file.

If it creates the par2 files, then it'll be able to create, verify and repair fine

[jms667]

Same issue, test fails.

NANOBOOT> /volume1/@appstore/sabnzbd/bin/par2 create temp.par2 file.mp4 /volume1/@appstore/sabnzbd/bin/par2: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory

I guess my architecture is bromolow/x86_64. Hardware is a HP N54L.

NANOBOOT> cat /proc/cpuinfo | grep "processor\|model name" processor : 0 model name : AMD Turion(tm) II Neo N54L Dual-Core Processor processor : 1 model name : AMD Turion(tm) II Neo N54L Dual-Core Processor

And software is xpenology, fake 3615xs Synology hosted by an ESXi6 vm.

NANOBOOT> uname -a Linux NANOBOOT 3.10.35 #1 SMP Sun Jul 17 16:02:22 CEST 2016 x86_64 GNU/Linux synology_bromolow_3615xs

[KaraokeStu]

That's really weird, as other than an Intel cpu, I'm running the same. What's your DSM version?

[jms667]

DSM version: DSM 5.2-5967

[KaraokeStu]

OK, so I've narrowed it down and got it working with DSM 5.x, however we lose the mutli-threading at the moment.

@Dr-Bean, @cytec or @Diaoul any ideas how to get this to cross-compile with openmp support?

[KaraokeStu]

@Safihre I've managed to get things working by statically linking par2cmdline - anyone have any issues with par2 being 4.5Mb rather than 500Kb?

[Safihre]

For the windows binary of par2cmdline the same thing happened. Here he applied the Strip command to reduce the size: Parchive/par2cmdline#94 (comment)

But then again, I doubt it really matters since 4.5MB is not a lot..

[KaraokeStu]

Tested and confirmed working on both DSM 5 and DSM 6

[Safihre]

Thanks a lot!!

[jms667]

Yes ! Thanks @KaraokeStu.
I've also tested on my xpenology box. It's working again.