Package Details: libjxl-git 0.6.1.r590.g7f5a2cd0-1

Git Clone URL: https://aur.archlinux.org/libjxl-git.git (read-only, click to copy)
Package Base: libjxl-git
Description: JPEG XL image format reference implementation (git version)
Upstream URL: https://jpeg.org/jpegxl/
Keywords: jpeg-xl
Licenses: BSD
Conflicts: libjpeg-xl-git, libjxl
Provides: libjpeg-xl-git, libjxl, libjxl.so, libjxl_threads.so
Replaces: libjpeg-xl-git
Submitter: dbermond
Maintainer: dbermond
Last Packager: dbermond
Votes: 9
Popularity: 0.61
First Submitted: 2021-06-02 18:30 (UTC)
Last Updated: 2022-04-25 18:38 (UTC)

Required by (27)

Sources (11)

Latest Comments

dbermond commented on 2022-04-25 17:52 (UTC)

@JDAturbo That's because upstream does not fix their git repository to give the correct version with the git describe command. I always left this way in hope they can someday properly update this, but it's really taking too long.

JDAturbo commented on 2022-04-25 17:47 (UTC)

I believe the pkgver is wrong. The version on main branch is 0.7.0: https://github.com/libjxl/libjxl/blob/main/lib/CMakeLists.txt

andrius4669 commented on 2022-01-10 20:16 (UTC)

https://github.com/google/highway/issues/497 has been fixed and now it instead fails on https://github.com/libjxl/libjxl/issues/1080

andrius4669 commented on 2022-01-09 21:59 (UTC)

that wouldn't be an issue if -DJPEGXL_FORCE_SYSTEM_HWY:BOOL='true' wasn't set. why is that submodule, at known working commit, is even being cloned if broken one is being depended upon instead?

anyway I've reported https://github.com/google/highway/issues/497, we'll see how that goes. but consider taking off -DJPEGXL_FORCE_SYSTEM_HWY:BOOL='true', while i kinda know reasons not to, it's got bigger chances to break stuff with untested hwy commits.

dbermond commented on 2022-01-06 18:48 (UTC)

@yaron This is an upstream issue, probably on highway. It looks like a commit that was made today on upstream highway broke the libjxl build.

yaron commented on 2022-01-06 14:28 (UTC)

@dbermond there seem to be an error while compiling this version:

In file included from /usr/include/hwy/tests/test_util-inl.h:22:
/usr/include/hwy/tests/test_util.h:26:10: fatal error: 'hwy/tests/include_farm_sve.h' file not found
#include "hwy/tests/include_farm_sve.h"
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

dbermond commented on 2022-01-03 02:09 (UTC)

@Yatha package updated to match the latest upstream changes.

Yatha commented on 2022-01-02 19:53 (UTC)

This package required "gflags" package. Otherwise " libgflags not found " error occured

politas commented on 2021-12-30 08:36 (UTC)

Manjaro folks having issues should replace this package with the Official Repositories libjxl

dbermond commented on 2021-12-29 11:34 (UTC)

@Vaporeon Changed the highway dependency for the time being. 'libjxl_jni.so' is still present. If this file is not being built for you, probably the build system is not detecting your 'java-environment' (jdk).

Vaporeon commented on 2021-12-18 04:58 (UTC)

build/tools/libjxl_jni.so, a file manually installed by the PKGBUILD does not exist anymore either.

Vaporeon commented on 2021-12-18 04:47 (UTC)

This fails to build without highway version 0.15.0 or higher.

Armag67 commented on 2021-10-23 15:23 (UTC) (edited on 2021-10-23 15:25 (UTC) by Armag67)

Hello,

It was upstream... Now it builds fine with the ad96c3d commit and the git clone... way.

https://github.com/libjxl/libjxl/issues/765

https://github.com/libjxl/libjxl/commit/ad96c3d84f8b3b79425fecff4ef800621c1fe3c5

dbermond commented on 2021-10-22 20:01 (UTC)

@andrius4669 I have no problems in building the package. Working fine for me.

andrius4669 commented on 2021-10-22 20:00 (UTC)

