Hello Denis, On Wed, Jun 02, 2010 at 02:13:51PM +0200, Denis Barbier wrote: > On 2010/6/2 Andre Espaze wrote: > [...] > > Your solution is however better because the exported symbols > > are in control while in my case I remove every GetIDMapper function > > inlining. > [...] > > It seems that there is some disagreement between us, I believe that > the sentence above is the root cause. You say that my solution gives > a better control on symbols which are exported, but my opinion is that > both solutions provide the exact same API. Can you please explain the > differences induced by those patches? (For instance by running > objdump, readelf,... on generated libraries and comparing output) > Thanks.
Sure, I am going to show the problem on real librairies. I had first imitated it by the test.cpp code provided in bug 457075, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457075#400 >From the beginning, the problem is specific to g++ optimizations that's why I wanted to reflect that fact in my patch. Am I wrong on that point? The disagreement is maybe just here. I assume that you run git-buildpackage on the revision f57b74db488c91754eadbca263c065ff2022ac71, thus the build has failed with the status message given by Adam in that bug entry. The relevant code is in the CONVERTOR directory of the VISU module: $ cd VISU_SRC_5.1.3/src/CONVERTOR The VISUConvertor can not be built because GetIDMapper symbols do not exist. You can check the problem in the corresponding module: $ readelf -s .libs/libVisuConvertor_la-VISU_MergeFilterUtilities.o | \ grep GetIDMapper However if you remove the O2 optimizations in the CXXFLAGS of the Makefile (by first making a backup): $ cp Makefile Makefile.orig $ sed -i "s/^CXXFLAGS = .*/CXXFLAGS = -D_OCC64 -g -D_DEBUG_ -pthread/" \ Makefile and then force the module to be built again: $ rm libVisuConvertor_la-VISU_MergeFilterUtilities.lo $ make it will work. Now if you check the exported symbols: $ readelf -s .libs/libVisuConvertor_la-VISU_MergeFilterUtilities.o | \ grep GetIDMapper 759: 0000000000000000 113 FUNC WEAK DEFAULT 395 _ZN4VISU11GetIDMapperINS_ 769: 0000000000000000 113 FUNC WEAK DEFAULT 411 _ZN4VISU11GetIDMapperINS_ 879: 0000000000000000 259 FUNC WEAK DEFAULT 569 _ZN4VISU11GetIDMapperINS_ 880: 0000000000000000 259 FUNC WEAK DEFAULT 571 _ZN4VISU11GetIDMapperINS_ you should have 4 entries. At that step, I understood that the upstream code is valid C++ (but not necessarily robust) and thus I wanted to provide a patch controlling g++ optimizations while respecting their coding style. That's why you can find the 'if' statements since the beginning. My patch no-template-function-inline will remove every template function inlining of GetIDMapper when compiling with O2 optimizations: $ cd ../../.. $ patch -p1 < no-template-function-inline.patch $ patch -p1 < debian/patches/visu-no-template-inline.patch $ cd VISU_SRC_5.1.3/src/CONVERTOR $ mv Makefile.orig Makefile $ make $ readelf -s .libs/libVisuConvertor_la-VISU_MergeFilterUtilities.o | \ grep GetIDMapper 89: 0000000000000000 113 FUNC WEAK DEFAULT 48 _ZN4VISU11GetIDMapperINS_ 95: 0000000000000000 54 FUNC WEAK DEFAULT 50 _ZN4VISU11GetIDMapperINS_ 96: 0000000000000000 54 FUNC WEAK DEFAULT 52 _ZN4VISU11GetIDMapperINS_ 97: 0000000000000000 113 FUNC WEAK DEFAULT 54 _ZN4VISU11GetIDMapperINS_ Finally your solution will only export the needed GetIDMapper symbol: $ git checkout HEAD VISU_MergeFilterUtilities.hxx $ cd ../../.. $ patch -p1 < visu-template-export.patch $ cd VISU_SRC_5.1.3/src/CONVERTOR $ make $ readelf -s .libs/libVisuConvertor_la-VISU_MergeFilterUtilities.o | \ grep GetIDMapper 68: 0000000000000000 113 FUNC WEAK DEFAULT 26 _ZN4VISU11GetIDMapperINS_ I agree with you that your solution is valid and robust C++ code so the if statements could be removed no matter if the code is compiled with or without optimizations or even with others compilers. But I think that such a decision should be made by upstream because we discovered the problem only when working with g++ O2 optimizations. I am open to further explanations if needed. Best regards, André -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
