Package Details: luxcorerender 2:2.7.beta1-2

Git Clone URL: https://aur.archlinux.org/luxcorerender.git (read-only, click to copy)
Package Base: luxcorerender
Description: Physically correct, unbiased rendering engine.
Upstream URL: https://www.luxcorerender.org/
Licenses: Apache
Provides: luxrays
Submitter: bartus
Maintainer: bartus (howetuft)
Last Packager: bartus
Votes: 15
Popularity: 0.000077
First Submitted: 2018-05-11 21:03 (UTC)
Last Updated: 2024-11-25 20:46 (UTC)

Dependencies (21)

Sources (15)

Pinned Comments

bartus commented on 2020-06-11 15:32 (UTC) (edited on 2020-08-22 09:39 (UTC) by bartus)

This package is also hosted on GitHub.
Use env vars to control build process:
  • DISABLE_OPENCL=1 to skip opencl kernel build (yields DISABLE_CUDA=1)
  • DISABLE_CUDA=1 to skip cuda kernel build.
Usage cases:
  • export DISABLE_CUDA=1 before build
  • DISABLE_CUDA=1 ~your-aur-helper~
  • makepkg DISABLE_CUDA=1
  • yay -S blender-2.8-git --mflags "DISABLE_CUDA=1"

bartus commented on 2019-04-10 11:42 (UTC)

Please report issues and patches to luxcorerender@github.com

Latest Comments

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

bartus commented on 2019-10-19 14:37 (UTC) (edited on 2019-10-19 14:40 (UTC) by bartus)

@NorthSailor: Yep, fixed.

We could even drop glfw from dedpends as it's a dependency of testing gui.

nsailor commented on 2019-10-19 07:50 (UTC) (edited on 2019-10-19 07:50 (UTC) by nsailor)

Is there any reason why this package depends on glfw-x11 instead of just glfw? I'm running Sway and changing the dependency to glfw (satisfied by glfw-wayland on my system) seems to work fine.

bartus commented on 2019-10-06 12:24 (UTC) (edited on 2019-10-06 12:32 (UTC) by bartus)

@omgold: Can't reproduce: I have the same flags in link.txt as in your case.

build/samples/luxcoredemo/CMakeFiles/luxcoredemo.dir/link.txt

/usr/bin/c++

-march=x86-64
-mtune=generic
-O2
-pipe
-fno-plt
-std=c++11
-Wall
-Wno-long-long
-pedantic
-msse
-msse2
-msse3
-mssse3
-fPIC
-fopenmp

-Wl,--version-script='/build/luxcorerender/src/LuxCore-luxcorerender_v2.2/cmake/exportmaps/linux_symbol_exports.map'
-rdynamic
CMakeFiles/luxcoredemo.dir/luxcoredemo.cpp.o

-o
../../bin/luxcoredemo
-Wl,-rpath,"\$ORIGIN"
../../lib/libluxcore.a
../../lib/libslg-core.a
../../lib/libslg-film.a
../../lib/libslg-kernels.a
../../lib/libluxrays.a
../../lib/libbcd.a
../../lib/libopenvdb.a
-lembree3
-lOpenImageDenoise
-ltbb
-ltbb
-ltiff
-ltiff
-lIex
-lIlmImf
-lHalf
-lImath
-lIlmThread
-lpng
-lz
-ljpeg
/usr/lib64/libboost_thread.so.1.71.0
/usr/lib64/libboost_program_options.so.1.71.0
/usr/lib64/libboost_filesystem.so.1.71.0
/usr/lib64/libboost_serialization.so.1.71.0
/usr/lib64/libboost_iostreams.so.1.71.0
/usr/lib64/libboost_regex.so.1.71.0
/usr/lib64/libboost_system.so.1.71.0
/usr/lib64/libboost_python37.so.1.71.0
/usr/lib64/libboost_chrono.so.1.71.0
/usr/lib64/libboost_serialization.so.1.71.0
/usr/lib64/libboost_numpy37.so.1.71.0
-lpython3.7m
-lOpenCL
-lpthread
/usr/lib64/libboost_python37.so.1.71.0
-lOpenImageIO
-lGL
-lOpenCL

But luxcoredemo builds without the issue, and it gets linked with /usr/lib/libGLX.so as expected

ldd build/bin/luxcoredemo |grep -i glx
        libGLX.so.0 => /usr/lib/libGLX.so.0 (0x00007fb822ebd000)

Could you perhaps try build luxcorerender with extra-x86_64-build from devtools ( you can use -r /tmp flag to build in ram ) ( resolve missing oidn dep with -- -I "$$oidn$$pkg.tar" flag )