it's failing here too but it's more of upstream issue tbh, report test failures to libjxl's github

dbermond commented on 2021-10-22 19:55 (UTC)

@Armag67 Sorry, but Manjaro is not supported. The package is building fine on Arch Linux. Please seek help on your distribution support channels.

Armag67 commented on 2021-10-22 19:20 (UTC) (edited on 2021-10-22 19:47 (UTC) by Armag67)

Hello,

With:

git clone https://aur.archlinux.org/libjxl-git.git
cd libjxl-git
env LC_ALL=C makepkg -si

on Manjaro stable Xfce, I get the error:

...
The following tests did not run:
    944 - GaussBlurTest.SlowTestDirac1D (Disabled)

The following tests FAILED:
    1140 - conformance_tooling_test (Failed)
Errors while running CTest
Output from these tests are in: /home/h2/Installs/new-git/libjxl-git/src/build/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.
make: *** [Makefile:136: test] Error 8
make: Leaving directory '/home/h2/Installs/new-git/libjxl-git/src/build'
==> ERROR: A failure occurred in check().
    Aborting...

Same result with pamac.

opale95 commented on 2021-10-08 18:24 (UTC)

@dbermond Thank you, installing jdk-openjdk did the trick.

dbermond commented on 2021-10-08 16:47 (UTC)

@opale95 Please use english language when posting. The package is building fine. From what I could understand from your log, it looks like that the jni bindings are not being built. If this is the case, you need to make sure that you have a compatible jdk installed and that it is enabled at archlinux-java.

opale95 commented on 2021-10-08 11:30 (UTC) (edited on 2021-10-08 11:31 (UTC) by opale95)

I get an error at the install part:

-- Installing: /home/antoine/ssd/git/libjxl-git/pkg/libjxl-git/usr/bin/djxl
make : on quitte le répertoire « /home/antoine/ssd/git/libjxl-git/src/build »
install: impossible d'évaluer 'build/tools/libjxl_jni.so': Aucun fichier ou dossier de ce type
==> ERREUR : Une erreur s’est produite dans package_libjxl-git().
    Abandon…

trougnouf commented on 2021-10-07 16:49 (UTC)

Sorry I missed it, thank you :)

dbermond commented on 2021-10-07 16:29 (UTC)

@trougnouf The package already provides 'libjxl'. See 'Provides' at this AUR web page or 'provides' on the PKGBUILD file.

trougnouf commented on 2021-10-07 12:50 (UTC) (edited on 2021-10-07 12:51 (UTC) by trougnouf)

Can you make this package provide "libjxl"? Otherwise it won't detect the conflict with the non-git version.

dbermond commented on 2021-09-04 14:21 (UTC)

@andrius4669 Thanks. This is just a warning. No need to hurry for changing it, as it does not affect anything.

andrius4669 commented on 2021-08-28 12:33 (UTC)

CMake Warning:
  Manually-specified variables were not used by the project:

    JPEGXL_ENABLE_GIMP_SAVING

doesn't seem like this option exists anymore

dbermond commented on 2021-08-03 15:31 (UTC)

@ugjdgdto I was just waiting for the pull request to be merged to implement it here. Package updated to match the latest upstream changes.

ugjdgdto commented on 2021-08-03 14:31 (UTC)

Some submodules are no longer needed after this commit, I think?

dbermond commented on 2021-06-06 01:39 (UTC)

@silverhikari That's because highway on-tree dependency was updated to 0.12.2 by upstream. This version installs headers in different directories compared to 0.12.0. I've pushed an update, and now the package is using highway from system again. Building fine now.

silverhikari commented on 2021-06-05 23:10 (UTC)

i get a rm error when compiling, so here is what is happening rm: cannot remove '/var/tmp/pamac-build-silver/libjxl-git/pkg/libjxl-git/usr/include/contrib': No such file or directory

dbermond commented on 2021-06-03 15:36 (UTC)

