Arch Linux User Repository

• Pkgbuild maintained at https://github.com/FabioLolix/PKGBUILD-AUR_fix

• every time you have error while loading shared libraries: libXXX.so.XXX: cannot open shared object file: No such file or directory for build from source programs you have to rebuild it

Another package goes to the ignore list - opencv. Upgrading it to the latest v4.8.0 causes nomacs to not open when I click an image anymore. Downgrading it to 4.7.0 fixes that.

@rado84 you need rebuild the package not to hold back other packages, it is the same every time a dinamically linked soname changes

$ nomacs
nomacs: error while loading shared libraries: libopencv_imgproc.so.407: cannot open shared object file: No such file or directory

• implement checkrebuild from rebuild-detector into your workflow.

Ping! Please read the comment below.

Hello! I have found some fixes you can apply to your package, and also will tell you how to fix check.

• Add ninja to makedepends, use it while building the package via -GNinja and replace ctest invocation with ninja -C build check. This works because tests are only enabled at build time, not built! This will build and run the tests. As for why invoke ninja directly, not sure, but upstream CI does the same.

• Since you have decided to use the Release build type, add -DCMAKE_C_FLAGS_RELEASE="-DNDEBUG" and do the same for its CXX variant, this enables -O2 instead of -O3. Source: https://wiki.archlinux.org/title/CMake_package_guidelines#Fixing_the_automatic_optimization_flag_override

• Add -DUSE_SYSTEM_QUAZIP=ON to enable the usage of system quazip, this is suggested by a cmake warning at build.

• Can you please check the usage of libglvnd? namcap says it might not be needed.

By the time I got to tell you about most of the fixes, you already did them yourself! Cheers!

@FabioLolix Sorry, adding pull requests to your github page won't solve the problem, which is that you are sometimes slow to update, and your packages sometimes stay in an unusable state. That's fine; we are all unpaid volunteers, and I don't ascribe any blame! However, if you let me help keep this packages functional, it will be helpful for all users.

The pull request won't solve the fundamental problem. I can see you are quite slow on your github page as well! OTOH if you accepted a co-maintainer here, this would result in near immediate fixes. Either way, the choice is yours.

Thank you for the fix and update!

The opencv5 patch also have just been merged upstream

why is the package using "RelWithDebInfo" instead of "None" or "Release" build type?

asyync1024, I don't remember why I used RelWithDebInfo 3 years ago, now is None again

Just a note: this package appears to track stable upstream releases, while the newly released upstream version is still in beta, so the out-of-date flag is probably not applicable here.

I spent a few minutes checking why the package was flagged before realizing that the new release is still a beta version, so I thought I'd mention it here.

@gerliczkowalczuk the flag message literally says "New beta version"

v3.22.0 (2025/12) have been the first stable version since v3.16 (2020/07) all the release in between are marked as 'pre-release'

I was pondering if updating to that or not, in the end yes because the opencv5 patch doesn't apply to v3.22.1

Would be nice to add a license to the package (pkgctl license setup), see https://gitlab.archlinux.org/archlinux/rfcs/-/blob/master/rfcs/0040-license-package-sources.md?ref_type=heads#aur

@C0rn3j nothing against, I'll look into it, likely I'll do this alphabetically for my pkgbuilds since I have other revisions in course (cmake style and options, depends listing and -git pkgver() function)

Rhinoceros I'm fine thanks, pull-rquests/patches are welcome here for starting https://github.com/FabioLolix/PKGBUILD-AUR_fix

Hello!

I wanted to ask why is the package using "RelWithDebInfo" instead of "None" or "Release" build type? Is this requested by upstream or is there any specific reason for this?

I have some other package improvements also coming up soon, not today I think, but tomorrow for sure.

Thanks!

FWIW if you want to build with all features, you can install nomacs-git with the patch in the comments there.

OpenCV 5.0 dropped the deprecated C-API headers (imgproc_c.h), which causes compilation to fail with fatal error: opencv2/imgproc/imgproc_c.h: No such file or directory. Until upstream updates the source code to support OpenCV 5.0, you can successfully build nomacs as a standard image viewer by disabling the OpenCV, RAW, TIFF, and plugin modules in the build() function using the following patch:

--- PKGBUILD.orig
+++ PKGBUILD
@@ -38,6 +38,10 @@
 build() {
   cd nomacs
   cmake -B build -S ImageLounge -Wno-dev \
+    -DENABLE_OPENCV=OFF \
+    -DENABLE_RAW=OFF \
+    -DENABLE_TIFF=OFF \
+    -DENABLE_PLUGINS=OFF \
     -DCMAKE_BUILD_TYPE=RelWithDebInfo \
     -DCMAKE_INSTALL_PREFIX=/usr \
     -DQT_VERSION_MAJOR=6 \

Upstream has a pending fix: https://github.com/nomacs/nomacs/pull/1622/commits/c779d64c66e0d5f1581bdea7bc6ebd7fc6a1e374

I'm getting same error as @riddle00 applying the fix gives me a working build