inline vtable problems with latest kdelibs snapshot?

[Simon Hausmann]

On Tuesday 09 May 2006 19:35, Friedrich W. H. Kossebau wrote:
> Am Dienstag, 9. Mai 2006 19:33, schrieb Frans Englich:
> > On Tuesday 09 May 2006 17:13, David Faure wrote:
> > > On Tuesday 09 May 2006 19:05, Friedrich W. H. Kossebau wrote:
> > > > Hi,
> > > >
> > > > after I updated to the most new kdelibs snapshot some of the test in
> > > > kdeutils/khexedit/lib/tests do not link any longer, but complain
> > > > about undefined vtables, e.g.:
> > > > --- 8< ---
> > > > Linking CXX executable kebcdic1047charcodeckcharcodeciftest
> > > > CMakeFiles/kebcdic1047charcodeckcharcodeciftest.dir/kebcdic1047charco
> > > >de ck charcodeciftest.o: In function `KEBCDIC1047CharCodec':
> > > > /home/koder/Programmieren/kdesvn/trunk/KDE/kdeutils/khexedit/lib/test
> > > >s/ .. /codecs/kebcdic1047charcodec.h:44: undefined reference to
> > > > `vtable for KHE::KEBCDIC1047CharCodec'
> > > > collect2: ld returned 1 exit status
> > > > make[2]: ***
> > > > [khexedit/lib/tests/kebcdic1047charcodeckcharcodeciftest] Fehler 1
> > > > make[1]: ***
> > > > [khexedit/lib/tests/CMakeFiles/kebcdic1047charcodeckcharcodeciftest.d
> > > >ir /a ll] Fehler 2
> > > > make: *** [all] Fehler 2
> > > > --- 8< ---
> > > >
> > > > Any idea what could have triggered this?
> > >
> > > Yes, visibility is hidden by default again, on compilers that support
> > > it (notably gcc-4.0)
>
> Aha, thanks for the info :)
>
> > >  For your test to link, you need the library it's
> > > linking with (libkhexedit or something) to export the symbols that the
> > > test uses - best done using a KHEXEDIT_EXPORT defined to KDE_EXPORT in
> > > a khexedit_export.h file, so that people compiling on windows can later
> > > on alter that header file to redefine the macro more precisely. Then
> > > insert KHEXEDIT_EXPORT between "class" and "KEBCDIC1047CharCodec" ;)
> >
> > So if I got this straight: you suggest to export classes even if their
> > only requirement for the export is testing? Can't it be done in a way
> > such that exporting doesn't affect production? Seems to be a pity,
> > otherwise.
>
> Yes, it's the same problem for me here, testing internal classes.
> I really hope there could be a way to use full libraries, like it used to
> be. The other alternative would be to manually add the SUT files and all
> dependent for each single test, which makes doing testing more
> inconvenient, which is no good!
>
> > I've myself run into this problem, so it will be interesting to see if
> > anyone can come up with a solution.
>
> The same setup worked with libtool (IIRC). Did it store the not exported
> symbols somewhere so they were available if linking to the lib as a
> convenience library?
>
> I guess the trolls came across this problem, too? How did they solve it?

We have a Q_INTERNAL_EXPORT macro which is only set for internal development 
builds. In addition we sometimes compile the .cpp files into the unit test.

Simon