@andrius4669 Not needed. Maintainer of qt-jpegxl-image-plugin-git needs to update the package dependencies, as it currently needs the git master branch of libjxl, and does not build with the latest stable libjxl 0.3.7 release. So it should depend on libjxl-git/libjpeg-xl-git and not on libjxl/libjpeg-xl, at least for now.

andrius4669 commented on 2021-06-03 15:17 (UTC)

should probably provide libjpeg-xl too, as I can't install qt-jpegxl-image-plugin-git now.

dbermond commented on 2021-04-23 12:44 (UTC)

@andrius4669 I added asciidoc on the libjpeg-xl 0.3.7 update but forgot to add it here. Package updated, thanks.

andrius4669 commented on 2021-04-22 08:06 (UTC)

CMake Warning at CMakeLists.txt:300 (message):
  asciidoc was not found, the man pages will not be installed.

dbermond commented on 2021-03-02 01:32 (UTC)

@andrea.denisse just run makepkg and it will automatically update pkgver to the latest upstream commit. No intervention is needed here currently.

denisse commented on 2021-03-01 17:02 (UTC)

Hello, the current version of this package contains multiple vulnerabilities. Affected versions are v0.3.1 and earlier. Please update to the latest version.

nathanielcwm commented on 2021-02-06 13:56 (UTC)

Oh my bad didn't notice it was a split package.

dbermond commented on 2021-02-06 12:31 (UTC)

@nathanielcwm It's already there. Please look carefully.

nathanielcwm commented on 2021-02-06 08:07 (UTC)

Since there's a libjpeg-xl package now should this provide libjpeg-xl?

dbermond commented on 2020-12-29 23:45 (UTC)

@ncmprhnsbl Arch derivatives are not supported. You need to seek help in the support channels of your distribution. Please don't report errors when not running Arch Linux.

ncmprhnsbl commented on 2020-12-29 23:41 (UTC) (edited on 2020-12-29 23:42 (UTC) by ncmprhnsbl)

"Are you on Arch Linux or an Arch derivative?" it is indeed a derivative :D.. my apologies for the bother <smacks self across back of head>

dbermond commented on 2020-12-29 15:04 (UTC)

@ncmprhnsbl Are you on Arch Linux or an Arch derivative? I have no problems building the package, neither with makepkg or with devtools. No environment variable is needed for building, just plain makepkg.

ncmprhnsbl commented on 2020-12-29 01:48 (UTC)

but no, still getting the same error with plain makepkg .. am i missing some env variable?

ncmprhnsbl commented on 2020-12-21 02:30 (UTC)

ah,ok.. i suspected that might be the case, thanks

dbermond commented on 2020-12-19 15:01 (UTC)

@ncmprhnsbl Package is building fine. AUR helpers are not supported. Use makepkg.

ncmprhnsbl commented on 2020-12-19 12:08 (UTC) (edited on 2020-12-19 12:09 (UTC) by ncmprhnsbl)

using trizen: failed because (some)libs installed in /usr/lib64 and rm "${pkgdir}/usr/lib/"{libhwy.a,pkgconfig/libhwy{,-test}.pc} fails. fixed by adding: -DCMAKE_INSTALL_LIBDIR:PATH='/usr/lib'

dbermond commented on 2020-12-17 14:39 (UTC)

@andrius4669 Package updated to match the latest upstream changes.

andrius4669 commented on 2020-12-17 05:53 (UTC)

patching file third_party/highway/CMakeLists.txt
Hunk #1 FAILED at 90.
1 out of 1 hunk FAILED -- saving rejects to file third_party/highway/CMakeLists.txt.rej
==> ERROR: A failure occurred in prepare().

dbermond commented on 2020-11-16 19:19 (UTC)

@andrius4669 Package updated to match the latest upstream changes.

andrius4669 commented on 2020-11-16 18:17 (UTC)

Git submodule list should be updated (current still works tho).

dbermond commented on 2020-10-29 19:51 (UTC)

@andrius4669 Package updated to match the latest upstream changes.

andrius4669 commented on 2020-10-29 18:08 (UTC)

patch no longer applies

dbermond commented on 2020-10-13 17:59 (UTC)

@andrius4669 Package updated to match the latest upstream changes.

