Package Details: dlib 19.24-1

Git Clone URL: https://aur.archlinux.org/dlib.git (read-only, click to copy)
Package Base: dlib
Description: A general purpose cross-platform C++ library designed using contract programming and modern C++ techniques
Upstream URL: http://dlib.net
Keywords: algebra convolutional deep dlib learning linear machine networks neural
Licenses: custom
Submitter: pingplug
Maintainer: pingplug (swiftscythe, xantares)
Last Packager: swiftscythe
Votes: 35
Popularity: 0.011036
First Submitted: 2015-08-19 09:02 (UTC)
Last Updated: 2022-05-08 16:54 (UTC)

Pinned Comments

Latest Comments

batyu commented on 2022-05-27 19:46 (UTC) (edited on 2022-05-27 19:49 (UTC) by batyu)

Recent dlib update leads to missing dependency: /usr/lib/photoview/photoview: error while loading shared libraries: libdlib.so.19.23.0: cannot open shared object file: No such file or directory

I tried to reinstall it, but the build failed:

WARNING: You are currently running a version of TypeScript which is not officially supported by @typescript-eslint/typescript-estree.

You may find that it works just fine, or you may not.

SUPPORTED TYPESCRIPT VERSIONS: >=3.3.1 <4.5.0

YOUR TYPESCRIPT VERSION: 4.5.5

Please only submit bug reports when using the officially supported version.

============= Failed to compile.

You must provide the URL of lib/mappings.wasm by calling SourceMapConsumer.initialize({ 'lib/mappings.wasm': ... }) before using SourceMapConsumer
I don't know if the warning is relevant, the full output is quite long and I don't see what else is relevant.

xantares commented on 2021-12-13 09:58 (UTC) (edited on 2021-12-13 10:37 (UTC) by xantares)

seems dlib.net timeouts or has an invalid certificate

maybe fetching the tarball from github would be more reliable ?

bartus commented on 2021-08-12 14:28 (UTC) (edited on 2021-08-12 14:44 (UTC) by bartus)

Maintaining two packages for different variant of same package is rather suboptimal. But as you refrain form using config vars in the PKGBUILD, perhaps you would like implement detection ofavx2 extension of the host cpu and enable the USE_AVX_INSTRUCTIONS cmake flag base on that?

Check appleseed PKGBUILD for reference: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=appleseed#n70

!btw. I've to gave some thought to my appleseed PKGBUILD as user may cross build for different machine and would want a direct control over the CPU optimization flags...

swiftscythe commented on 2021-01-17 15:15 (UTC)

@xantares, I don't have the rights to do that... but I can set it up in the following days :)

xantares commented on 2021-01-17 11:01 (UTC)

can you add me to the package maintainers, I'll try to set up the ENABLE_CUDA var

xantares commented on 2021-01-08 17:40 (UTC)

that would be cool

bartus commented on 2021-01-07 11:33 (UTC) (edited on 2021-01-07 11:35 (UTC) by bartus)

@swiftscythe: You can use env var like ENABLE_CUDA to gave users ability to control if build with or without cuda. I'm already doing this for some of my PKGBUILDs: e.g: blender, luxcorerender

xantares commented on 2021-01-06 12:35 (UTC) (edited on 2021-01-06 12:39 (UTC) by xantares)

could the dlib-cuda be moved to a separate PKGBUILD ?

this would avoid to install the huge cuda packages (4GB once installed) if we only use the regular dlib

xan.

swiftscythe commented on 2021-01-04 07:01 (UTC)

@Kicer, oops, I forgot to add the provides=(dlib) to dlib-cuda. Should be fine now.

Kicer commented on 2020-12-29 20:57 (UTC)

@swiftscythe then maybe this package should be split into two?

Kicer commented on 2020-12-29 11:51 (UTC)

I have installed dlib-cuda variant of this package. Then in another package I setup make dependency like this: makedepends=('dlib'). I would expect it will work with both dlib and dlib-cuda variants, but it does not. It explicitly demands dlib variant. Do I misunderstand something, or it simply won't work this way?

swiftscythe commented on 2020-12-15 06:03 (UTC)

