#550 Link errors due to missing export attributes

[Lars Fastrup]

Have download and compiled OWLNext 7.0.10 with OWLMaker.

Building the classes example with VS2022 yields the following linker error for the configurations Dynamic Debug and Dynamic Release:

Error LNK2019 unresolved external symbol "public: bool __thiscall owl::TRegKey::TSecurityDescriptor::IsValid(void)const " (?IsValid@TSecurityDescriptor@TRegKey@owl@@QBE_NXZ) referenced in function "public: __thiscall <lambda_72df5e190eb369ed6f1e5881832cf074>::operator()(class owl::TRegKey &,unsigned long,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)const " (??R<lambda_72df5e190eb369ed6f1e5881832cf074>@@QBE@AAVTRegKey@owl@@KABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z)   classes F:\Source\owlnext-7.0.10\examples\classes\VS2022\regtest.obj    1

The static configuration builds and runs with no issues.

[Vidar Hasfjord]

Hi Lars, thanks for reporting this issue!

It seems TRegKey::TSecurityDescriptor is missing the _OWLCLASS attribute, and hence is not exported in the DLL interface. I will fix it for our upcoming 7.0.11 update.

[Vidar Hasfjord]

I found further similar issues, so this ticket has been renamed and its scope broadened.

The reported issue with TRegKey::TSecurityDescriptor was fixed on the trunk in [r6498], and the fix has been merged into 7.0 [r6499].

Further missing link attributes were discovered for TFontUnicodeRanges, TStreamFile, TWindowClassName, TPrinter::TDevMode, TSplitterIndicatorList, TTransferBuffer::TXPolygamousControl, TTransferBuffer::TXFieldConflict, TTransferBuffer::TXUnboundControl , and TTransferBuffer::TXMeddlingValidator. All of these were missing the _OWLCLASS attribute. This was fixed on the trunk in [r6516], and the fix has been merged into 6.30 [r6518], 6.36 [r6520], 6.44 [r6521] and 7.0 [r6522].

There are still a lot of classes missing the _OWLCLASS attribute, but as far as I can see, all of them are fully inlined, so they do not cause link errors. If I have missed any that are not fully inlined, please report.

Ideally, we should export all public classes (i.e. apply _OWLCLASS consistently). Although a fully inlined implementation will not cause link errors, it may violate the One Definition Rule, since taking a function address will yield different results inside and outside of the DLL, unless the function is exported.

(Templates are exempt, of course, although full specialisations, if any, are ordinary classes and should be exported.)

Let me know what you think.