Description of problem: I installed lzop-1.04-3.fc32.x86_64. Running lzop with or without a input file and lzo-2.10-1 showed that lzo failed to start due to a library version conflict. lzop Lempel-Ziv-Oberhumer Packer Copyright (C) 1996 - 2017 lzop v1.04 Markus Franz Xaver Johannes Oberhumer Aug 10th 2017 lzo_init() failed - check your LZO installation ! library version conflict (2080, 20a0) - check your LZO installation ! lzo-2.10-1.fc32 also failed to start when using openvpn with a server with the comp-lzo option specific in the configuration file. Thu Feb 27 00:12:32 2020 NOTE: --fast-io is disabled since we are not using UDP Thu Feb 27 00:12:32 2020 Cannot initialize LZO compression library Thu Feb 27 00:12:32 2020 Exiting due to fatal error These errors were reported at https://bugzilla.redhat.com/show_bug.cgi?id=1802299 Downgrading to lzo-2.08-16.fc31.x86_64 fixed the openvpn and lzop errors. Version-Release number of selected component (if applicable): lzo-2.10-1.fc32.x86_64 lzop-1.04-3.fc32.x86_64 openvpn-2.4.8-2.fc32.x86_64 How reproducible: I've seen these errors each of several times. Steps to Reproduce: 1. Boot F32 KDE Plasma spin installation 2. Log in to Plasma on Wayland from sddm 3. sudo dnf install lzop openvpn 4. run konsole 5. lzop 6. use openvpn to connect to an openvpn server with comp-lzo in its configuration file Actual results: lzo 2.10-1 failed to start due to a library version conflict when running lzop Expected results: lzop and openvpn would run normally Additional info: The lzo library version conflict with lzop was reported for patool at https://bugzilla.redhat.com/show_bug.cgi?id=1801248
I tried rebuilding lzop against lzo-2.10 but it did not help surprisingly. I am not sure where the version check is being hardcoded.
Correction: rebuilding against lzo-2.10 has taken care of the library version conflict error, but not the lzo_init one. The error was being highlighted during make check: https://bugzilla.redhat.com/show_bug.cgi?id=1799624#c4 It appears disabling make check was not the way to go after all.
Compiling lzo with -01 instead of -02 fixes the initialization issue. Together with rebuilding lzop against lzo-2.10 it allows lzop to run: <mock-chroot> sh-5.0# lzop Lempel-Ziv-Oberhumer Packer Copyright (C) 1996 - 2017 lzop v1.04 Markus Franz Xaver Johannes Oberhumer Aug 10th 2017 Usage: lzop [-dxlthIVL19] [-qvcfFnNPkUp] [-o file] [-S suffix] [file..] Commands: -1 compress faster -9 compress better -d decompress -x extract (same as -dPp) -l list compressed file -I display system information -t test compressed file -V display version number -h give this help -L display software license Options: -q be quiet -v be verbose -c write on standard output -oFILE write output to 'FILE' -p write output to current dir -pDIR write to path 'DIR' -f force overwrite of output files -n do not restore the original file name (default) -N restore the original file name -P restore or save the original path and file name -S.suf use suffix .suf on compressed files -U delete input files after successful operation (like gzip and bzip2) file.. files to (de)compress. If none given, try standard input. <mock-chroot> sh-5.0# I unfortunately do not have commit access to neither lzo nor lzop. Jakub, would you be able to investigate why -O2 breaks lzo?
I am running a script trying to determine which of the flags added by -O2 is causing trouble, will report back once the script finishes.
Created attachment 1666748 [details] patch adding -fno-strict-aliasing to CFLAGS The attached patch fixes the problem, lzop rebuild is not necessary after all. Could someone with commit access to lzo apply it? Thank you!
gcc bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1808821
(In reply to Julian Sikorski from comment #5) > Created attachment 1666748 [details] > patch adding -fno-strict-aliasing to CFLAGS > > The attached patch fixes the problem, lzop rebuild is not necessary after > all. Could someone with commit access to lzo apply it? Thank you! Thanks Julian. I ran fedpkg clone --anonymous lzo, and then I applied the changed in your patch. I built lzo-2.10-2 with fedpkg --release f32 local and updated lzo with dnf. lzop and openvpn ran correctly with lzo-2.10-2 installed.
I'm pushing out an update with the new CFLAG as this breaks anything trying to use lzo. Upstream needs to fix their code so I'm leaving this bug open.
Proposing as an FE issue, per Michael Cronenworth's email: "Hello, The following update needs some karma so it can be released sooner than 12 days from now. https://bodhi.fedoraproject.org/updates/FEDORA-2020-25291e492f The lzo package was updated last month from 2.08 (dated 2014) to 2.10 (dated 2017). Part of the code in the new version is not properly written to work with gcc aliasing and the resulting binary does not work. I've applied a workaround (disabling gcc strict aliasing) until the maintainer or upstream fixes it. Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1807737 Thanks, Michael" However, note that 'released' is somewhat fuzzy for Branched. updates-testing is enabled by default on Branched installs, so the first time an F32 install with lzo is updated, it will get the fixed lzo even though it has not been pushed to stable yet. We are more likely to grant an FE if lzo may be used during composes, or on live images, or something like that. Is this the case?
+1 FE
Discussed during the 2020-03-09 freeze exception review meeting: [0] Accepted as a freeze exception issue as we believe it will break LZO-based OpenVPN connections in live sessions. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-03-09/f32-blocker-review.2020-03-09-16.01.txt
FEDORA-2020-25291e492f has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-25291e492f
lzo-2.10-2.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, please make note of it in this bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days