Project

General

Profile

Bug #11641

darktable doesn't build with lua enabled

Added by Nick Kachulin 11 months ago. Updated 11 months ago.

Status:
New
Priority:
Low
Category:
Lua
Target version:
-
Start date:
06/06/2017
Due date:
% Done:

0%

Affected Version:
2.2.5
System:
other GNU/Linux
bitness:
64-bit
hardware architecture:
amd64/x86

Description

Attempting to get lua-enabled darktable on Gentoo...
After enabling lua in cmake compilation fails with "lua.h not found" in LuaAutoC (see attachment).
There are 3 #include "..." statements there which files are in ../lua in fact.
Maybe I've done something wrong? Please help...

build.log Magnifier (65.9 KB) Nick Kachulin, 06/06/2017 09:06 PM

darktable-2.2.5.ebuild (3.84 KB) Nick Kachulin, 06/06/2017 09:11 PM

darktable-2.2.5.ebuild (3.91 KB) Nick Kachulin, 06/07/2017 03:10 PM

lua5.2.pc (655 Bytes) Nick Kachulin, 06/08/2017 05:20 PM

lua5.2.3-r1.files - All the files that belong to installed package. (1.28 KB) Nick Kachulin, 06/08/2017 05:21 PM

History

#1 Updated by Roman Lebedev 11 months ago

It does build just fine on debian, with external lua
So my guess would be that there is something wrong with the include path
E.g. there should be something like -isystem /usr/include/lua5.2 in that compile output
And it is not there

PS: it might be easier to solve such issues through IRC...

#2 Updated by Nick Kachulin 11 months ago

Roman, thanx for the clue!
Managed to get it working through a dirty hack adding -DCMAKE_C_FLAGS and -DCMAKE_CXX_FLAGS... Have spent few hours trying to find out how to do it in a kosher way, but cmake refused to add -isystem via its variable. CMAKE_INCLUDE_PATH or CMAKE_INCLUDE_DIRECTORIES were supposed to do the trick but nope...

#3 Updated by Tobias Ellinghaus 11 months ago

In what path do you have Lua installed? Anything non-standard?

#4 Updated by Nick Kachulin 11 months ago

No, and... yes. The issue with Gentoo is that normally it still has only lua5.1 installable into slot 0 ("standard").
The necessity to have few version in the same system is implemented via installation in different slots and have the eselect command to switch symlinks to one or another versions to be the default one (as one of possible solutions). However the transition to slotted implementation is stuck due to retiring the mantainer or something like this. So "no" means that lua is installed in a standard way in the standard place, while "yes" means that I used hardmasked and unsupported option to achieve this. Since darktable is the only lua consumer in my system I think it is absolutely okay at the moment.
However. My issue appeared at the building stage. As Roman pointed out, cmake for some reason does not include lua headers path and did not pass "-isystem /usr/include/lua5.2" to the compiler that fais to find proper heades, and this is the issue. I brute-forced this via CFLAGS, which is incorrect yet allows dt to compile. If somebody suggests me how to solve this correctly, I mean, to make cmake to pass this include path to gcc, I'll put my ebuild to bugzilla to allow Gentoo folks to take advantage of lua in dt.

#5 Updated by Tobias Ellinghaus 11 months ago

Please show us your CMakeCache.txt. In theory CMake should add the Lua include directory, maybe something went wrong there.

#6 Updated by Roman Lebedev 11 months ago

Nick Kachulin wrote:

No, and... yes. The issue with Gentoo is that normally it still has only lua5.1 installable into slot 0 ("standard").
The necessity to have few version in the same system is implemented via installation in different slots and have the eselect command to switch symlinks to one or another versions to be the default one (as one of possible solutions). However the transition to slotted implementation is stuck due to retiring the mantainer or something like this. So "no" means that lua is installed in a standard way in the standard place, while "yes" means that I used hardmasked and unsupported option to achieve this. Since darktable is the only lua consumer in my system I think it is absolutely okay at the moment.

Does the lua5.2 package installs .pc file? Can you upload it here?

However. My issue appeared at the building stage. As Roman pointed out, cmake for some reason does not include lua headers path and did not pass "-isystem /usr/include/lua5.2" to the compiler that fais to find proper heades, and this is the issue. I brute-forced this via CFLAGS, which is incorrect yet allows dt to compile. If somebody suggests me how to solve this correctly, I mean, to make cmake to pass this include path to gcc, I'll put my ebuild to bugzilla to allow Gentoo folks to take advantage of lua in dt.

#7 Updated by Nick Kachulin 11 months ago

Here you go...
lua5.2.3-r1.files shows all the files that belong to installed package. Just for the case...
Moreover, there is a symlink, too. It doesn't belong to the package and is set up after installation by eselect.
lrwxrwxrwx 1 root root 23 июн 7 14:01 /usr/lib64/liblua.so -> /usr/lib64/liblua5.2.so

As for CMakeCache.txt, I'll post it a little bit later: successful build purges all the files, so I'll have to disable the cleanup and reinstall dt.
Thanks!

#8 Updated by Tobias Ellinghaus 11 months ago

That .pc file looks broken, on my Debian box I got

Cflags: -I${includedir}/${lib_name_include}

while yours has

Cflags: -I${includedir}

So mine adds /usr/include/lua5.2 and yours /usr/include

#9 Updated by Nick Kachulin 11 months ago

Okay, that was the case...
Manual editing lua5.2.pc has solved the problem and the ugly kludge has gone from the ebuild...
Will report the problem to gentoo bugzilla, but not sure about how fast the change will come, given than a maintainer seem to be absent.
Thank you guys, the issue is to be closed, I think.

UPD: Now I've a clue about how fast it may be. There is a bug on bugzilla about it for about a year...

#10 Updated by Roman Lebedev 11 months ago

Nick Kachulin wrote:

UPD: Now I've a clue about how fast it may be. There is a bug on bugzilla about it for about a year...

g
And do note that in git master, we have already finally switched to lua5.3, so unless by some strange logic gentoo has decided to unmask lua5.2 AFTER lua5.3, the lua support will be lost again with the next major dt release

#11 Updated by Nick Kachulin 11 months ago

No, the logic is different))) Gentoo still has lua 5.1 in portage tree stabilized. Since minor lua releases are incompatible (say hi to gtk3 and wave your hand))), there was a decision (sane!) to go on with slotted implementation to allow to keep few versions simultaneously since apps are upgraded at different pace and the maintainers cannot just upgrade the lua in favor of some apps because it'll break some others. However there is no person responsible for transition to slotted lua due to lack of maintainers, so we have 5.2 and 5.3 in the tree masked because no one takes care about them (sane also!) and hanging bug reports. As soon as someone come up to become a lua maintainer, the situation will drastically improve. Unfortunately, a lot of useful programs are out of tree due to lack of maintainers: devs can't keep them in-tree without a proper care. There is few overlays full of such stuff kept or moved out of tree. (BTW just found overlay with lua stuff. Will see if it has better ebuilds than masked ones it the main tree...)

Also available in: Atom PDF