LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 09-14-2018, 09:25 AM   #1
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,325

Rep: Reputation: Disabled
Slackware 14.2 - llvm-6.0.1 / cmake regression.


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.
 
Old 09-14-2018, 09:37 AM   #2
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 4,381

Rep: Reputation: 2312Reputation: 2312Reputation: 2312Reputation: 2312Reputation: 2312Reputation: 2312Reputation: 2312Reputation: 2312Reputation: 2312Reputation: 2312Reputation: 2312
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...
 
Old 09-14-2018, 09:46 AM   #3
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,325

Original Poster
Rep: Reputation: Disabled
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...
 
Old 09-14-2018, 09:49 AM   #4
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 4,381

Rep: Reputation: 2312Reputation: 2312Reputation: 2312Reputation: 2312Reputation: 2312Reputation: 2312Reputation: 2312Reputation: 2312Reputation: 2312Reputation: 2312Reputation: 2312
...or, in alternative, patch lightspark.
 
Old 09-14-2018, 09:50 AM   #5
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,325

Original Poster
Rep: Reputation: Disabled
Lightspark is already fixed, this is a cmake bug.
 
Old 09-14-2018, 10:27 AM   #6
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,325

Original Poster
Rep: Reputation: Disabled
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.
 
Old 09-14-2018, 12:58 PM   #7
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,570

Rep: Reputation: 4752Reputation: 4752Reputation: 4752Reputation: 4752Reputation: 4752Reputation: 4752Reputation: 4752Reputation: 4752Reputation: 4752Reputation: 4752Reputation: 4752
Quote:
Originally Posted by orbea View Post
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.
 
Old 09-14-2018, 04:21 PM   #8
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,277
Blog Entries: 4

Rep: Reputation: Disabled
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
 
2 members found this post helpful.
Old 09-14-2018, 06:21 PM   #9
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,325

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by volkerdi View Post
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 View Post
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...

Last edited by orbea; 09-14-2018 at 06:22 PM.
 
Old 09-14-2018, 10:58 PM   #10
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,570

Rep: Reputation: 4752Reputation: 4752Reputation: 4752Reputation: 4752Reputation: 4752Reputation: 4752Reputation: 4752Reputation: 4752Reputation: 4752Reputation: 4752Reputation: 4752
Quote:
Originally Posted by orbea View Post
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.
 
1 members found this post helpful.
Old 09-16-2018, 09:05 AM   #11
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,325

Original Poster
Rep: Reputation: Disabled
That makes sense, however SBo explicitly supports the latest patched version of Slackware stable so this is still somewhat disruptive.
 
Old 09-16-2018, 10:00 AM   #12
allend
Senior Member
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 4,998

Rep: Reputation: 1742Reputation: 1742Reputation: 1742Reputation: 1742Reputation: 1742Reputation: 1742Reputation: 1742Reputation: 1742Reputation: 1742Reputation: 1742Reputation: 1742
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.
 
Old 09-16-2018, 10:46 AM   #13
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,325

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by allend View Post
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.
 
Old 09-16-2018, 01:58 PM   #14
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,277
Blog Entries: 4

Rep: Reputation: Disabled
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.
 
4 members found this post helpful.
Old 09-17-2018, 08:56 AM   #15
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,325

Original Poster
Rep: Reputation: Disabled
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...
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Slackware-current: Bash-completion regression orbea Slackware 2 04-05-2016 03:44 PM
Slackware-current: /usr/share/cmake and /usr/share/cmake-3.3 directories igor29768 Slackware 1 11-07-2015 12:37 AM
llvm-config problem in slackware64-current LLVM 3.2 package teeemcee Slackware 0 01-24-2013 02:44 PM
[SOLVED] GNU indent in Slackware has a regression with --blank-lines-after-declarations qunying Slackware 0 12-14-2012 08:45 AM
cmake: Using find_package(Boost) when FindBoost.cmake is not in the default location damien_d Programming 3 10-27-2010 03:40 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 11:43 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration