Therion fails to compile with vtk 6
Hello everyone - This is not a big deal to me because 1) I know how to get around it and 2) I don't use Loch anyway. However, for those to DO care, I thought I would post some information. The final few lines of the compile run are listed below. This is from 64-bit Fedora 21 and Therion 5.3.15. VTK version 6.1.0-18.fc21 is installed using the RPM packages from the main Fedora repository. I had to link the existing vtk directory to the location where Therion's make file expected it. ln -s /usr/include/vtk /usr/local/include/vtk-5.4 Without the link it fails much earlier in the loch compile. Based on this it appears to me that major changes have been made between vtk 5 and 6. Eventually I am sure other people will run into this problem. The workaround is to modify makefile so that it never attempts to compile loch. There is also a change to makeinstall.tcl. Bill Gee ================ lxData.cxx:543:28: error: ‘class vtkPolyDataNormals’ has no member named ‘SetInput’ this->scrapWallsNormals->SetInput(this->scrapWalls); ^ lxData.cxx:550:19: error: ‘class vtkAppendPolyData’ has no member named ‘AddInput’ this->allWalls->AddInput(this->scrapWallsNormals->GetOutput()); ^ lxData.cxx:551:19: error: ‘class vtkAppendPolyData’ has no member named ‘AddInput’ this->allWalls->AddInput(this->lrudWalls); ^ lxData.cxx:553:27: error: ‘class vtkTriangleFilter’ has no member named ‘SetInput’ this->allWallsTriangle->SetInput(this->allWalls->GetOutput()); ^ lxData.cxx:554:25: error: ‘class vtkDepthSortPolyData’ has no member named ‘SetInput’ this->allWallsSorted->SetInput(this->allWallsTriangle->GetOutput()); ^ lxData.cxx:556:27: error: ‘class vtkStripper’ has no member named ‘SetInput’ this->allWallsStripped->SetInput(this->allWallsTriangle->GetOutput()); ^ lxData.cxx:559:24: error: ‘class vtkPolyDataNormals’ has no member named ‘SetInput’ this->surfaceNormals->SetInput(this->surface); ^ lxData.cxx:562:26: error: ‘class vtkTriangleFilter’ has no member named ‘SetInput’ this->surfaceTriangle->SetInput(this->surfaceNormals->GetOutput()); ^ lxData.cxx:563:24: error: ‘class vtkDepthSortPolyData’ has no member named ‘SetInput’ this->surfaceSorted->SetInput(this->surfaceTriangle->GetOutput()); ^ lxData.cxx: In member function ‘void lxData::ExportVTK(wxString)’: lxData.cxx:585:6: error: ‘class vtkPolyDataWriter’ has no member named ‘SetInput’ w->SetInput(this->allWallsStripped->GetOutput()); ^ Makefile:110: recipe for target '.././loch/lxData.o' failed make[1]: *** [.././loch/lxData.o] Error 1 make[1]: Leaving directory '/home/bgee/Installs/therion/loch' Makefile:182: recipe for target 'loch/loch' failed make: *** [loch/loch] Error 2 ==================
On Thu, Dec 11, 2014 at 12:42:24PM -0600, Bill Gee wrote:
Based on this it appears to me that major changes have been made between vtk 5 and 6. Eventually I am sure other people will run into this problem.
I already fixed this for the Debian package - you can find a patch here: http://sources.debian.net/src/therion/5.3.15-2/debian/patches/vtk6.patch/ It would be great if more of the patches we're carrying in Debian got merged so that others didn't hit these same problems and have to try to fix them again for themselves: http://sources.debian.net/src/therion/5.3.15-2/debian/patches/ If there's anything Wookey or I can do to help get them merged, please say. Cheers, Olly
+++ Olly Betts [2014-12-11 19:57 +0000]:
On Thu, Dec 11, 2014 at 12:42:24PM -0600, Bill Gee wrote:
It would be great if more of the patches we're carrying in Debian got merged so that others didn't hit these same problems and have to try to fix them again for themselves:
A fedora therion maintainer would also help, although not as much as upstreaming.
http://sources.debian.net/src/therion/5.3.15-2/debian/patches/
If there's anything Wookey or I can do to help get them merged, please say.
Indeed. I'm keen to upstream everything that is upstreamble, and reduce our patch-pile. Stacho - are you still so firewalled at work that you can't access a VCS and thus are not keen to have an 'official' one? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Hi Olly - Thanks for the reply. I downloaded the patch file vtk6.patch and tried to apply it to the Therion 5.3.15 source tree. It looks like the first part worked but not the second. Here is the output from patch: =============== [bgee@main2 therion]$ patch -p1 -i vtk6.patch patching file loch/lxData.cxx Hunk #1 succeeded at 540 (offset 5 lines). Hunk #2 succeeded at 582 (offset 5 lines). patching file loch/Makefile Hunk #1 FAILED at 37. 1 out of 1 hunk FAILED -- saving rejects to file loch/Makefile.rej [bgee@main2 therion]$ ================== If I try to compile this, it goes further than before but still fails while processing loch. It appears to still be looking for vtk libraries in the vtk-5.4 directory. Regards - Bill Gee On Thursday, December 11, 2014 19:57:00 Olly Betts wrote:
On Thu, Dec 11, 2014 at 12:42:24PM -0600, Bill Gee wrote:
Based on this it appears to me that major changes have been made between vtk 5 and 6. Eventually I am sure other people will run into this problem.
I already fixed this for the Debian package - you can find a patch here:
http://sources.debian.net/src/therion/5.3.15-2/debian/patches/vtk6.patch/
It would be great if more of the patches we're carrying in Debian got merged so that others didn't hit these same problems and have to try to fix them again for themselves:
http://sources.debian.net/src/therion/5.3.15-2/debian/patches/
If there's anything Wookey or I can do to help get them merged, please say.
Cheers, Olly
On Sun, Dec 14, 2014 at 08:23:23PM -0600, Bill Gee wrote:
Thanks for the reply. I downloaded the patch file vtk6.patch and tried to apply it to the Therion 5.3.15 source tree. It looks like the first part worked but not the second. Here is the output from patch:
=============== [bgee@main2 therion]$ patch -p1 -i vtk6.patch patching file loch/lxData.cxx Hunk #1 succeeded at 540 (offset 5 lines). Hunk #2 succeeded at 582 (offset 5 lines). patching file loch/Makefile Hunk #1 FAILED at 37. 1 out of 1 hunk FAILED -- saving rejects to file loch/Makefile.rej [bgee@main2 therion]$ ==================
If I try to compile this, it goes further than before but still fails while processing loch. It appears to still be looking for vtk libraries in the vtk-5.4 directory.
That's probably just a consequence of the changes to loch/Makefile not getting applied (since that's where those libraries are specified), which is probably because some earlier patch in the huge pile we're now carrying also changed that area of that file. If you look at loch/Makefile.rej, you can probably make the required changes to loch/Makefile by hand. Alternatively, applying all the patches in the order given in the series file should work - you can get quilt to do that with: QUILT_PATCHES=/path/to/debian/patches quilt push -a Cheers, Olly
Hi Olly - That sounds a bit like the roads around here! They are well known for having a patch on top of a patch on top of a patch. I took a stab at changing the loch Makefile manually. It still fails, but now it has yet another message. Here is the last few bits from the compile run. ================== gcc -c -Wall -D_GNU_SOURCE -DLOCH -DLXLINUX -I/usr/lib64/wx/include/gtk2- unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 - D_LARGE_FILES -D__WXGTK__ -pthread -o .././loch/img.o img.c c++ -o .././loch/loch -Wall .././loch/lxR2P.o .././loch/lxTR.o .././loch/lxOGLFT.o .././loch/lxSetup.o .././loch/lxRender.o .././loch/lxWX.o .././loch/lxImgIO.o .././loch/lxLRUD.o .././loch/lxFile.o .././loch/lxSTree.o .././loch/lxData.o .././loch/lxMath.o .././loch/lxSView.o .././loch/lxSScene.o .././loch/lxGUI.o .././loch/lxGLC.o .././loch/lxOptDlg.o .././loch/lxAboutDlg.o .././loch/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/lib/vtk-5.4 - lvtkCommonExecutionModel-6.1 -lvtkCommonDataModel-6.1 -lvtkCommonCore-6.1 - lvtkFiltersCore-6.1 -lvtkFiltersHybrid-6.1 -lvtkIOLegacy-6.1 -lfreetype -lGLU -lpthread -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 make[1]: *** [.././loch/loch] Error 1 make[1]: Leaving directory `/home/bgee/Installs/therion/loch' make: *** [loch/loch] Error 2 ====================== I noticed a section at the top of the Loch Makefile where it is using some tcl programs to find where vtk is installed. This starts on line 14. On my systems the three tcl programs return data as if vtk 5.4 were installed. The system has no trace of vtk 5.4 left on it. The two directories returned for VTKPATH and VTKLIBPATH do not exist. Will this cause any problems? Thanks - Bill Gee On Monday, December 15, 2014 22:14:30 Olly Betts wrote:
On Sun, Dec 14, 2014 at 08:23:23PM -0600, Bill Gee wrote:
Thanks for the reply. I downloaded the patch file vtk6.patch and tried to apply it to the Therion 5.3.15 source tree. It looks like the first part worked but not the second. Here is the output from patch:
=============== [bgee@main2 therion]$ patch -p1 -i vtk6.patch patching file loch/lxData.cxx Hunk #1 succeeded at 540 (offset 5 lines). Hunk #2 succeeded at 582 (offset 5 lines). patching file loch/Makefile Hunk #1 FAILED at 37. 1 out of 1 hunk FAILED -- saving rejects to file loch/Makefile.rej [bgee@main2 therion]$ ==================
If I try to compile this, it goes further than before but still fails while processing loch. It appears to still be looking for vtk libraries in the vtk-5.4 directory.
That's probably just a consequence of the changes to loch/Makefile not getting applied (since that's where those libraries are specified), which is probably because some earlier patch in the huge pile we're now carrying also changed that area of that file.
If you look at loch/Makefile.rej, you can probably make the required changes to loch/Makefile by hand.
Alternatively, applying all the patches in the order given in the series file should work - you can get quilt to do that with:
QUILT_PATCHES=/path/to/debian/patches quilt push -a
Cheers, Olly
On Mon, Dec 15, 2014 at 07:32:53PM -0600, Bill Gee wrote:
I took a stab at changing the loch Makefile manually. It still fails, but now it has yet another message. Here is the last few bits from the compile run.
==================/usr/lib64/ gcc -c -Wall -D_GNU_SOURCE -DLOCH -DLXLINUX -I/usr/lib64/wx/include/gtk2- unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 - D_LARGE_FILES -D__WXGTK__ -pthread -o .././loch/img.o img.c c++ -o .././loch/loch -Wall .././loch/lxR2P.o .././loch/lxTR.o .././loch/lxOGLFT.o .././loch/lxSetup.o .././loch/lxRender.o .././loch/lxWX.o .././loch/lxImgIO.o .././loch/lxLRUD.o .././loch/lxFile.o .././loch/lxSTree.o .././loch/lxData.o .././loch/lxMath.o .././loch/lxSView.o .././loch/lxSScene.o .././loch/lxGUI.o .././loch/lxGLC.o .././loch/lxOptDlg.o .././loch/lxAboutDlg.o .././loch/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/lib/vtk-5.4 - lvtkCommonExecutionModel-6.1 -lvtkCommonDataModel-6.1 -lvtkCommonCore-6.1 - lvtkFiltersCore-6.1 -lvtkFiltersHybrid-6.1 -lvtkIOLegacy-6.1 -lfreetype -lGLU -lpthread -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 make[1]: *** [.././loch/loch] Error 1 make[1]: Leaving directory `/home/bgee/Installs/therion/loch' make: *** [loch/loch] Error 2 ======================
I noticed a section at the top of the Loch Makefile where it is using some tcl programs to find where vtk is installed. This starts on line 14. On my systems the three tcl programs return data as if vtk 5.4 were installed. The system has no trace of vtk 5.4 left on it. The two directories returned for VTKPATH and VTKLIBPATH do not exist. Will this cause any problems?
Looking at getvtkver.tcl it assumes 5.4 if it can't find a vtk install, so I suspect that's what is happening for you. On Debian unstable, VTKPATH is /usr/include/vtk-6.1 (correct) but VTKLIBPATH is /usr/lib/vtk-6.1 (wrong). But the latter doesn't matter, as the libraries are in /usr/lib/x86_64-linux-gnu which is on the default linker search path, so are found anyway. It looks like your build finds the headers (so VTKPATH isn't a problem) but fails to find the libraries when it comes to link. If you can determine the correct directory, you can probably override by passing it on the command line, like so: make VTKLIBPATH=/usr/lib64/vtk6.1 Cheers, Olly
Hi Olly - I finally got some time today to spend on this. It is still not working, but the needle has been moved! Once again I get a different error. I think progress is being made ... On my Fedora 21 system vtk is version 6.1.0. It is installed in /usr/lib64/vtk and /usr/include/vtk. When I ran make with these two paths specified on the command line, I got the same result as below. Six libraries with names ending in "-6.1" could not be found. I modified the loch Makefile as shown here. I used hard-coded pathnames for VTKPATH and VTKLIBPATH. I also remove "-6.1" from the library names in the VTKLIBS line. ============= # VTKVERSION = 5.4 VTKVERSION = $(shell tclsh ./getvtkver.tcl version) # VTKPATH = /usr/local/include/vtk-$(VTKVERSION) # VTKPATH = $(shell tclsh ./getvtkver.tcl incpath) VTKPATH = /usr/include/vtk # VTKLIBPATH = /usr/local/lib/vtk-$(VTKVERSION) # VTKLIBPATH = $(shell tclsh ./getvtkver.tcl libpath) VTKLIBPATH = /usr/lib64/vtk VTKLIBS = -lvtkHybrid -lvtkImaging -lvtkIO -lvtkGraphics -lvtkFiltering - lvtkCommon -lvtkjpeg -lvtkpng -lvtkzlib -lvtksys -lfreetype POSTMAKE = STRIPFLAG = -s [... snip ...] # PLATFORM DEBIAN CXX = c++ CC = gcc POBJECTS = lxR2P.o ## VTKLIBS = -lvtkHybrid -lvtkImaging -lvtkIO -lvtkGraphics -lvtkFiltering - lvtkCommon -lfreetype VTKLIBS = -lvtkCommonExecutionModel -lvtkCommonDataModel -lvtkCommonCore - lvtkFiltersCore -lvtkFiltersHybrid -lvtkIOLegacy -lfreetype ## CXXPFLAGS = -DLXLINUX $(shell wx-config --cxxflags) -Wno-deprecated $(shell freetype-config --cflags) -I$(VTKPATH) CXXPFLAGS = -DLXLINUX $(shell wx-config --cxxflags) $(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 - lpthread -lz LXPLATFORM = LINUX ==================== This runs almost all the way through. At the end it complains about an undefined symbol reference. Here are the last few lines of output: ==================== gcc -c -Wall -D_GNU_SOURCE -DLOCH -DLXLINUX -I/usr/lib64/wx/include/gtk2- unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 - D_LARGE_FILES -D__WXGTK__ -pthread -o .././loch/img.o img.c c++ -o .././loch/loch -Wall .././loch/lxR2P.o .././loch/lxTR.o .././loch/lxOGLFT.o .././loch/lxSetup.o .././loch/lxRender.o .././loch/lxWX.o .././loch/lxImgIO.o .././loch/lxLRUD.o .././loch/lxFile.o .././loch/lxSTree.o .././loch/lxData.o .././loch/lxMath.o .././loch/lxSView.o .././loch/lxSScene.o .././loch/lxGUI.o .././loch/lxGLC.o .././loch/lxOptDlg.o .././loch/lxAboutDlg.o .././loch/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 -lvtkCommonDataModel -lvtkCommonCore -lvtkFiltersCore -lvtkFiltersHybrid -lvtkIOLegacy -lfreetype -lGLU -lpthread -lz -s /usr/bin/ld: .././loch/lxRender.o: undefined reference to symbol 'png_write_row@@PNG16_0' /lib64/libpng16.so.16: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Makefile:129: recipe for target '.././loch/loch' failed make: *** [.././loch/loch] Error 1 ===================== This looks to me like vtk is no longer a problem. Now it is something to do with libpng16. Regards - Bill Gee On Tuesday, December 16, 2014 03:15:37 Olly Betts wrote:
On Mon, Dec 15, 2014 at 07:32:53PM -0600, Bill Gee wrote:
I took a stab at changing the loch Makefile manually. It still fails, but now it has yet another message. Here is the last few bits from the compile run.
==================/usr/lib64/ gcc -c -Wall -D_GNU_SOURCE -DLOCH -DLXLINUX -I/usr/lib64/wx/include/gtk2- unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 - D_LARGE_FILES -D__WXGTK__ -pthread -o .././loch/img.o img.c c++ -o .././loch/loch -Wall .././loch/lxR2P.o .././loch/lxTR.o .././loch/lxOGLFT.o .././loch/lxSetup.o .././loch/lxRender.o .././loch/lxWX.o .././loch/lxImgIO.o .././loch/lxLRUD.o .././loch/lxFile.o .././loch/lxSTree.o .././loch/lxData.o .././loch/lxMath.o .././loch/lxSView.o .././loch/lxSScene.o .././loch/lxGUI.o .././loch/lxGLC.o .././loch/lxOptDlg.o .././loch/lxAboutDlg.o .././loch/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/lib/vtk-5.4 - lvtkCommonExecutionModel-6.1 -lvtkCommonDataModel-6.1 -lvtkCommonCore-6.1 - lvtkFiltersCore-6.1 -lvtkFiltersHybrid-6.1 -lvtkIOLegacy-6.1 -lfreetype -lGLU -lpthread -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 make[1]: *** [.././loch/loch] Error 1 make[1]: Leaving directory `/home/bgee/Installs/therion/loch' make: *** [loch/loch] Error 2 ======================
I noticed a section at the top of the Loch Makefile where it is using some tcl programs to find where vtk is installed. This starts on line 14. On my systems the three tcl programs return data as if vtk 5.4 were installed. The system has no trace of vtk 5.4 left on it. The two directories returned for VTKPATH and VTKLIBPATH do not exist. Will this cause any problems? Looking at getvtkver.tcl it assumes 5.4 if it can't find a vtk install, so I suspect that's what is happening for you.
On Debian unstable, VTKPATH is /usr/include/vtk-6.1 (correct) but VTKLIBPATH is /usr/lib/vtk-6.1 (wrong). But the latter doesn't matter, as the libraries are in /usr/lib/x86_64-linux-gnu which is on the default linker search path, so are found anyway.
It looks like your build finds the headers (so VTKPATH isn't a problem) but fails to find the libraries when it comes to link. If you can determine the correct directory, you can probably override by passing it on the command line, like so:
make VTKLIBPATH=/usr/lib64/vtk6.1
Cheers, Olly
+++ Bill Gee [2014-12-18 11:02 -0600]:
Hi Olly -
I finally got some time today to spend on this. It is still not working, but the needle has been moved! Once again I get a different error. I think progress is being made ...
On my Fedora 21 system vtk is version 6.1.0. It is installed in /usr/lib64/vtk and /usr/include/vtk.
/lib64 was such a bad idea! But too late to fix now I suspect.
When I ran make with these two paths specified on the command line, I got the same result as below. Six libraries with names ending in "-6.1" could not be found.
That'll be debian packaging vtk so that 5.8 and 6.1 can be co-installed, but I guess fedora has just the one version, so no versionning in the library names.
I modified the loch Makefile as shown here. I used hard-coded pathnames for VTKPATH and VTKLIBPATH. I also remove "-6.1" from the library names in the VTKLIBS line.
# VTKPATH = $(shell tclsh ./getvtkver.tcl incpath)
we should probably try and fix this up so that it actually works on both debian- and fedora- type distros. Therion could really do with using cmake or something rather than handmade makefiles, tcl scripts, and perl scripts. That getvtkver is doing exactly the sort of thing that cmake does for you in a standard way
This runs almost all the way through. At the end it complains about an undefined symbol reference. Here are the last few lines of output:
==================== gcc -c -Wall -D_GNU_SOURCE -DLOCH -DLXLINUX -I/usr/lib64/wx/include/gtk2- unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 - D_LARGE_FILES -D__WXGTK__ -pthread -o .././loch/img.o img.c c++ -o .././loch/loch -Wall .././loch/lxR2P.o .././loch/lxTR.o .././loch/lxOGLFT.o .././loch/lxSetup.o .././loch/lxRender.o .././loch/lxWX.o .././loch/lxImgIO.o .././loch/lxLRUD.o .././loch/lxFile.o .././loch/lxSTree.o .././loch/lxData.o .././loch/lxMath.o .././loch/lxSView.o .././loch/lxSScene.o .././loch/lxGUI.o .././loch/lxGLC.o .././loch/lxOptDlg.o .././loch/lxAboutDlg.o .././loch/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 -lvtkCommonDataModel -lvtkCommonCore -lvtkFiltersCore -lvtkFiltersHybrid -lvtkIOLegacy -lfreetype -lGLU -lpthread -lz -s /usr/bin/ld: .././loch/lxRender.o: undefined reference to symbol 'png_write_row@@PNG16_0' /lib64/libpng16.so.16: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Makefile:129: recipe for target '.././loch/loch' failed make: *** [.././loch/loch] Error 1 =====================
This looks to me like vtk is no longer a problem. Now it is something to do with libpng16.
Right - you don't seem to have included libpng on the link command line. I think you just need -lpng in there. The error is telling you that the symbol you want ('png_write_row@@PNG16_0') is in the library /lib64/libpng16.so.16 (which is found), but as you didn't ask to link it, it can only complain. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
participants (3)
-
Bill Gee -
Olly Betts -
Wookey