I am trying to track down an error that can at least be observed when building recent versions of LibreOffice (e.g., revision bf3ff35d8c96315c35cf8dc8495be4b488b55cb6 of git://anongit.freedesktop.org/libreoffice/core) on Fedora 15 i386 (i.e., with GCC 4.6.0 20110603 (Red Hat 4.6.0-10)). The problem is that linking together objects via
> g++ -shared vbarange.o vbasheetobjects.o fails with errors like > `.L109' referenced in section > `.rodata._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollectionEEEE4ItemERKN3com3sun4star3uno3AnyESD_[ScVbaCollectionBase<cppu::WeakImplHelper1<ooo::vba::XCollection> > >::Item(com::sun::star::uno::Any const&, com::sun::star::uno::Any const&)]' > of vbasheetobjects.o: defined in discarded section > `.text._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollectionEEEE4ItemERKN3com3sun4star3uno3AnyESD_[non-virtual > thunk to ScVbaCollectionBase<cppu::WeakImplHelper1<ooo::vba::XCollection> > >::Item(com::sun::star::uno::Any const&, com::sun::star::uno::Any const&)]' > of vbasheetobjects.o The two C++ files vbarange.cxx and vbasheetobjects.cxx are compiled with identical g++ command lines, including switches -fPIC -fno-common -pipe -fvisibility=hidden -fvisibility-inlines-hidden -std=c++0x -fexceptions -fno-enforce-eh-specs -Os besides more mundane -D, -I, -M, and -W switches. Both objects include code for the _ZThn20_N19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollectionEEEE4ItemERKN3com3sun4star3uno3AnyESD_ function, but there are two things that strike me as odd: First, the code emitted for the two functions is rather different in the two object files, even though both are compiled with identical command line switches. One difference is that In vbasheetobjects.o, the code contains a .rodata section (see below) with a number of labels into code that follows, whereas the code in vbarange.o does not contain such a .rodata section. Could it be that -Os can cause these differences? (If necessary, I can easily make available the -S output for the relevant code from the two different files.) Second, the directive for the .rodata section mentioned above is > .section > .rodata._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollectionEEEE4ItemERKN3com3sun4star3uno3AnyESD_,"aG",@progbits,_ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollectionEEEE4ItemERKN3com3sun4star3uno3AnyESD_,comdat while the directive for the corresponding .text section (split in multiple parts) is > .section > .text._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollectionEEEE4ItemERKN3com3sun4star3uno3AnyESD_,"axG",@progbits,_ZThn20_N19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollectionEEEE4ItemERKN3com3sun4star3uno3AnyESD_,comdat Note the difference in the GroupName part of the .section directives, the text section using the symbol denoting a non-virtual thunk to the function in question. My understanding of such ELF section groups is weak, but my theory is that the .rodata and .text sections should belong to a single group, so that the linker would either keep or remove them together. What apparently happens instead is that the linker uses the .text section from vbarange.o, drops the corresponding .text section from vbasheetobjects.o, and then stumbles over the left-over .rodata section. (Manually adapting the GroupName of the .rodata section directive to match the .text section makes the link succeed.) The problem has been worked around for now in LIbreOffice by compiling vbasheetobjects.o without -Os (see http://cgit.freedesktop.org/libreoffice/core/commit/?id=148e0ccb50ce419e18e452eb7ccfe03cb4881634 -- i.e., that change must be reverted before the problem can be observed in the code revision mentioned at the beginning). Can somebody enlighten me why the generated code differs in the first place, and whether my theory of non-matching GroupNames is correct? Thanks, -Stephan