omgold commented on 2019-10-06 09:08 (UTC)

It seems there is a library dependency issue. Stuff that needs OpenCL seems to need GLX also:

/usr/lib/ccache/bin/c++ -march=haswell -mtune=native -O2 -pipe -fstack-protector-strong -fno-plt -std=c++11 -Wall -Wno-long-long -pedantic -msse -msse2 -msse3 -mssse3 -fPIC -fopenmp -Wl,--version-script='/home/omangold/cache/luxcorerender/luxcorerender/src/LuxCore-luxcorerender_v2.2/cmake/exportmaps/linux_symbol_exports.map' -rdynamic CMakeFiles/luxcoredemo.dir/luxcoredemo.cpp.o -o ../../bin/luxcoredemo -Wl,-rpath,"\$ORIGIN" ../../lib/libluxcore.a ../../lib/libslg-core.a ../../lib/libslg-film.a ../../lib/libslg-kernels.a ../../lib/libluxrays.a ../../lib/libbcd.a ../../lib/libopenvdb.a -lembree3 -lOpenImageDenoise -ltbb -ltbb -ltiff -ltiff -lIex -lIlmImf -lHalf -lImath -lIlmThread -lpng -lz -ljpeg -lboost_thread -lpthread -lboost_program_options -lboost_filesystem -lboost_serialization -lboost_iostreams -lboost_regex -lboost_system -lboost_python3 -lboost_chrono -lboost_serialization -lboost_numpy3 -lboost_date_time -lboost_atomic -lpython3.7m -lOpenCL -lOpenImageIO -lboost_thread -lpthread -lboost_program_options -lboost_filesystem -lboost_serialization -lboost_iostreams -lboost_regex -lboost_system -lboost_python3 -lboost_chrono -lboost_serialization -lboost_iostreams -lboost_regex -lboost_system -lboost_python3 -lboost_chrono -lboost_numpy3 -lboost_date_time -lboost_atomic -lOpenCL /usr/bin/ld: ../../lib/libluxrays.a(device.cpp.o): in function luxrays::OpenCLDeviceDescription::GetOCLContext() const': device.cpp:(.text+0xaa8): undefined reference toglXGetCurrentContext' /usr/bin/ld: device.cpp:(.text+0xab3): undefined reference to `glXGetCurrentDisplay' collect2: error: ld returned 1 exit status make[2]: [samples/luxcoredemo/CMakeFiles/luxcoredemo.dir/build.make:143: bin/luxcoredemo] Error 1 make[2]: Leaving directory '/srv/cache/omangold/luxcorerender/luxcorerender/src/LuxCore-luxcorerender_v2.2/build' make[1]: [CMakeFiles/Makefile2:600: samples/luxcoredemo/CMakeFiles/luxcoredemo.dir/all] Error 2 make[1]: Leaving directory '/srv/cache/omangold/luxcorerender/luxcorerender/src/LuxCore-luxcorerender_v2.2/build' make: *** [Makefile:87: all] Error 2

bartus commented on 2019-04-10 11:42 (UTC)

Please report issues and patches to luxcorerender@github.com

bartus commented on 2019-03-31 22:17 (UTC) (edited on 2019-03-31 22:21 (UTC) by bartus)

@darkshadow44 Yes, your solution for luxmark is exactly how it should be.

DarkShadow44 commented on 2019-03-31 20:59 (UTC) (edited on 2019-03-31 21:00 (UTC) by DarkShadow44)

Download https://aur.archlinux.org/cgit/aur.git/snapshot/aur-e907af0a8906.tar.gz and try to compile that (old luxmark PKGBUILD)

/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../lib/libslg-film.a(intel_oidn.cpp.o): in function `slg::IntelOIDN::Apply(slg::Film&, unsigned int)':
(.text+0x1ac): undefined reference to `oidnNewDevice'
/usr/bin/ld: (.text+0x1be): undefined reference to `oidnCommitDevice'

The .a file in question is owned by luxcorerender. Do I have to link in oidn or should be linking luxrendercore be enough?

bartus commented on 2019-03-31 20:50 (UTC)

@DarkShadow44: please specify what's the problem with oidn exactly, I can't reproduce the issue base on your description.

DarkShadow44 commented on 2019-03-31 20:23 (UTC)

Works fine, thanks! Luxmark is finally compiling again.

Now where I'm not quite sure, luxcorerender depends on oidn - why do I have to manually link oidn when referencing luxcorerender?

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