@kailua, I completely agree with you. I guess if this was in the official repositories, it would make sense, because the packagers must generate all the packages in the PKGBUILD, but in the AUR it's probably not the best, since users without Nvidia graphics cards will have to install CUDA just to build the CPU-only version. I am for removing from the makedepends of the complete package as well, even if namcap is not happy about it. We have reasons.

kailua commented on 2020-12-11 11:41 (UTC)

@bartus and @swiftscythe I would rather not add cuda and cudann to makedepends for the complete package. It will install giga bytes of packages even if you are just building the split package without cuda.

Is there a better way to satisfy namcap?

bartus commented on 2020-12-04 17:49 (UTC) (edited on 2020-12-04 17:49 (UTC) by bartus)

Three things:

  1. There should be ${MAKEFLAGS:--j1} in ninja call in order for `options=(!makeflags) to work (trust me, I've switched most my packages to ninja ;)

  2. There's some garbage in /usr/include/dlib/external. It holds stuff like zlib,libjpeg,pybind11 etc. redundant to system ones.

  3. Looks like cuda is missing from makedepends[]

namcap dlib/PKGBUILD
PKGBUILD (dlib) E: Split PKGBUILD needs additional makedepends ['cuda', 'cudnn'] to work properly

swiftscythe commented on 2020-11-07 02:25 (UTC)

@xantares done

xantares commented on 2020-11-05 12:10 (UTC)

also your package does not honor makepkg's MAKEFLAGS variable, and ninja by default uses N+2 threads, this exhausts my memory can you pass MAKEFLAGS to ninja ? or else regular makefiles are fine also

swiftscythe commented on 2020-11-02 01:28 (UTC)

@xantares, sure I will update it. However I did it because openblas is faster, so I was thought people want to use that instead of complaining on GitHub why it's slow (as I've seen many times). But I guess that's not for me to decide.

xantares commented on 2020-10-28 10:29 (UTC) (edited on 2020-10-30 11:42 (UTC) by xantares)

hello,

setting openblas as as dependency instead of the blas virtual package

means that we can no longer decide whether to use openblas or the regular blas

it also leads to conflicts

would you reconsider that choice ?

swiftscythe commented on 2020-09-02 08:56 (UTC)

Would you be willing to add a split package (in the same fashion as pytorch or tensorflow) that builds dlib-cpu and dlib-cuda?

I could do it if you wanted me to :)

harbind commented on 2020-04-06 11:14 (UTC) (edited on 2020-04-06 11:46 (UTC) by harbind)

I was coming here to suggest to change the source to the official site, but noticed that someone already did that. That sourceforge is slow at its best, quite often you get nothing out from it.

I can also verify that this package compiles and works fine on both armv7h and aarch64, if you want to update the arch array.

sandsmark commented on 2020-04-04 14:39 (UTC) (edited on 2020-04-04 14:40 (UTC) by sandsmark)

Another request: sourceforge is extremely slow (at least here), could you switch to either the official site (dlib.net) or github?

official is pretty straightforward, it's the same tarball:

  -source=("https://downloads.sourceforge.net/project/dclib/${pkgname}/v${pkgver}/${pkgname}-${pkgver}.tar.bz2")
  +source=("http://dlib.net/files/${pkgname}-${pkgver}.tar.bz2")

Github only has tar.gz as far as I know, so it needs a different sha256sum:

  -source=("https://downloads.sourceforge.net/project/dclib/${pkgname}/v${pkgver}/${pkgname}-${pkgver}.tar.bz2")
  -sha256sums=('1decfe883635ce51acd72869cebe870ab9b85eb094d417adc8f48aa7b8c60cd7')
  +source=("https://github.com/davisking/${pkgname}/archive/v${pkgver}.tar.gz")
  +sha256sums=('7af455bb422d3ae5ef369c51ee64e98fa68c39435b0fa23be2e5d593a3d45b87')

sandsmark commented on 2019-08-07 16:25 (UTC) (edited on 2020-04-04 14:41 (UTC) by sandsmark)

Would be nice to install imglab as well. Not sure if this is the best solution, but it works:

http://ix.io/1QV8

edit: putting it inline, in case ix.io becomes unavailable:

diff --git PKGBUILD PKGBUILD
index 378f43b..55ba9ce 100644
--- PKGBUILD
+++ PKGBUILD
@@ -23,20 +23,31 @@ sha256sums=('24772f9b2b99cf59a85fd1243ca1327cbf7340d83395b32a6c16a3a16136327b')

 build() {
   cd "${srcdir}"
-  mkdir -p build && cd build
-  cmake \
+  export CMAKE_ARGS="
     -DCMAKE_INSTALL_PREFIX:PATH=/usr \
     -DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib \
     -DBUILD_SHARED_LIBS:BOOL=ON \
     -DCUDA_HOST_COMPILER='/opt/cuda/bin/gcc' \
     -DCMAKE_BUILD_TYPE=Release \
-    "../${pkgname}-${pkgver}"
+  "
   if [[ -f "/usr/lib/ccache/bin/nvcc-ccache" ]] ; then
-    cmake \
+    CMAKE_ARGS+=" \
       -DCUDA_NVCC_EXECUTABLE=/usr/lib/ccache/bin/nvcc-ccache \
       -DCUDA_HOST_COMPILER=/usr/lib/ccache/bin/gcc \
-      "../${pkgname}-${pkgver}"
+      "
   fi
+
+  mkdir -p build && cd build
+  cmake \
+    ${CMAKE_ARGS} \
+    "../${pkgname}-${pkgver}"
+  make
+
+  cd "${srcdir}"
+  mkdir -p build-imglab && cd build-imglab
+  cmake \
+    ${CMAKE_ARGS} \
+    "../${pkgname}-${pkgver}/tools/imglab"
   make
 }

@@ -44,6 +55,9 @@ package() {
   cd "${srcdir}/build"
   make DESTDIR=${pkgdir} install
   install -Dm644 "../${pkgname}-${pkgver}/dlib/LICENSE.txt" "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
+
+  cd "${srcdir}/build-imglab"
+  make DESTDIR=${pkgdir} install
 }

 # vim:set ts=2 sw=2 et:

xantares commented on 2019-04-25 09:36 (UTC) (edited on 2019-04-25 09:36 (UTC) by xantares)

hi,

you have to replace blas by cblas in depends

pingplug commented on 2019-04-25 09:10 (UTC)

xantares:

report empty dir issue (also missing cmake files) to upstream

xantares commented on 2019-04-25 07:30 (UTC)

hi again; here's the ouput of nacmap:

dlib W: Directory (usr/include/dlib/test/tools) is empty

...

dlib E: Dependency libx11 detected and not included (libraries ['usr/lib/libX11.so.6'] needed in files ['usr/lib/libdlib.so.19.17.0'])

dlib E: Dependency cblas detected and not included (libraries ['usr/lib/libcblas.so.3'] needed in files ['usr/lib/libdlib.so.19.17.0'])

dlib W: Dependency blas included but already satisfied

dlib W: Dependency included and not needed ('giflib')

dlib W: Dependency included and not needed ('sqlite')

=> replace blas by cblas, drop giflib, sqlite and add libx11 deps

axionl commented on 2018-07-19 06:35 (UTC)

Should this empty directories be removed?

dlib W: Directory (usr/include/dlib/cmake_utils/test_for_sse4) is empty dlib W: Directory (usr/include/dlib/all) is empty dlib W: Directory (usr/include/dlib/cmake_utils/test_for_cpp11) is empty dlib W: Directory (usr/include/dlib/test/blas_bindings) is empty dlib W: Directory (usr/include/dlib/test/gui) is empty dlib W: Directory (usr/include/dlib/external/libpng/arm) is empty dlib W: Directory (usr/include/dlib/test/tools) is empty dlib W: Directory (usr/include/dlib/cmake_utils/test_for_cudnn) is empty dlib W: Directory (usr/include/dlib/cmake_utils/test_for_cuda) is empty dlib W: Directory (usr/include/dlib/travis) is empty dlib W: Directory (usr/include/dlib/cmake_utils/test_for_neon) is empty dlib W: Directory (usr/include/dlib/cmake_utils/test_for_avx) is empty dlib W: Directory (usr/include/dlib/appveyor) is empty dlib W: Directory (usr/include/dlib/test/examples) is empty

pingplug commented on 2018-07-01 13:21 (UTC)

use this package if you want to speed up CUDA source compilation with ccache https://github.com/pingplug/PKGBUILDs/tree/master/others/ccache-ext

adsun commented on 2018-06-01 21:54 (UTC)

Never mind. I checked the build and it works fine. Sorry for the false alarm.

adsun commented on 2018-05-31 19:35 (UTC)

Please update sha256sums.

unclejimbo commented on 2018-05-04 04:47 (UTC)

Is this package constraining multi-threading to only one core?

When I compiled dlib from source, the multi-threading is normal.

Xyne commented on 2018-01-12 20:19 (UTC) (edited on 2018-01-12 20:22 (UTC) by Xyne)

Hi,

Thank you for maintaining this package.

Given that the provided CMake configuration files build the shared library and that some projects that rely on Dlib require it, this package should build the object files. If they are truly deprecated then let upstream disable them in CMake. The "standard" or "vanilla" package is whatever upstream sets as default in CMake and that is generally what should be provided in Arch. Users who do not need the libs can disable them. If upstream changes the configuration, then users who need them can instead enable them.

libdlib should then be merged into this package if these changes are made.

Here's a PKGBUILD. Thanks!

# Maintainer: pingplug <pingplug@foxmail.com>
# Contributor: perlawk

pkgname=dlib
_pkgname=dlib
pkgver=19.8
pkgrel=2
pkgdesc="Dlib is a general purpose cross-platform C++ library designed using contract programming and modern C++ techniques."
arch=('i686' 'x86_64')
url="<http://www.dlib.net/>"
license=('Boost Software License')
depends=('glibc' 'blas' 'cuda' 'cudnn' 'giflib' 'lapack' 'libjpeg-turbo' 'libpng' 'neon' 'sqlite')
# optdepends=('blas: for BLAS support'
#             'cuda: for CUDA support'
#             'cudnn: for CUDNN support'
#             'giflib: for GIF support'
#             'lapack: for LAPACK support'
#             'libjpeg-turbo: for JPEG support'
#             'libpng: for PNG support'
#             'neon: for neon support'
#             'sqlite: for sqlite support')
source=("<https://downloads.sourceforge.net/project/dclib/>${_pkgname}/v${pkgver}/${_pkgname}-${pkgver}.tar.bz2")
sha256sums=('dbd31f7b97166e58f366c83fa5127e9fa44c492921558b61ce63a7d775be696b')

build() {
  cd "${srcdir}/${_pkgname}-${pkgver}"
  mkdir -p -- build
  cd -- build
  cmake \
    -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DCMAKE_INSTALL_LIBDIR=lib
    ..
  make -j $(($(nproc) + 1))
}

package() {
  cd "${srcdir}/${_pkgname}-${pkgver}/build"
  make DESTDIR="$pkgdir" install
  install -Dm644 ../dlib/LICENSE.txt "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
}

I have left the optdepends for future reference in anticipation of library deprecation. You can of course move any deps back to optdeps or to makedeps if the compiled library does not require them after installation. I didn't check.

rib commented on 2017-11-22 01:48 (UTC)

I ended up creating an alternative 'libdlib' package that installs headers, a libdlib.so library + 'dlib-1' pkg-config file: https://aur.archlinux.org/packages/libdlib

rib commented on 2017-11-22 00:37 (UTC)

Although dlib is possible to use without compiling a libdlib.so it seems awkward to make a package which doesn't install the pkg-config files so projects can't discover this style of dlib packaging. Although I understand the idea of encouraging the use of dlib without needing a shared library; personally I'd still prefer a package that would install a library, headers and pkg-config file, more consistent with other packages, and other distros (at least Ubuntu - I didn't check any others). For the case where dlib is used without a pre-built library the upstream documentation suggests compiling dlib/all/source.cpp which isn't installed via cmake (which is why this package installs them directly I suppose) but with that inconsistency then it seems unlikely much software will be written to expect that /usr/include/dlib/all/source.cpp exists if they want to be easily buildable across a range of distros.

yxchng commented on 2017-09-06 06:31 (UTC)

Why package a library without .so files? How should I use this package?

joker512 commented on 2017-02-09 15:55 (UTC)

Why don't you build .a and .so files in this package?