Package Details: lib32-shaderc 2020.4-1

Git Clone URL: (read-only, click to copy)
Package Base: lib32-shaderc
Description: Collection of tools, libraries and tests for shader compilation (32bit)
Upstream URL:
Licenses: Apache
Conflicts: lib32-shaderc-git
Submitter: oxalin
Maintainer: oxalin
Last Packager: oxalin
Votes: 2
Popularity: 0.43
First Submitted: 2019-08-15 16:26
Last Updated: 2020-12-12 19:54

Latest Comments

1 2 3 Next › Last »

oxalin commented on 2020-12-12 19:38

Update is on its way. It seems I missed a few updates, I'll have a look at my feeds to be sure I don't miss anymore.

sgt-hartman commented on 2020-12-11 16:48

I have the same issue as @Nocifer. Beeing not a AUR packaging guru, how do i update to "2020.3" ?

Nocifer commented on 2020-12-08 10:10

Yes, this was obviously an upstream bug, and then like DDoSolitary says I too noticed that this package is on 2020.0 and not the latest 2020.3, so updating to that fixed the issue. So, @oxalin, please update this package :)

DDoSolitary commented on 2020-12-08 09:17

Got the same error as @Nocifer. It seems that updating to 2020.3 fixes this.

Nocifer commented on 2020-12-07 20:39

I'm trying to build this package due to the lib32-gst-plugins-bad update today and I'm getting the following error:

[16/29] Building CXX object libshaderc_util/CMakeFiles/shaderc_util.dir/src/
FAILED: libshaderc_util/CMakeFiles/shaderc_util.dir/src/ 
/usr/lib/ccache/bin/g++  -m32 -DENABLE_HLSL -I/tmp/makepkg/lib32-shaderc/src/shaderc-2020.0/libshaderc_util/include -D_FORTIFY_SOURCE=2 -march=native -O2 -pipe -fno-plt -D_FORTIFY_SOURCE=2 -I/usr/include/glslang -Wimplicit-fallthrough -O3 -DNDEBUG -Wextra-semi -Wall -Werror -fvisibility=hidden -fPIC -std=c++11 -std=gnu++11 -MD -MT libshaderc_util/CMakeFiles/shaderc_util.dir/src/ -MF libshaderc_util/CMakeFiles/shaderc_util.dir/src/ -o libshaderc_util/CMakeFiles/shaderc_util.dir/src/ -c /tmp/makepkg/lib32-shaderc/src/shaderc-2020.0/libshaderc_util/src/
/tmp/makepkg/lib32-shaderc/src/shaderc-2020.0/libshaderc_util/src/ error: cannot convert ‘<brace-enclosed initializer list>’ to ‘int’ in initialization
  142 |     }};
      |      ^
[22/29] Building CXX object glslc/CMakeFiles/glslc.dir/src/
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().

Could some kind and more knowledgable soul share their wisdom with me? Could this be an issue with my custom CXXFLAGS in makepkg.conf (basically -march=native)?

oxalin commented on 2020-05-04 05:50

@eschwartz: take a deep breath, no need to call me a liar. I honestly do this (creating and maintaining packages, and sometimes having to interact with other package maintainers) to the best of my knowledges and of my free time. I think we are all working in the same direction, so cool off. Sometime, I miss something and I fix it as fast as I can do. I updated the package hastily in between to activities with my child and, after updating and seeing no error, I thought everything had went just fine.

You were right though, something went wrong while updating the package and was not displayed properly. I use Octopi with pacaur and something in-between may not have followed. When I rebooted a bit earlier, I saw that the package was still at 2019.0. So I reverted the change to "${pkgdir}": As @DDoSolitary pointed out, this variable is an abolute path. And as you stated, removing the quotes shouldn't have happened (which was done inadvertently when modifying the path).

While your suggestion of removing the "f" parameter is right, I have not applied it for now. I'll include it in the next update. I'll have to remove the "share" from the folder list at the same time otherwise the rm command will fail (there is no "share" folder).

To everyone: let me know you encounter anything with the updated version (I double-checked that the package was really installed this time).

Samega7Cattac commented on 2020-05-03 13:48

I have the same issue as @Nocifer conflicts with shaderc

thaewrapt commented on 2020-05-03 12:45

@oxalin Sorry, my bad, thought the upstream (64-bit) version update caused the issue.

Nocifer commented on 2020-05-03 08:58

People, please, we're not competing here, we're trying to make this work. In any case, as @DDoSolitary and @eschwartz have already pointed out, this line in the PKGBUILD

rm -rf ${_pkgbasename}-${pkgver}/${pkgdir}/usr/{include,share,bin}

should become

rm -r ${pkgdir}/usr/{include,bin}

because $pkgdir is an absolute path that already points to pkg/$pkgname, so there's no need for that ${_pkgbasename}-${pkgver}.

Further, there is no $pkgdir/usr/share folder to be deleted, something that would have been noticed earlier if it wasn't for that -f flag which, as @eschwartz already pointed out, should not really be used with rm because it can hide errors such as this. A better way would be to remove share from {include,share,bin} and then simply get rid of the -f flag.

Also, yeah, it wouldn't hurt to keep shell variables wrapped in quotes to guard against the corner case of having spaces in the path name.

DDoSolitary commented on 2020-05-03 03:06

Oops I missed that "too" in your comment. Sorry.