andrius4669 commented on 2020-10-13 15:21 (UTC)

...
-- Installing: /home/anon/.cache/yay/libjpeg-xl-git/pkg/libjpeg-xl-git/usr/bin/xyb_range
make: Leaving directory '/home/anon/.cache/yay/libjpeg-xl-git/src/build'
rm: cannot remove '/home/anon/.cache/yay/libjpeg-xl-git/pkg/libjpeg-xl-git/usr/bin/cbrunsli': No such file or directory
==> ERROR: A failure occurred in package().
    Aborting...

dbermond commented on 2020-07-28 01:38 (UTC)

@hotaru Patches updated to match to latest upstream changes. Package is now building fine.

hotaru commented on 2020-07-28 01:14 (UTC)

looks like the remove-werror patch is no longer needed:

patching file CMakeLists.txt
Reversed (or previously applied) patch detected!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file CMakeLists.txt.rej
==> ERROR: A failure occurred in prepare().
    Aborting...
error making: libjpeg-xl-git

dbermond commented on 2020-05-06 22:31 (UTC)

@andrius4669 It's better to use all submodules that are explicitly declared by upstream. Package is now fixed.

andrius4669 commented on 2020-05-06 20:58 (UTC)

Well, actually, mingw-std-threads is not actually being used or even referenced at all if MINGW is not defined. So fix what is not exactly cleanest but works for me well is:

