Hi Adam,
>
> 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 feel really sorry for the wrong patch that I sent you, the reason
is that I forgot to add the CXXFLAGS="-g" in the configure command, I was
building VISU without optimizations. I hope that I did not make you
loose too much time. Since my last successful build, I have looked
deeper into the problem and I found that g++ inline small template
function with -O2. Here I imitate the GetIDMapper definition found in
src/CONVERTOR/VISU_MergeFilterUtilities.cxx:705:
$ cat test.cpp
class Data{
};
template <class TData>
void
GetIDMapper(TData data)
{
}
void test(void)
{
GetIDMapper(Data());
}
When compiling without optimizations, the GetIDMapper symbol is built:
$ g++ -c test.cpp && readelf -s test.o | grep GetIDMapper
... _Z11GetIDMapperI4DataEvT_
However -O2 will inline the template function:
$ g++ -O2 -c test.cpp && readelf -s test.o | grep GetIDMapper
For not loosing optimizations on the whole build, I have finally
found that I can control g++:
$ cat test.cpp
class Data{
};
template <class TData>
__attribute__((noinline))
void
GetIDMapper(TData data)
{
}
void test(void)
{
GetIDMapper(Data());
}
$ g++ -O2 -c test.cpp && readelf -s test.o | grep GetIDMapper
... _Z11GetIDMapperI4DataEvT_
So the good new is that I will provide a VISU patch and we can again
configure VISU in the for loop of debian/rules. Will it be possible
to reset the last commit? I deeply apologize for my mistake. For not
reproducing the same problem, I am going to build a new Salome version
and send you patches carefully once everything works.
By the way, is the 'git-builpackage' command that exports CXXFLAGS
to '-O2 -g'? I could not yet understand that step.
Best regards,
André
> 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/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
