Package Details: python-dlib-cuda 19.24.6-1

Git Clone URL: https://aur.archlinux.org/python-dlib.git (read-only, click to copy)
Package Base: python-dlib
Description: Dlib is a general purpose cross-platform C++ library designed using contract programming and modern C++ techniques.
Upstream URL: http://www.dlib.net/
Licenses: boost
Conflicts: python-dlib
Provides: python-dlib
Submitter: u1bmoW1r16
Maintainer: petronny (AutoUpdateBot)
Last Packager: petronny
Votes: 16
Popularity: 0.133642
First Submitted: 2016-10-27 15:05 (UTC)
Last Updated: 2024-08-10 03:07 (UTC)

Required by (6)

Sources (1)

Pinned Comments

petronny commented on 2024-03-30 13:11 (UTC) (edited on 2024-03-30 13:13 (UTC) by petronny)

Set _build_cpu and _build_cuda to 1 and 0 to build or not build the CPU or CUDA version.

If options=(!lto) has no effect, please check if it's still enabled in /etc/makepkg.conf.

petronny commented on 2023-11-28 04:57 (UTC)

Prebuilt binaries of this package can be found in arch4edu.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

MarsSeed commented on 2024-03-30 13:36 (UTC)

The options=(!lto) setting in a PKGBUILD always overrides the LTO switch for that particular build, regardless of what any makepkg.conf contains.

petronny commented on 2024-03-30 13:11 (UTC) (edited on 2024-03-30 13:13 (UTC) by petronny)

Set _build_cpu and _build_cuda to 1 and 0 to build or not build the CPU or CUDA version.

If options=(!lto) has no effect, please check if it's still enabled in /etc/makepkg.conf.

nursoda commented on 2024-03-13 14:06 (UTC)

@petronny Please update the PKGBUILD as pointed out by Encrypt-Keeper.

coyotepunk05 commented on 2024-02-23 09:43 (UTC)

Disabling LTO in /etc/makepkg.conf gets rid of the error. Thanks.

Eeems commented on 2024-02-22 19:05 (UTC)

@ndoskrnl You seem to be mistaken, I'm not the maintainer, and it appears that this doesn't resolve the issue for some users.

Encrypt-Keeper commented on 2024-02-22 18:07 (UTC) (edited on 2024-02-22 18:10 (UTC) by Encrypt-Keeper)

I can confirm the issue with being unable to build due to the error generated with LTO version 12.0 instead of the expected 13.0 compilation terminated:

Uncommenting options=(!lto) in the PKGBUILD has no effect. Still fails with the same error.

Editing /etc/makepkg.conf and replacing OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge debug lto) with OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug !lto)

Allowed me to successfully build the package.

songtianlun commented on 2024-02-22 06:21 (UTC)

Disabling LTO in /etc/makepkg.conf can resolve the issue of generated with LTO version 12.0 instead of the expected 13.0 compilation terminated:

- OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge debug lto)
+ OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge debug !lto)

coyotepunk05 commented on 2024-02-19 01:36 (UTC)

I am having the same issue with the LTO version. Uncommenting ##options=(!lto) does not make any difference. The package build still fails and gives the same error.

Has anyone found a way around this yet?

ndoskrnl commented on 2024-02-14 09:08 (UTC) (edited on 2024-02-14 09:13 (UTC) by ndoskrnl)

@MarsSeed I found the cause of issue by compare my system's '/etc/makepkg.conf' with the one in clean chroot. It shows that new version of pacman (as of 'core/pacman 6.0.2-9' now) makes option link time optimization enabled by default:

diff --text --unified --color=always /etc/makepkg.conf /mnt/chroots/arch/root/etc/makepkg.conf

@@ -92,7 +94,7 @@
 #-- debug:      Add debugging flags as specified in DEBUG_* variables
 #-- lto:        Add compile flags for building with link time optimization
 #
-OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug !lto)
+OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge debug lto)

 #-- File integrity checks to use. Valid: md5, sha1, sha224, sha256, sha384, sha512, b2
 INTEGRITY_CHECK=(sha256)

Since the makedep 'cuda' is still using gcc-12 which will generate 'dlib_generated_cuda_dlib.cu.o' and 'dlib_generated_cusolver_dlibapi.cu.o':

readelf -p .comment /mnt/chroots/arch/extra-x86_64/ndoskrnl/build/python-dlib/src/dlib-19.24.2-cuda/build/temp.linux-x86_64-cpython-311/dlib_build/libdlib.a outputs

...
File: /mnt/chroots/arch/extra-x86_64/ndoskrnl/build/python-dlib/src/dlib-19.24.2-cuda/build/temp.linux-x86_64-cpython-311/dlib_build/libdlib.a(dlib_generated_cuda_dlib.cu.o)

String dump of section '.comment':
  [     1]  GCC: (GNU) 12.3.0


File: /mnt/chroots/arch/extra-x86_64/ndoskrnl/build/python-dlib/src/dlib-19.24.2-cuda/build/temp.linux-x86_64-cpython-311/dlib_build/libdlib.a(dlib_generated_cusolver_dlibapi.cu.o)

String dump of section '.comment':
  [     1]  GCC: (GNU) 12.3.0

So new installed systems will built python-dlib[-cuda] into fails at all due to different LTO version.

Therefore I recommend the maintainer @Eeems to uncomment the '##options=(!lto)' in file PKGBUILD default.

Eeems commented on 2024-02-12 06:45 (UTC) (edited on 2024-02-12 06:46 (UTC) by Eeems)

In case anybody is wondering, a fresh build using archlinux:latest with base-devel, and the required packages works with no issue. So something appears to be wrong with MarsSeed's system. If anybody else is having the same error, it would be helpful if you were to leave a comment as such, and if the solution provided here works: https://aur.archlinux.org/pkgbase/python-dlib#comment-945557

« First ‹ Previous 1 2 3 4 5 6 Next › Last »