Dependencies missing on Arch [emergency fix works]

Hi all,

I am totally stuck, and I am unable to un-stack myself. I am on Arcolinux (rolling, Arch based), and fetched vkdt from github. Most of the compilation worked just fine — except for four stubborn error messages:

  • Did not find uncompress() function in ZLIB
  • Did not find zError() function in ZLIB
  • Can’t even find plain malloc() / free() !
  • Can’t find any aligned malloc() implementation!

Could someone please point me into the right direction?

Sincerely,
Claes in Lund, Sweden

Do you have the dev version of the libraries?

if you do not want to use the arch linux package built in the OBS … you might be able to use the PKGBUILD file File PKGBUILD of Package vkdt - openSUSE Build Service

Yes, thank you.
But I would very much like to compile it myself
to fit my CPU a bit better (znver2). I am sure there
are several microseconds to gain…

Your CPU isn’t going to do much for VKDT, its all GPU

1 Like

That was a very valid point. Thank you!

1 Like

does that mean you abandoned the idea of compiling now? the malloc/free missing sounds like it’s in the cmake of the rawspeed build? in this case yeah… probably some very basic dev packages missing. that seems very distro specific though. but mica is of course right, the cpu is not doing much (except the raw decoding pass in rawspeed).

Thanks for your reply :slight_smile:

does that mean you abandoned the idea of compiling now?

Temporarily, yes.
I made a swift test using Ubuntu Studio – and there it behaved much better.
However, on this Arch-based distro it does not.

I do agree about some basic dev pkg probably missing — but as far as I understand,
I have fetched every -dev available. Grumpf.

However: I do have vkdt running on this machine, using the OBS pkg.

Have fun!
Claes in Lund, Sweden

Yep. Strange, as on Arch gcc (and gcc-libs) should provide those… Does darktable (also bundling rawspeed) build fine in this environment?

Yes! dt-git compiles just fine.

hm in that case maybe something in the vkdt build setup is wrong? how exactly did you build it?
after a clean checkout, you can edit bin/config.mk to overwrite values from bin/config.mk.defaults. in particular by default it builds with clang (maybe that trips over the test for gcc/malloc?).

if you want to use gcc, put this in your bin/config.mk:

CC=gcc
CXX=g++
export CC CXX
1 Like

Thank you!
Will test immediately after breakfast.

Sincerely,
Claes in Lund, Sweden

In that case there might be some other packages missing on Arch… The PKGBUILD recipe mentioned above has clang, llvm, and openmp among others.

1 Like

Btw, just tried building myself for Windows using the MSYS2 CLANG64 environment, and I’m hitting the same issue:

-- Looking for uncompress
-- Looking for uncompress - not found
CMake Error at cmake/Modules/CheckZLIB.cmake:57 (message):
  Did not find uncompress() function in ZLIB
Call Stack (most recent call first):
  cmake/src-dependencies.cmake:158 (include)
  CMakeLists.txt:213 (include)


-- Looking for zError
-- Looking for zError - not found
CMake Error at cmake/Modules/CheckZLIB.cmake:62 (message):
  Did not find zError() function in ZLIB
Call Stack (most recent call first):
  cmake/src-dependencies.cmake:158 (include)
  CMakeLists.txt:213 (include)


-- Looking for ZLIB - found (system)
-- Looking for malloc
-- Looking for malloc - not found
-- Looking for free
-- Looking for free - not found
CMake Error at cmake/Modules/memory-align-alloc.cmake:13 (message):
  Can't even find plain malloc() / free() !
Call Stack (most recent call first):
  src/CMakeLists.txt:1 (include)


-- Looking for aligned_alloc
-- Looking for aligned_alloc - not found
-- Looking for posix_memalign
-- Looking for posix_memalign - not found
-- Looking for _aligned_malloc
-- Looking for _aligned_malloc - not found
-- Looking for _aligned_free
-- Looking for _aligned_free - not found
CMake Error at cmake/Modules/memory-align-alloc.cmake:34 (message):
  Can't find any aligned malloc() implementation!
Call Stack (most recent call first):
  src/CMakeLists.txt:1 (include)

zlib is of course installed and found earlier:

-- Found ZLIB: C:/msys64/clang64/lib/libz.dll.a (found suitable version "1.3", minimum required is "
1.2.11")

As standalone rawspeed builds just fine (and darktable using it as a submodule build fine as well), there’s likely something going on w/ how it’s built/integrated here (starting w/ the hard-coded -G "Unix Makefiles")…

This e.g. works in my standalone rawspeed git clone folder (MSYS specific generator):

cmake \
  -G "MSYS Makefiles" \
  -DCMAKE_INSTALL_PREFIX=/opt/rawspeed \
  -DCMAKE_BUILD_TYPE=Release \
  -DBUILD_TESTING=OFF \
  -DBUILD_BENCHMARKING=OFF \
  -DBUILD_FUZZERS=OFF \
  -S . -B build

However, if I try to run the same manually from vkdt/ext/rawspeed, I get the error above again.

So, something wrong w/ that submodule commit? Too old? CMake version in Arch and MSYS2 (3.27.4 here) too new for it?

1 Like

Yep, rawspeed dev branch has a new cmake_policy(SET CMP0067 NEW): CMP0067 — CMake 3.28.2 Documentation

try_compile() fails for all these tests on this old rawspeed commit and more recent CMake…

@kmilos Thank you!
I am so happy that I am not alone in this wilderness :slight_smile:

1 Like

Tried adding this as well, but it’s not sufficient, there’s more going on I guess :confused:

Ok, it looks like it was this change: Disable clang's shiny new `-Wunsafe-buffer-usage` for now · darktable-org/rawspeed@e4c667b · GitHub

Recent Clang elevated this to an error, which makes CMake’s try_compile() fail.

I guess -Wno-unsafe-buffer-usage can be added to the vkdt Makefiles somewhere instead of changing the rawspeed submodule…

1 Like

In conclusion, vkdt might benefit from a wider CI net than the outdated Ubuntu 22.04 default compilers. Clang 15 and GCC 12 are available for example (as is GCC 13 if the ubuntu-toolchain-r PPA is used).

P.S. Hard-coding CC and CXX (or requiring creation of a new file just to change those) is not great for testing flexibility obviously.

P.P.S. make -j20 is senseless on GHA runners.

so you’re saying trying to update/re-merge the CR3 stuff into a current rawspeed commit would likely fix this?