Jim Watson wrote:
On 02/03/2007, at 7:43 PM, Oliver Bolte wrote:
Hi,
I'll be happy if we can get rid of STLport anyway.
Oliver
Stephan Bergmann wrote:
[EMAIL PROTECTED] wrote:
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=75046
Issue #|75046
Summary|Porting stlport for .NET 2005 64 bit compiler
Component|porting
Version|680m203
Platform|PC
URL|
OS/Version|Windows Vista
Status|NEW
Status whiteboard|
Keywords|
Resolution|
Issue type|TASK
Priority|P3
Subcomponent|code
Assigned to|obo
Reported by|obo
Hi all,
Reading this, I was just wondering whether, in general, it would make
sense for completely new platforms to not use our STLport but rather
the standard libraries that come with the respective compiler (if
they are complete enough, which I assume is the case by now). (Of
course, that would mean that we have to clean up STLport-specific
constructs in our code base, but the more portable the better, anyway.)
-Stephan
---------------------------------------------------------------------
So... what is the significance of this rather scary comment in configure?
Warning!!, --without-stlport4 is possible with
gcc >= 3.3.3, but will break ABI compatability
jim
For UNO components written in C++, we guarantee that components
developed against an old version of OOo (resp. URE) on a certain
platform continue to work with a newer verson of OOo/URE on that
platform, without recompilation. That implies that the Application
Binary Interface of the OOo/URE dynamic libraries that such a component
can link against (sal, salhelper, cppu, cppuhelper) does not change
incompatibly. Unfortunately, some functionality exposed by those
OOo/URE dynamic libraries uses "STL stuff," in such a way that changing
from STLport to something else would most likely change the ABI
incompatibly.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
