Hello Andre, I've installed your patches, but still have the same build error:
./.libs/libVisuConvertor.so: undefined reference to `vtkIntArray* VISU::GetIDMapper<VISU::TGetPointData>(VISU::TFieldList*, VISU::TGetPointData, char const*)' collect2: ld returned 1 exit status It seems like if the problem were the missing -L...TOOLSGUI then there would have been a missing library instead of a missing symbol... But then, you were able to get it to build with these changes, so there must be something I don't understand going on here. I did install your patches in pieces, not all at once, so I may have missed something. Can you compare the tree currently in git with your own, to see if there are some significant differences which would cause it to not build? I hope we can get this working soon! -Adam On Thu, 2010-05-27 at 18:30 +0200, Andre Espaze wrote: > Hello Adam, > > I have just succeeded to make a 5.1.3-9 release with VISU, I have > enclosed the 2 patches. I also wanted to let you know that I have > understood the runtime problems of VISU but I need to progress > by steps (my solution is still too messy for being published). I will > first be glad if the -9 release works for you too. > > With a fresh sid version, I got a problem on /bin/sh now linked to dash > because autoconf publishes configure scripts with /bin/sh at top but > the KERNEL configure.ac script uses 'function' which is a bash command. > I could not find a solution yet (even by tweaking SHELL and > CONFIG_SHELL). > > Then I wonder if doing a: > chmod -x debian/tmp/usr/lib/python2.5/*-packages/salome/* > is a nice idea because you can not list directories any more. I got > this problem while debugging. I will try to provide a solution on that > point by listing required scripts. > > Best regards, > > André > > > On Mon, 2010-05-17 at 12:06 +0200, Andre Espaze wrote: > > > Hi Adam, > > > > > > Sorry for the lack of news, I was focus on making VISU work. I have > > > succeeded to build a Salome package however the current result is > > > unfortunately split from our development line. That's why I will first > > > explain my steps and then ask your advice on the merge as I saw that > > > serious reorganizations are also pending. > > > > > > My goal is to provide a functional Salome package for mechanical > > > engineering even if incomplete. As a consequence the necessary modules > > > are for me KERNEL, GUI, GEOM, MED, SMESH and VISU. As VISU was failing > > > in the build process of debian/rules, I decided to build it by hand by > > > exporting the necessary environment variables. In that case I only had > > > to modify the gui-build-in-tree.patch (attached to the mail) for making > > > the libVISU linking work by adding the path to libToolsGUI. > > > However, back to the complete debian/rules process, the compilation > > > was still failing in the VISU CONVERTER library because of an absent > > > template symbol (probably the same problem described in your mail on > > > the 25th of January). So I needed to investigate the configure and > > > build steps of debian/rules but those steps take lot of time. For > > > easing my researchs, I decided to work on a package building > > > only the necessary modules which I called salome-core. The working > > > snapshot is available here: > > > http://www.python-science.org/files/salome-core.tar.gz > > > and I have attached the resulting debian/rules which configure > > > every module separately. I could not find the problem in the > > > previous loop configuration. > > > > > > >From there two questions arise. First, I like the debian/rules file > > > of salome-core but I remember that you were against such solution for > > > maintenance reasons. Would you like me to adapt it as a loop or did you > > > finally change your mind? From now it seems anyway that VISU needs to be > > > configured separately. Second, could the current salome-core package be > > > a starting point for the reorganizations that we discussed previously? > > > For me it has the main advantage to build only the necessary modules, > > > thus saving time for every run of Salome packaging. However it will > > > require to write several packages (salome-advance and salome-dev). > > > By comparing to the opencascade package, I understand that the whole > > > building should be made in a row and the subpackages splitted by > > > several *.install files. > > > > > > ... > > > > > > > - self.CMD=['SALOME_ContainerPy.py','FactoryServerPy'] > > > + self.CMD=['SALOME_Container','FactoryServerPy'] > > > (I have adapted the patch to the current version.) > > > ... > > > > I just took care of this, the result is in the alioth git repository. > > > Thank you for the update. Even if the current version work, I would > > > prefer to rename 'SALOME_ContainerPy.py' to 'SALOME_ContainerPy' because > > > '/usr/bin/SALOME_Container' already exists and is finally overwritten in > > > the install step of debian/rules. > > > > > > Even if several points still need to be discussed or adapted, the > > > good point is that we know now how to build a Salome package with the > > > essential modules. Once again, thank you very much for all your efforts. > > > I am going to track the remaining bugs at runtime (some menu do not show > > > up in SMESH, the results can not be seen in VISU). > > > > > > All the best, > > > > > > André -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
