[SOLVED] Slackware 14.2 - llvm-6.0.1 / cmake regression.

orbea · 09-14-2018, 09:25 AM

It was brought to my attention that lightspark from SBo no longer builds in Slackware 14.2 due to the llvm-6.0.1 update, but it still builds fine in current with the same llvm version. In 14.2 it will fail with several errors from missing headers such as.

Code:

/tmp/SBo/lightspark/src/scripting/abc.cpp:38:27: fatal error: llvm/Module.h: No such file or directory

However lightspark does have checks for the newer header locations already as can be seen in these lines.

https://github.com/lightspark/lights...LVM.cmake#L209
https://github.com/lightspark/lights...ng/abc.cpp#L34

This reveals that 'check_include_file_cxx' in cmake-3.5.2 does not actually work, but I built cmake-3.12.2 from current in 14.2 without issues and found that lightspark now builds fine again.

Would it be possible to update cmake in 14.2 too given that the newer llvm has revealed this to be a problem with at least one program? Or suppose there is a better solution? I would prefer to not hack lightspark if possible.

ponce · 09-14-2018, 09:37 AM

the newer cmake actually introduces some regressions for other packages (consider I'm saying this having tested it only for the third party ones), I'm not that sure that it could be the best solution to push it in 14.2...

orbea · 09-14-2018, 09:46 AM

I realize that is likely, however this slippery slope was already started with llvm, rust and firefox. I think the correct solution is to either revert this whole mess or finish what was started and update cmake as well as resolve anything else that reveals itself afterwards...

ponce · 09-14-2018, 09:49 AM

...or, in alternative, patch lightspark.

orbea · 09-14-2018, 09:50 AM

Lightspark is already fixed, this is a cmake bug.

orbea · 09-14-2018, 10:27 AM

But yes, a lightspark hack would look like this. I don't like it though.

Code:

sed -e 's|llvm/Module.h|llvm/IR/Module.h|' \
    -e 's|llvm/LLVMContext.h|llvm/IR/LLVMContext.h|' \
    -e 's|llvm/Constants.h|llvm/IR/Constants.h|' \
    -e 's|llvm/Analysis/Verifier.h|llvm/IR/Verifier.h|' \
    -e 's|llvm/Target/TargetData.h|llvm/Transforms/Scalar/GVN.h|' \
    -i src/scripting/abc.cpp

sed -e 's|llvm/Module.h|llvm/IR/Module.h|' \
    -e 's|llvm/LLVMContext.h|llvm/IR/LLVMContext.h|' \
    -e 's|llvm/Constants.h|llvm/IR/Constants.h|' \
    -e 's|llvm/DerivedTypes.h|llvm/IR/DerivedTypes.h|' \
    -e 's|llvm/Support/IRBuilder.h|llvm/IR/IRBuilder.h|' \
    -e 's|llvm/Target/TargetData.h|llvm/Transforms/Scalar/GVN.h|' \
    -i src/scripting/abc_codesynt.cpp

Alternatively could workaround using 'check_include_file_cxx' for older cmake versions, but that would be a lot of work and could be hard to upstream.

volkerdi · 09-14-2018, 12:58 PM

Quote:

Originally Posted by orbea

I realize that is likely, however this slippery slope was already started with llvm, rust and firefox. I think the correct solution is to either revert this whole mess or finish what was started and update cmake as well as resolve anything else that reveals itself afterwards...

Rust and LLVM were provided in case you wanted to compile Firefox or Thunderbird locally. The correct solution is to not install those otherwise.

55020 · 09-14-2018, 04:21 PM

You can just add these definitions to the cmake invocation in lightspark.SlackBuild

Code:

diff --git a/multimedia/lightspark/lightspark.SlackBuild b/multimedia/lightspark/lightspark.SlackBuild
index bb900c9321..d615ba7700 100644
--- a/multimedia/lightspark/lightspark.SlackBuild
+++ b/multimedia/lightspark/lightspark.SlackBuild
@@ -78,6 +78,9 @@ cd build
     -DMANUAL_DIRECTORY=man \
     -DLIB_SUFFIX=${LIBDIRSUFFIX} \
     -DGNASH_EXE_PATH=/usr/bin/gtk-gnash \
+    -DHAVE_IR_DATALAYOUT_H=TRUE \
+    -DHAVE_IR_VERIFIER_H=TRUE \
+    -DHAVE_TRANSFORMS_SCALAR_GVN_H=TRUE \
     -Wno-dev \
     -DCMAKE_BUILD_TYPE=Release ..
   make

orbea · 09-14-2018, 06:21 PM

Quote:

Originally Posted by volkerdi

Rust and LLVM were provided in case you wanted to compile Firefox or Thunderbird locally. The correct solution is to not install those otherwise.

That sounds fine to me, but these updates are in patches and people can update them with slackpkg without fully appreciating the consequences. Maybe it would be better if they were in extra instead? Or am I not understanding something?

Quote:

Originally Posted by 55020

You can just add these definitions to the cmake invocation in lightspark.SlackBuild

Code:

diff --git a/multimedia/lightspark/lightspark.SlackBuild b/multimedia/lightspark/lightspark.SlackBuild
index bb900c9321..d615ba7700 100644
--- a/multimedia/lightspark/lightspark.SlackBuild
+++ b/multimedia/lightspark/lightspark.SlackBuild
@@ -78,6 +78,9 @@ cd build
     -DMANUAL_DIRECTORY=man \
     -DLIB_SUFFIX=${LIBDIRSUFFIX} \
     -DGNASH_EXE_PATH=/usr/bin/gtk-gnash \
+    -DHAVE_IR_DATALAYOUT_H=TRUE \
+    -DHAVE_IR_VERIFIER_H=TRUE \
+    -DHAVE_TRANSFORMS_SCALAR_GVN_H=TRUE \
     -Wno-dev \
     -DCMAKE_BUILD_TYPE=Release ..
   make

Thanks, I didn't realize I could do that, but its still a bit of a hack...

volkerdi · 09-14-2018, 10:58 PM

Quote:

Originally Posted by orbea

That sounds fine to me, but these updates are in patches and people can update them with slackpkg without fully appreciating the consequences. Maybe it would be better if they were in extra instead? Or am I not understanding something?

I considered the fact that there had been no previous updates in /patches to either of these, so reverting is still possible.

orbea · 09-16-2018, 09:05 AM

That makes sense, however SBo explicitly supports the latest patched version of Slackware stable so this is still somewhat disruptive.

allend · 09-16-2018, 10:00 AM

I would prefer that -stable 14.2 is not hacked to provide a fix for "an open source Flash player implementation". There are people who rely on -stable for production systems. Security based updates are expected, but changing the build chain to address a failure in support for a third party package is a bridge too far. It is much better to just hack the SlackBuild script.
I accept that 14.2 is halfway to EOL and that -stable is in need of renewal, but I have not seen a sweet spot that would have allowed this to occur.

orbea · 09-16-2018, 10:46 AM

Quote:

Originally Posted by allend

There are people who rely on -stable for production systems. Security based updates are expected, but changing the build chain to address a failure in support for a third party package is a bridge too far. It is much better to just hack the SlackBuild script.

I agree with this, but the problem is the build chain was already changed with llvm and now a previously unexposed cmake bug is now exposed. This was the whole point of making this thread, if this was just a lightspark bug I would of fixed it in lightspark or worked around it the slackbuild.

I'm certainly fine with the solution of just not installing the newer llvm, but since its in patches I am not sure that will fly with SBo.

55020 · 09-16-2018, 01:58 PM

Telling lightspark where the includes are, using the config variables provided by lightspark for the exact purpose of telling lightspark where the includes are, is pretty damn innocuous IMO. Maybe it could use a bit of if-then-elseness in case someone's still got the old llvm, but basically we're done.

Out of 7254 SlackBuilds on SBo, lightspark is the only one that's got b0rkenated by the new-llvm + old-cmake combo. I know cos I've checked. We don't, at this time, need a more general solution.

orbea · 09-17-2018, 08:56 AM

Did any other packages break from llvm at all? I suppose its possible that even if they did not break during compile time they may of broken more subtly during runtime.

That said the current lightspark upstream maintainer proposed the best solution, apparently the llvm parser does not actually work and he is not knowledgeable enough about llvm to fix it besides making sure it compiles. So he said he plans to make llvm an optional compile time dependency and default it to off in case someone wants to fix it in the future. When this is ready I plan to either backport it or update to a git snapshot again...