Search Criteria
Package Details: lib32-libheif 1.19.5-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/lib32-libheif.git (read-only, click to copy) |
---|---|
Package Base: | lib32-libheif |
Description: | HEIF file format decoder and encoder (32-bit) |
Upstream URL: | https://github.com/strukturag/libheif |
Licenses: | GPL3 |
Provides: | libheif.so |
Submitter: | rodrigo21 |
Maintainer: | sl1pkn07 |
Last Packager: | sl1pkn07 |
Votes: | 5 |
Popularity: | 0.000001 |
First Submitted: | 2018-09-03 23:49 (UTC) |
Last Updated: | 2025-01-18 12:57 (UTC) |
Dependencies (26)
- lib32-gcc-libs (lib32-gcc-libs-gitAUR, lib32-gccrs-libs-gitAUR, lib32-gcc-libs-snapshotAUR)
- lib32-gdk-pixbuf2
- lib32-glibc (lib32-glibc-gitAUR, lib32-glibc-linux4AUR, lib32-glibc-eacAUR, lib32-glibc-eac-binAUR)
- lib32-libwebp
- libgdk_pixbuf-2.0.so (gdk-pixbuf2, lib32-gdk-pixbuf2)
- libglib-2.0.so (glib2-gitAUR, glib2-selinuxAUR, glib2-patched-thumbnailerAUR, glib2, lib32-glib2)
- libgobject-2.0.so (glib2-gitAUR, glib2-selinuxAUR, glib2-patched-thumbnailerAUR, glib2, lib32-glib2)
- libheif (libheif-gitAUR, libheif-highmemAUR)
- libsharpyuv.so (lib32-libwebp, libwebp)
- cmake (cmake-gitAUR) (make)
- lib32-aomAUR (make)
- lib32-libdav1dAUR (make)
- lib32-libde265AUR (make)
- lib32-libjpeg-turbo (lib32-mozjpeg-gitAUR) (make)
- lib32-libpng (make)
- lib32-rav1eAUR (make)
- lib32-svt-av1AUR (make)
- lib32-x265AUR (make)
- lib32-aomAUR (optional) – AOM plugin
- lib32-libdav1dAUR (optional) – DAV1D encoder
- Show 6 more dependencies...
Latest Comments
1 2 3 Next › Last »
vitaliikuzhdin commented on 2025-01-21 19:59 (UTC) (edited on 2025-01-21 20:00 (UTC) by vitaliikuzhdin)
Even clean-building using
yay
doesn't solve the error. This is not an issue specific to me. Even if it were only for me, I am still a user, and it is not that hard to bump thepkgrel
. There is absolutely no reason to treat all warnings as errors unless during development. Neither is there a reason to keep it this way until the next release, since not bumping thepkgrel
means no update.You are correct; I was only giving an example regarding the headers. However, the binaries still need to be removed, not renamed. There is no reason to keep them. No package will ever depend on them, as only the libraries are required.
This point still stands. Please enable the same features as the 'official'
libheif
package. It does make a difference:sl1pkn07 commented on 2025-01-18 14:03 (UTC) (edited on 2025-01-18 14:18 (UTC) by sl1pkn07)
is a minor change only affected to you, so not need bump the pkgrel
the install includes only affect to packages include own specific architecture headers, like lib32-libtiff. i think this package is not the case
the binaries is already converted in the package() step
greetings
vitaliikuzhdin commented on 2025-01-18 13:58 (UTC)
@sl1pkn07, you need to also increase the
pkgrel
and regenerate the.SRCINFO
for users to notice the changes.On a side note, I wonder if there's a need to deviate so much from the original
libheif
in terms of included features, and to install the binaries with the-32
postfix at all. Usually, only the 32-bit libraries are installed to/usr/lib32
, and in very rare cases, architecture-specific headers would also be installed.sl1pkn07 commented on 2025-01-18 12:57 (UTC)
done (?)
vitaliikuzhdin commented on 2025-01-13 11:41 (UTC) (edited on 2025-01-13 11:41 (UTC) by vitaliikuzhdin)
@sl1pkn07, after rebuilding all dependencies and retrying the build in a clean chroot, I was able to compile the package successfully. It doesn't seem like the chroot
makepkg.conf
flags are the reason for the issue:I'm guessing some package installed on my host system triggers
cmake
to setCMAKE_COMPILE_WARNING_AS_ERROR=ON
, which is why I'm getting the error. Adding-DCMAKE_COMPILE_WARNING_AS_ERROR=OFF
to thebuild()
function resolved the issue for me.vitaliikuzhdin commented on 2025-01-13 07:49 (UTC) (edited on 2025-01-13 11:29 (UTC) by vitaliikuzhdin)
@sl1pkn07, the error I posted below occurred after I manually updated the pkgver, and it still persists for me. Here is some additional information you might find helpful:
sl1pkn07 commented on 2025-01-13 07:09 (UTC) (edited on 2025-01-18 12:55 (UTC) by sl1pkn07)
nothing to do(?)
vitaliikuzhdin commented on 2025-01-10 19:06 (UTC)
1 2 3 Next › Last »