Hello everyone - It has been a couple of months. With the release of version 5.3.12 I dug into this problem in greater depth. Net result - I can get Therion to compile but Loch is still no-go. Details below. I don't use Loch, so not having it is not a problem for me. The target system is Fedora 20, 64-bit. I installed it as a clean, fresh system. It is not an upgrade. One thing I found with Fedora 20 is that vtk-devel cannot be installed. When I try to "yum install vtk-devel" I get a raft of errors that ends like this: --> Processing Conflict: community-mysql-5.5.34-1.fc20.x86_64 conflicts --> mariadb --> Processing Conflict: 1:mariadb-5.5.34-2.fc20.x86_64 conflicts --> community-mysql --> Finished Dependency Resolution Error: mariadb conflicts with community-mysql-5.5.34-1.fc20.x86_64 Error: community-mysql conflicts with 1:mariadb-5.5.34-2.fc20.x86_64 There is also a long list of dependencies that includes PostGreSQL and what looks like 50 or 60 Python and TCL libraries. It's a mess!!! Here is what I changed to make Therion compile. 1) In file "makeinstall.tcl" ... Comment out line 55. 2) In file "Makefile" ... Change line 122 to read all: therion doc xtherion/xtherion 3) In file "Makefile" ... Comment out lines 30, 173, 174, 190, 229, 233, 237, 241, 245, 249 The next thing I will do is try this on some systems that are upgraded from Fedora 19 to 20. Regards - Bill Gee On Thursday, October 17, 2013 17:21:43 Wookey wrote:
+++ Bill Gee [2013-10-08 19:42 -0500]:
Hi Wookey -
It is kind of a strange situation for me. I earn a good living as a software packager for Windows applications. I can turn MSI files inside-out. But RPMs?? I have no clue where to even start!
Right well, maybe you can help with the windows packaging (although we do it using Linux tools).
Of course, if I were to take on RPM packaging, I still have to get Therion to compile.
Fedora 17 is over a year old. They are up to 19, and I expect to see 20 before the end of the year. Still, it's not THAT old.
On that subject - Fedora package names are quite different from Debian.
Yes, that's often the case. There is a different set of conventions.
I ran some queries on my system to see what is installed. Here is what it shows. I think this covers everything you mentioned. ================
[bgee@main2 ~]$ rpm -qa | grep -i wx wxGTK-devel-2.8.12-4.fc17.x86_64 wxPython-2.8.12.0-2.fc17.x86_64 wxBase-2.8.12-4.fc17.x86_64 wxGTK-2.8.12-4.fc17.x86_64 wxGTK-media-2.8.12-4.fc17.x86_64 wxGTK-gl-2.8.12-4.fc17.x86_64 [bgee@main2 ~]$ rpm -qa | grep -i mesa mesa-libGL-devel-8.0.4-1.fc17.x86_64 mesa-libOSMesa-devel-8.0.4-1.fc17.x86_64 mesa-libglapi-8.0.4-1.fc17.x86_64 mesa-libxatracker-8.0.4-1.fc17.x86_64 mesa-libOSMesa-8.0.4-1.fc17.x86_64 mesa-dri-filesystem-8.0.4-1.fc17.x86_64 mesa-libGLU-8.0.4-1.fc17.x86_64 mesa-dri-drivers-8.0.4-1.fc17.x86_64 mesa-libgbm-8.0.4-1.fc17.x86_64 mesa-libEGL-8.0.4-1.fc17.x86_64 mesa-libGLU-devel-8.0.4-1.fc17.x86_64 mesa-libGLES-8.0.4-1.fc17.x86_64 mesa-libGL-8.0.4-1.fc17.x86_64 [bgee@main2 ~]$ rpm -qa | grep -i freetype freetype-2.4.8-4.fc17.x86_64 freetype-2.4.8-4.fc17.i686 freetype-devel-2.4.8-4.fc17.x86_64 [bgee@main2 ~]$ rpm -qa | grep -i vtk vtk-tcl-5.8.0-6.fc17.x86_64 vtk-5.8.0-6.fc17.x86_64 vtk-python-5.8.0-6.fc17.x86_64 vtk-devel-5.8.0-6.fc17.x86_64 vtk-qt-5.8.0-6.fc17.x86_64 vtk-java-5.8.0-6.fc17.x86_64 [bgee@main2 ~]$
=====================
I assume xTherion needs vtk
No. Loch needs vtk and wx
xtherion needs tcl and tk
.... If vtk were the problem, then I would expect
the Therion compiles to fail too. It runs through xTherion without error. It only fails when it gets to Loch.
Exactly. Look at the difference between the top-level Makefile and the loch/Makefile.
You can see a working (debian) build-log here, which might help: https://buildd.debian.org/status/fetch.php?pkg=therion&arch=i386&ver=5.3.11-> 2&stamp=1381462995
Wookey