diff --git a/PKGBUILD b/PKGBUILD
index 0d68e71..9495c4f 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -25,7 +25,6 @@ source=('git+https://gitlab.com/wg1/jpeg-xl.git'
         'git+https://github.com/google/brunsli.git'
         'git+https://github.com/webmproject/sjpeg.git'
         'git+https://skia.googlesource.com/skcms.git'
-        'git+https://github.com/meganz/mingw-std-threads.git'
         '010-libjpeg-xl-git-remove-werror.patch'
         '020-libjpeg-xl-git-fix-headers-install-path.patch'
         '030-libjpeg-xl-git-fix-gdk-pixbuf-install-path.patch'
@@ -38,7 +37,6 @@ sha256sums=('SKIP'
             'SKIP'
             'SKIP'
             'SKIP'
-            'SKIP'
             '0f538f216f7fca8611efd5d638b521eb2c3b1fb716720afb371f034b3165c90c'
             'c2ea669a2afd94b6582921c893e0b382cd632c12d0a9c2358f955fd6cccffdc3'
             '1666790b92321fbf5859abe50c7355c91b0eddd7381529f35f052e71913c3bf0'
@@ -46,6 +44,7 @@ sha256sums=('SKIP'

 prepare() {
     git -C jpeg-xl submodule init
+    git -C jpeg-xl submodule deinit --force third_party/mingw-std-threads
     git -C jpeg-xl config --local submodule.third_party/brotli.url "${srcdir}/brotli"
     git -C jpeg-xl config --local submodule.third_party/lodepng.url "${srcdir}/lodepng"
     git -C jpeg-xl config --local submodule.third_party/lcms.url "${srcdir}/Little-CMS"
@@ -53,7 +52,6 @@ prepare() {
     git -C jpeg-xl config --local submodule.third_party/brunsli.url "${srcdir}/brunsli"
     git -C jpeg-xl config --local submodule.third_party/sjpeg.url "${srcdir}/sjpeg"
     git -C jpeg-xl config --local submodule.third_party/skcms.url "${srcdir}/skcms"
-    git -C jpeg-xl config --local submodule.third_party/mingw-std-threads.url "${srcdir}/mingw-std-threads"
     git -C jpeg-xl submodule update
     patch -d jpeg-xl -Np1 -i "${srcdir}/010-libjpeg-xl-git-remove-werror.patch"
     patch -d jpeg-xl -Np1 -i "${srcdir}/020-libjpeg-xl-git-fix-headers-install-path.patch"

dbermond commented on 2020-05-06 20:47 (UTC)

I've identified what's happening. It seems that the commit referenced by submodule mingw-std-threads was moved. Maybe it was on the git master branch but now it's not on master branch anymore and not on any branch currently. I'll push a fix.

My git sources on $SRCDEST were still pointing to that old state, so I could not reproduce the issue.

andrius4669 commented on 2020-05-06 20:16 (UTC)

Non-makepkg based git submodule update:

$ git submodule update
Cloning into '/home/anon/jpeg-xl/third_party/brotli'...
Cloning into '/home/anon/jpeg-xl/third_party/brunsli'...
Cloning into '/home/anon/jpeg-xl/third_party/googletest'...
Cloning into '/home/anon/jpeg-xl/third_party/lcms'...
Cloning into '/home/anon/jpeg-xl/third_party/lodepng'...
Cloning into '/home/anon/jpeg-xl/third_party/mingw-std-threads'...
Cloning into '/home/anon/jpeg-xl/third_party/sjpeg'...
Cloning into '/home/anon/jpeg-xl/third_party/skcms'...
Submodule path 'third_party/brotli': checked out '35ef5c554d888bef217d449346067de05e269b30'
Submodule path 'third_party/brunsli': checked out 'ede60d8bae3c10c56e64a0001f7b354c5a086ca3'
Submodule path 'third_party/googletest': checked out '0ea2d8f8fa1601abb9ce713b7414e7b86f90bc61'
Submodule path 'third_party/lcms': checked out '65c63bf549d78253c14b30b3d62cb668bbbe612c'
Submodule path 'third_party/lodepng': checked out '48e5364ef48ec2408f44c727657ac1b6703185f8'
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 2 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), 2.00 KiB | 1023.00 KiB/s, done.
From https://github.com/meganz/mingw-std-threads
 * branch            baca8abcfa9576d1682e049c46c4805230aeda5b -> FETCH_HEAD
Submodule path 'third_party/mingw-std-threads': checked out 'baca8abcfa9576d1682e049c46c4805230aeda5b'
Submodule path 'third_party/sjpeg': checked out '868ab558fad70fcbe8863ba4e85179eeb81cc840'
Submodule path 'third_party/skcms': checked out '64374756e03700d649f897dbd98c95e78c30c7da'

There is clearly something different about mingw-std-threads repo compared to others.. but I have no idea how to get it working yet.

andrius4669 commented on 2020-05-06 19:57 (UTC)

can confirm. same issue with both pikaur and pure makepkg

RubenKelevra commented on 2020-05-06 13:42 (UTC)

@dbermond

I already did choose the cleanBuild option on yay.

I also tried to download the files from aur and use makepkg, which also fails.

Sure that your package just builds fine because you have something cached? Because I cannot build it on multiple machines...

dbermond commented on 2020-05-01 18:18 (UTC)

@RubenKelevra Package is building fine. I have no problems with the git submodule mingw-std-threads.

Try to delete any possible old sources of mingw-std-threads from your $SRCDEST directory (and/or from the directory where PKGBUILD is placed), and also make sure that you're using plain makepkg with the cleanbuild option.

RubenKelevra commented on 2020-04-30 15:11 (UTC)

@dbermond

that's great news,

but sadly the package won't build anymore :(

==> Starting prepare()...
Submodule 'third_party/brotli' (https://github.com/google/brotli) registered for path 'third_party/brotli'
Submodule 'third_party/brunsli' (https://github.com/google/brunsli.git) registered for path 'third_party/brunsli'
Submodule 'third_party/googletest' (https://github.com/google/googletest) registered for path 'third_party/googletest'
Submodule 'third_party/lcms' (https://github.com/mm2/Little-CMS) registered for path 'third_party/lcms'
Submodule 'third_party/lodepng' (https://github.com/lvandeve/lodepng) registered for path 'third_party/lodepng'
Submodule 'third_party/mingw-std-threads' (https://github.com/meganz/mingw-std-threads) registered for path 'third_party/mingw-std-threads'
Submodule 'third_party/sjpeg' (https://github.com/webmproject/sjpeg.git) registered for path 'third_party/sjpeg'
Submodule 'third_party/skcms' (https://skia.googlesource.com/skcms) registered for path 'third_party/skcms'
Cloning into '/home/ruben/.cache/yay/libjpeg-xl-git/src/jpeg-xl/third_party/brotli'...
done.
Cloning into '/home/ruben/.cache/yay/libjpeg-xl-git/src/jpeg-xl/third_party/brunsli'...
done.
Cloning into '/home/ruben/.cache/yay/libjpeg-xl-git/src/jpeg-xl/third_party/googletest'...
done.
Cloning into '/home/ruben/.cache/yay/libjpeg-xl-git/src/jpeg-xl/third_party/lcms'...
done.
Cloning into '/home/ruben/.cache/yay/libjpeg-xl-git/src/jpeg-xl/third_party/lodepng'...
done.
Cloning into '/home/ruben/.cache/yay/libjpeg-xl-git/src/jpeg-xl/third_party/mingw-std-threads'...
done.
Cloning into '/home/ruben/.cache/yay/libjpeg-xl-git/src/jpeg-xl/third_party/sjpeg'...
done.
Cloning into '/home/ruben/.cache/yay/libjpeg-xl-git/src/jpeg-xl/third_party/skcms'...
done.
Submodule path 'third_party/brotli': checked out '35ef5c554d888bef217d449346067de05e269b30'
Submodule path 'third_party/brunsli': checked out 'ede60d8bae3c10c56e64a0001f7b354c5a086ca3'
Submodule path 'third_party/googletest': checked out '0ea2d8f8fa1601abb9ce713b7414e7b86f90bc61'
Submodule path 'third_party/lcms': checked out '65c63bf549d78253c14b30b3d62cb668bbbe612c'
Submodule path 'third_party/lodepng': checked out '48e5364ef48ec2408f44c727657ac1b6703185f8'
fatal: git upload-pack: not our ref baca8abcfa9576d1682e049c46c4805230aeda5b
fatal: remote error: upload-pack: not our ref baca8abcfa9576d1682e049c46c4805230aeda5b
Fetched in submodule path 'third_party/mingw-std-threads', but it did not contain baca8abcfa9576d1682e049c46c4805230aeda5b. Direct fetching of that commit failed.
==> ERROR: A failure occurred in prepare().
    Aborting...
Error making: libjpeg-xl-git

dbermond commented on 2020-04-22 01:38 (UTC)

Quoting from upstream Readme: "JPEG XL no longer requires a particular CPU. The software chooses and uses the best available instruction set for the current CPU".

So there is no need to worry about sse4.1 and avx2 instruction sets anymore.

dbermond commented on 2020-04-22 01:38 (UTC)

@RubenKelevra Fixed. Working fine now.

RubenKelevra commented on 2020-04-21 00:54 (UTC)

It isn't building anymore:


==> Starting prepare()...
Submodule 'third_party/brotli' (https://github.com/google/brotli) registered for path 'third_party/brotli'
Submodule 'third_party/brunsli' (https://github.com/google/brunsli.git) registered for path 'third_party/brunsli'
Submodule 'third_party/googletest' (https://github.com/google/googletest) registered for path 'third_party/googletest'
Submodule 'third_party/lcms' (https://github.com/mm2/Little-CMS) registered for path 'third_party/lcms'
Submodule 'third_party/lodepng' (https://github.com/lvandeve/lodepng) registered for path 'third_party/lodepng'
Submodule 'third_party/mingw-std-threads' (https://github.com/meganz/mingw-std-threads) registered for path 'third_party/mingw-std-threads'
Submodule 'third_party/sjpeg' (https://github.com/webmproject/sjpeg.git) registered for path 'third_party/sjpeg'
Submodule 'third_party/skcms' (https://skia.googlesource.com/skcms) registered for path 'third_party/skcms'
Cloning into '/home/ruben/.cache/yay/libjpeg-xl-git/src/jpeg-xl/third_party/brotli'...
done.
Cloning into '/home/ruben/.cache/yay/libjpeg-xl-git/src/jpeg-xl/third_party/brunsli'...
done.
Cloning into '/home/ruben/.cache/yay/libjpeg-xl-git/src/jpeg-xl/third_party/googletest'...
done.
Cloning into '/home/ruben/.cache/yay/libjpeg-xl-git/src/jpeg-xl/third_party/lcms'...
done.
Cloning into '/home/ruben/.cache/yay/libjpeg-xl-git/src/jpeg-xl/third_party/lodepng'...
done.
Cloning into '/home/ruben/.cache/yay/libjpeg-xl-git/src/jpeg-xl/third_party/mingw-std-threads'...
Cloning into '/home/ruben/.cache/yay/libjpeg-xl-git/src/jpeg-xl/third_party/sjpeg'...
done.
Cloning into '/home/ruben/.cache/yay/libjpeg-xl-git/src/jpeg-xl/third_party/skcms'...
done.
Submodule path 'third_party/brotli': checked out '35ef5c554d888bef217d449346067de05e269b30'
Submodule path 'third_party/brunsli': checked out 'ede60d8bae3c10c56e64a0001f7b354c5a086ca3'
Submodule path 'third_party/googletest': checked out '0ea2d8f8fa1601abb9ce713b7414e7b86f90bc61'
Submodule path 'third_party/lcms': checked out '65c63bf549d78253c14b30b3d62cb668bbbe612c'
Submodule path 'third_party/lodepng': checked out '48e5364ef48ec2408f44c727657ac1b6703185f8'
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 2 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), 2.00 KiB | 2.00 MiB/s, done.
From https://github.com/meganz/mingw-std-threads
 * branch            baca8abcfa9576d1682e049c46c4805230aeda5b -> FETCH_HEAD
Submodule path 'third_party/mingw-std-threads': checked out 'baca8abcfa9576d1682e049c46c4805230aeda5b'
Submodule path 'third_party/sjpeg': checked out '868ab558fad70fcbe8863ba4e85179eeb81cc840'
Submodule path 'third_party/skcms': checked out '64374756e03700d649f897dbd98c95e78c30c7da'
patching file CMakeLists.txt
Hunk #1 succeeded at 154 (offset -11 lines).
patching file jpegxl.cmake
Hunk #1 succeeded at 457 (offset 20 lines).
patching file plugins/gdk-pixbuf/CMakeLists.txt
Hunk #1 succeeded at 24 with fuzz 2.
patching file CMakeLists.txt
Hunk #1 FAILED at 136.
1 out of 1 hunk FAILED -- saving rejects to file CMakeLists.txt.rej
can't find file to patch at input line 21
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -Naurp a/third_party/highway/hwy/targets.h b/third_party/highway/hwy/targets.h
|--- a/third_party/highway/hwy/targets.h        2020-03-11 01:58:08.000000000 +0000
|+++ b/third_party/highway/hwy/targets.h        2020-03-11 02:00:17.338460487 +0000
--------------------------
File to patch: 

dbermond commented on 2020-03-12 16:40 (UTC)

@RubenKelevra Good to know. Thanks for participating.

dbermond commented on 2020-03-12 16:39 (UTC)

Important notice:

  • This package requires a cpu that supports the sse4.1 instruction set at minimum.

RubenKelevra commented on 2020-03-12 15:39 (UTC)

@dbermond I can confirm that it works now! Thanks! :)

dbermond commented on 2020-03-11 02:41 (UTC)

@RubenKelevra Should work now.

RubenKelevra commented on 2020-03-10 17:14 (UTC)

Damn, sorry. I meant the CPU with SSE4 but without AVX2 has trouble get this package compiled successfully.

The libjpeg-xl-git r3.g0709f3a-2 was successfully completed on this machine after turning the optimizations from x86_64/generic to native/native. Without it would complain that some functions which should be inlined are not compiled with SSE4.1 support.

dbermond commented on 2020-03-10 17:03 (UTC)

@RubenKelevra Yes, I think that a package with optimized instructions would be nice in this case. I may create one.

Upstream should allow compilation on older non-sse4 cpus and check for instruction support at runtime, but it looks like that it's not the case. Maybe you can request this to them. Since upstream explicitly states that it requires sse4, I take this with no surprise.

RubenKelevra commented on 2020-03-10 16:18 (UTC)

@dbermond

I'm not able to build libjpeg-xl-git r3.g0709f3a-3 on my machine without AVX2/SSE4:

CMake Error at /usr/share/cmake-3.16/Modules/GoogleTestAddTests.cmake:40 (message):
  Error running test executable.

    Path: '/home/ruben/.cache/yay/libjpeg-xl-git/src/build/tests/quantizer_test'
    Result: Illegal instruction
    Output:

RubenKelevra commented on 2020-03-03 13:14 (UTC)

Okay, the build scripts of software do very regularly exactly this. So I thought it would fit a prepare script as well.

In this case:

How about a copy of this package with avx2 enabled? :)

dbermond commented on 2020-03-03 01:50 (UTC)

@RubenKelevra I've fixed the avx2 patch, so that the package now builds when using the default generic architecture. Thanks for reporting this.

Still requires sse4 at runtime of course.

dbermond commented on 2020-03-03 01:28 (UTC)

@RubenKelevra There is no auto switch, as it should not be this way. Users wanting avx2 support should manually disable the corresponding patch on the PKGBUILD.

PKGBUILDs are not supposed to be like the way you suggested. There should not be exit calls based on hardware, and neither automatic patch file deletion.

RubenKelevra commented on 2020-03-02 20:58 (UTC)

You could just add something like this to your prepare script, to avoid even trying to compile the package with a CPU not able to handle sse4.

And to readd avx2 support dynamically if the CPU supports it.

if [ "$(cat /proc/cpuinfo | grep -E "^flags" | grep -e "sse4_2" | wc -l)" -eq 0 ]; then
    echo "this package requires SSE4 to work"
    exit 1
elif [  "$(cat /proc/cpuinfo | grep -E "^flags" | grep -e "avx2" | wc -l)" -gt 0 ];
    # avx2 detected, remove patch 
    rm '040-libjpeg-xl-git-disable-avx2-avx512.patch'
fi

RubenKelevra commented on 2020-03-02 20:47 (UTC) (edited on 2020-03-02 20:48 (UTC) by RubenKelevra)

Alright, I figured out what's going wrong on the second machine (which got AVX2).

The machine has the default arch settings for c/cpp compiler for the target set, which is just -march=x86_64 and -mtune=generic.

This package requires that -march is set to native and -mtune can be deleted.

This obviously makes more sense on package level, where you would need to overwrite the CFLAGS/CXXFLAGS accordingly.

RubenKelevra commented on 2020-03-02 19:35 (UTC)

@dbermond thanks!

SSE4 is extremely common in processors deployed in the field, but avx2 is not, since many SSE4 processors have still not reached their end of service life to be replaced by something new.

Is the switch dynamic? (Haven't looked at the pkgbuild) since avx2 capable processors should be able to use avx2, since it makes a huge difference.

dbermond commented on 2020-03-02 01:15 (UTC)

@RubenKelevra Thanks for appreciating this package. Regarding the errors, I cannot reproduce them. Package is building fine for me.

I've disabled avx2 support and it should now work in older cpus. Please note that upstream states that it needs the sse4 instruction set, so this will not run in a generic x86_64 cpu which lacks sse4.

RubenKelevra commented on 2020-02-26 19:55 (UTC)

I tried it on a different machine, which got an older processor. Looks like this processor isn't supported :/

https://pastebin.com/4UqWGh3B

Is there a chance that you add the ability to select at build time if the CPU can run AVX2 and patch the file according to documentation?

CPU requirements
When running on Intel/AMD CPUs the software currently requires AVX2 support
(introduced by Intel in 2013 and AMD in 2015). If not supported by the CPU or
VM, the software will print "CPU does not support all enabled targets =>
exiting". You can either run on a more recent CPU/VM, or instruct the software
to only use/require SSE4 by uncommenting the line near the bottom of
third_party/highway/hwy/target.h:
// #define HWY_DISABLE_AVX2

RubenKelevra commented on 2020-02-26 16:50 (UTC)

Thanks for this package!

Tried to compile it and run into an error:

https://pastebin.com/LY0Qw4KM