Type: required
Title: Problems with deriving SAL_DLLPUBLIC classes from all-inline
classes on MSC
Posted by: stephan.bergm...@sun.com
Affected: connectivity
TaskId: i95065
<http://www.openoffice.org/issues/show_bug.cgi?id=95065>
Effective from: sb102
CWS:
<http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300/sb102>
CWS status: new
*Summary*
--------
connectivity::ORefVector
chart2 apphelper::LifeTimeGuard
*Description*
-------------
On MSC, when a class is marked as SAL_DLLPUBLIC_EX-/IMPORT, all its
base classes that are not yet otherwise marked as SAL_DLLPUBLIC_IMPORT
are apparently treated as SAL_DLLPUBLIC_EX-/IMPORT, too. This causes
link errors when such a base class is also used in a context where it
is not considered SAL_DLLPUBLIC_EX-/IMPORT, and cannot be changed to
be SAL_DLLPUBLIC_IMPORT because it is all inline.
This happened with connectivity::ORefVector, which was originally
derived from std::vector, and chart2's apphelper::LifeTimeGuard, which
was originally derived from osl::ResettableMutex. Both had to be
changed, where changing the former (introduction of Vector member
typedef and get() member functions) caused substantial (trivial)
change in depending source files in connectivity and dbaccess.
Send feedback to interface-announce@openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: interface-announce-unsubscr...@openoffice.org
For additional commands, e-mail: interface-announce-h...@openoffice.org
