LuxCoreRender daily/automatic builds

[Dade]

I forgot to mention I did completely remove the addon, confirm the directory is gone, restart Blender, and reinstall the addon by clicking Install in Blender and then locating the 'latest' version that I downloaded from the releases page on GitHub. I've also unpacked the standalone to its own directory elsewhere and it can't find the shared library in that location either. The output of the ldd command in all cases is the same: it has 2 entries for libtbbmalloc.so.2 - the first is "not found" and the second is the correct location. And it won't allow me to install the addon in Blender, or run the standalone.

As a test, try to add the "~/.config/blender/2.81/scripts/addons/BlendLuxCore/bin" directory to your LD_LIBRARY_PATH, does it work ?

[Martini]

As a test, try to add the "~/.config/blender/2.81/scripts/addons/BlendLuxCore/bin" directory to your LD_LIBRARY_PATH, does it work ?

Wow, it did work! I did not have any value set for that variable previously. Thank you, this works. But I feel it should not be necessary...

As another test (I did it before I tried your suggestion), I verified that I can uninstall everything, and install successfully the release version of 2.2 without that variable being set. It's only 2.3 auto that needs it. Additionally strange, is that if in the same Blender session where I installed 2.2, I can uninstall it and successfully install 2.3! That must have been how I did it yesterday, too. Although it then stops working after I restart Blender... unless of course I export that variable.

[Dade]

As a test, try to add the "~/.config/blender/2.81/scripts/addons/BlendLuxCore/bin" directory to your LD_LIBRARY_PATH, does it work ?

Wow, it did work! I did not have any value set for that variable previously. Thank you, this works. But I feel it should not be necessary...

Yes, it shouldn't and it is strange, I will try to do some test un-setting my "LD_LIBRARY_PATH".

[Martini]

Yes, it shouldn't and it is strange, I will try to do some test un-setting my "LD_LIBRARY_PATH".

I can see a small difference in the output of objdump that the working 2.2 release has RPATH $ORIGIN however 2.3 has RUNPATH $ORIGIN. Is there a mistake in the linker config perhaps? From what I can find on ServerOverflow, it needs to be -rpath='$ORIGIN'

[Martini]

Is there a mistake in the linker config perhaps? From what I can find on ServerOverflow, it needs to be -rpath='$ORIGIN'

Hmmm. I can see here that it is unchanged since 3 years ago
https://github.com/LuxCoreRender/LuxCor ... #L258-L264

Code: Select all

IF(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
	SET(CMAKE_EXE_LINKER_FLAGS -Wl,--version-script='${CMAKE_SOURCE_DIR}/cmake/exportmaps/linux_symbol_exports.map')
	SET(CMAKE_SHARED_LINKER_FLAGS -Wl,--version-script='${CMAKE_SOURCE_DIR}/cmake/exportmaps/linux_symbol_exports.map')
	SET(CMAKE_MODULE_LINKER_FLAGS -Wl,--version-script='${CMAKE_SOURCE_DIR}/cmake/exportmaps/linux_symbol_exports.map')
	SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
	SET(CMAKE_INSTALL_RPATH "$ORIGIN")
ENDIF()

[Dade]

Is there a mistake in the linker config perhaps? From what I can find on ServerOverflow, it needs to be -rpath='$ORIGIN'

Hmmm. I can see here that it is unchanged since 3 years ago
https://github.com/LuxCoreRender/LuxCor ... #L258-L264

Code: Select all

IF(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
	SET(CMAKE_EXE_LINKER_FLAGS -Wl,--version-script='${CMAKE_SOURCE_DIR}/cmake/exportmaps/linux_symbol_exports.map')
	SET(CMAKE_SHARED_LINKER_FLAGS -Wl,--version-script='${CMAKE_SOURCE_DIR}/cmake/exportmaps/linux_symbol_exports.map')
	SET(CMAKE_MODULE_LINKER_FLAGS -Wl,--version-script='${CMAKE_SOURCE_DIR}/cmake/exportmaps/linux_symbol_exports.map')
	SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
	SET(CMAKE_INSTALL_RPATH "$ORIGIN")
ENDIF()

We have updated the GCC version used to compile the automatic build so probably something has changed in the default GCC behavior

[Martini]

We have updated the GCC version used to compile the automatic build so probably something has changed in the default GCC behavior

According to this StackOverflow post you can use the option --disable-new-dtags to output the old header tag, RPATH.

The ld dynamic linker does not search DT_RUNPATH locations for transitive dependencies, unlike DT_RPATH.

[Dade]

According to this StackOverflow post you can use the option --disable-new-dtags to output the old header tag, RPATH.

Yes, next build should have this problem fixed and work without LD_LIBRARY_PATH.

[Martini]

Working! Thanks

[Magog]

Hi Guys,
I tried to install the latest build, but I always get this error..