Hello Martin and everyone ...

This version of therion still fails to compile loch on my Fedora 21 system. At the end of the loch compile it issues these messages:

==================== c++ -o ./loch -Wall ./lxR2P.o ./lxTR.o ./lxOGLFT.o ./lxSetup.o ./lxRender.o ./lxWX.o ./lxImgIO.o ./lxLRUD.o ./lxFile.o ./lxSTree.o ./lxData.o ./lxMath.o ./lxSView.o ./lxSScene.o ./lxGUI.o ./lxGLC.o ./lxOptDlg.o ./lxAboutDlg.o ./lxPres.o ./img.o -lwx_gtk2u_gl-2.8 -pthread -Wl,-z,relro - lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 -L/usr/lib64/vtk - lvtkCommonExecutionModel-6.1 -lvtkCommonDataModel-6.1 -lvtkCommonCore-6.1

Update - Solved! I finally got Loch to compile. The change is in the Loch Makefile, highlighted below in red. With this final change the entire Therion package will compile. ================== # PLATFORM LINUX CXX = c++ CC = gcc POBJECTS = lxR2P.o #ifeq ($(VTKV6),1) #VTKLIBS = -lvtkCommonExecutionModel-$(VTKVERSION) - lvtkCommonDataModel-$(VTKVERSION) -lvtkCommonCore-$(VTKVERSION) - lvtkFiltersCore-$(VTKVERSION) -lvtkFiltersHybrid-$(VTKVERSION) - lvtkIOLegacy-$(VTKVERSION) -lfreetype -lpng -ljpeg #else #VTKLIBS = -lvtkHybrid -lvtkImaging -lvtkIO -lvtkGraphics -lvtkFiltering -lvtkCommon - lfreetype #endif VTKLIBS = -lvtkCommonExecutionModel -lvtkCommonDataModel -lvtkCommonCore - lvtkFiltersCore -lvtkFiltersHybrid -lvtkIOLegacy -lfreetype -lpng -ljpeg CXXPFLAGS = -DLXLINUX $(shell wx-config --cxxflags) -Wno-deprecated $(shell freetype-config --cflags) -I$(VTKPATH) CCPFLAGS = -DLXLINUX $(shell wx-config --cflags) LXLIBDIR = linux PLIBS = $(shell wx-config --libs --gl-libs) -L$(VTKLIBPATH) $(VTKLIBS) -lGLU -lGL - lpthread -lX11 -lz LXPLATFORM = LINUX ============ Bill Gee On Sunday, December 28, 2014 14:33:53 Bill Gee wrote: -

lvtkFiltersCore-6.1 -lvtkFiltersHybrid-6.1 -lvtkIOLegacy-6.1 -lfreetype -lpng -ljpeg -lGLU -lGL -lpthread -lX11 -lz -s /usr/bin/ld: cannot find -lvtkCommonExecutionModel-6.1 /usr/bin/ld: cannot find -lvtkCommonDataModel-6.1 /usr/bin/ld: cannot find -lvtkCommonCore-6.1 /usr/bin/ld: cannot find -lvtkFiltersCore-6.1 /usr/bin/ld: cannot find -lvtkFiltersHybrid-6.1 /usr/bin/ld: cannot find -lvtkIOLegacy-6.1 collect2: error: ld returned 1 exit status Makefile:145: recipe for target 'loch' failed make: *** [loch] Error 1 ===============

My system does not contain any of the files that ld cannot find.

I got this far by making some changes to the loch Makefile. Here is the relevant section:

================= #VTKVERSION = $(shell tclsh ./getvtkver.tcl version) VTKVERSION=6.1 # VTKPATH = $(shell tclsh ./getvtkver.tcl incpath) # VTKLIBPATH = $(shell tclsh ./getvtkver.tcl libpath) VTKV6 = $(shell tclsh ./getvtkver.tcl version6) #ifeq ($(VTKV6),1) #VTKLIBS = -lvtkCommonExecutionModel-$(VTKVERSION) - lvtkCommonDataModel-$(VTKVERSION) -lvtkCommonCore-$(VTKVERSION) - lvtkFiltersCore-$(VTKVERSION) -lvtkFiltersHybrid-$(VTKVERSION) - lvtkIOLegacy-$(VTKVERSION) -lfreetype -lpng -ljpeg #else #VTKLIBS = -lvtkHybrid -lvtkImaging -lvtkIO -lvtkGraphics -lvtkFiltering - lvtkCommon -lvtkjpeg -lvtkpng -lvtkzlib -lvtksys -lfreetype #endif # VTKVERSION = 5.4 VTKPATH = /usr/include/vtk VTKLIBPATH = /usr/lib64/vtk POSTMAKE = STRIPFLAG = -s

# PLATFORM CONFIG

# PLATFORM LINUX CXX = c++ CC = gcc POBJECTS = lxR2P.o #ifeq ($(VTKV6),1) VTKLIBS = -lvtkCommonExecutionModel-$(VTKVERSION) - lvtkCommonDataModel-$(VTKVERSION) -lvtkCommonCore-$(VTKVERSION) - lvtkFiltersCore-$(VTKVERSION) -lvtkFiltersHybrid-$(VTKVERSION) - lvtkIOLegacy-$(VTKVERSION) -lfreetype -lpng -ljpeg #else #VTKLIBS = -lvtkHybrid -lvtkImaging -lvtkIO -lvtkGraphics -lvtkFiltering - lvtkCommon -lfreetype #endif CXXPFLAGS = -DLXLINUX $(shell wx-config --cxxflags) -Wno-deprecated $(shell freetype-config --cflags) -I$(VTKPATH) =====================

gettkver.tcl returns 0 even though the installed version of vtk is 6.1.

I forced the setting for both VTKPATH and VTKLIBPATH, and I removed the 'IF' statement around the setting of VTKLIBS. I tried using both of the VTKLIBS settings, but neither of them work.

I know very little about ld. It appears to me that the Fedora installation of vtk is using different filenames for the shared object libraries. The libraries names in the Makefile do not match up with what is actually on my system.

I attached a text file to this message showing 'ls -l' from the vtk shared objects directory. If someone can tell me which of these libraries are actually needed, I will try setting the VTKLIBS variable to use them.

Final note - For me this is not critical. I can easily set up the main therion Makefile so it bypasses loch entirely. I have never used loch. Therion compiles correctly - it is only loch that fails.

Thanks - Bill Gee

On Sunday, December 28, 2014 19:56:48 Martin Budaj wrote:

...

Hi all,

Hi Wookey - Sorry about that! I don't use colors very often, but I sort of assume when I do that they will work for most people. The three changes I made were to directly set the values of VTKPATH, VTKLIBPATH and VTKLIBS. The other changes were simply commenting out the logic that attempts to set these variables by scanning the local system. Your comment about a "smarter" build system is interesting. One of the things I discovered while working on this problem is that cmake has a system for finding libraries, and the vtk package for Fedora includes the necessary files to implement this system. I generated a diff file and attached it to this message. Bill Gee On Monday, December 29, 2014 17:02:46 Wookey wrote:

+++ Bill Gee [2014-12-29 10:12 -0600]:

...

Update -

Solved! I finally got Loch to compile. The change is in the Loch Makefile, highlighted below in red. With this final change the entire Therion package will compile.

My email is still black-and-white text. A diff would have been rather more use :-) But I presume you are saying, replace:

...

#ifeq ($(VTKV6),1)

#VTKLIBS = -lvtkCommonExecutionModel-$(VTKVERSION) -lvtkCommonDataModel-$(VTKVERSION) -lvtkCommonCore-$(VTKVERSION) -lvtkFiltersCore-$(VTKVERSION) -lvtkFiltersHybrid-$(VTKVERSION) -lvtkIOLegacy-$(VTKVERSION) -lfreetype -lpng -ljpeg

#else

#VTKLIBS = -lvtkHybrid -lvtkImaging -lvtkIO -lvtkGraphics -lvtkFiltering -lvtkCommon -lfreetype

#endif

with:

...

VTKLIBS = -lvtkCommonExecutionModel -lvtkCommonDataModel -lvtkCommonCore -lvtkFiltersCore -lvtkFiltersHybrid -lvtkIOLegacy -lfreetype -lpng -ljpeg

?

Thanks for the info. Seems that debian-based and fedora-based distros have used a different library-naming scheme.

Obviously a smarter patch would be needed to let it build on debian _and_ fedora based systems.

Mostly what all this shows is that therion could really use a proper build system like cmake, as then it could just use pkgconfig or built-in cmake findpackage runes which should deal with distro packaging variation like this.

Wookey

On 12/28/2014 04:23 PM, Wookey wrote:

+++ Martin Budaj [2014-12-28 19:56 +0100]:

...

Hi all,

new therion version is available. It's mostly a bug fixing release; see below for details. Most of the contributed patches were also applied or adapted (thanks, Olly & Wookey).

As suggested by Wookey, we intend to use some public VCS for development,

Good - I think that will help development.

...

presumably Github. We'll let you know when the repository is ready.

It would be better to use a free software webVCS front-end, like gitorious, or alioth (if you want to use an existing site), not the proprietary github. This being a free software project and all.

Is there a good reason why you don't want to put git on the existing therion server, and keep all the project parts under our own control? That's a bitmore faff, but sound practice.

While I understand your concerns, I'd rather the therion devs focus on devleoping therion and not have to manage the infrastructure also. That said, there is nothing stopping you from maintaining a free software based mirror :) Philip

There is a pile of software for doing this, depending how fancy you want. gitlab, gitorious, trac etc.

Wookey

+++ Stacho Mudrak [2014-12-30 11:09 +0100]:

* 82-nolang-segfault-fix.patch  (this avoids a genuine error case of language not being defined)

I believe, this error is already fixed. Are you able to reproduce it with current version of therion?

I can't remember what the issue was or how to reproduce it. Anyone remember? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/

+++ Olly Betts [2015-01-07 20:29 +0000]:

On Wed, Jan 07, 2015 at 09:11:06AM +0000, Wookey wrote:

...

+++ Stacho Mudrak [2014-12-30 11:09 +0100]:

...

* 82-nolang-segfault-fix.patch  (this avoids a genuine error case of language not being defined)

I believe, this error is already fixed. Are you able to reproduce it with current version of therion?

I can't remember what the issue was or how to reproduce it. Anyone remember?

No, but thlang_getid() now starts with an explicit check to handle the case where the id is -1, so the patch is clearly no longer needed:

const char * thlang_getid(int id) { if (id < 0) { return "en"; }

The important conclusion is that it clearly isn't useful for 5.3.16.

Agreed. That's good enough for me. therion 5.3.16-4 uploaded just now with the offending patch removed. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/