[dev] Re: [releases] recommended stlport settings?
On 12/05/2010 15:17, Stephan Bergmann wrote: > Of course, it turns out that my recent checking was conducted in the > wrong way (I simply grepped for traces of STLport-exported symbols in > the mangled C++ symbols exported from the URE API libs). Looking more > closely, it turns out that the URE ABI *is* tainted by STLport after all: > > Classes cppu::OPropertySetHelper (cppuhelper/propshlp.hxx) and > cppu::UnoUrlDescriptor and cppu::UnoUrl (both cppuhelper/unourl.hxx) > each have a std::auto_ptr member and non-inline constructors etc. ah, yes... i remember replacing the void* member in OPropertySetHelper with a std::auto_ptr... but it wasn't actually my idea; somebody had told me "those are the same size on all platforms, so it's compatible" :) > (And even if one would argue that those classes are not used in OOo > extensions---which would probably hold true for the UnoUrl stuff, at > least---it would still be unsound to recompile URE without STLport: > Thanks to three layer OOo extracting out URE, multiple office > installations, old and new, can share a single URE installation, and at > least OPropertySetHelper is used within non-URE OOo code. The only > sound way out of that problem is to change URE incompatibly, which > brings us back to where we started...) but is there really a practical problem with std::auto_ptr? with the STL containers of course i'd never assume that there would be binary compatibility, but really, how many different ways are there to implement std::auto_ptr? basically it has a pointer member, and the destructor will call delete on it, right? and if the destructor of the containing class is indeed non-inline, then that's the only place where the auto_ptr destructor would be invoked (effectively making it not part of the ABI). > :( > > -Stephan regards, michael -- "C++ has the lethal combination of looking all nice and simple on the surface and having lots of traps installed under the surface, waiting for a victim." -- Yossi Kreinin - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: [releases] recommended stlport settings?
On 05/10/10 09:59, Stephan Bergmann wrote: On 04/26/10 10:43, Caolán McNamara wrote: On Sun, 2010-04-25 at 19:44 +0200, Rene Engelhard wrote: We can only improve things here when we eventually drop the STLport-requirement (and become URE-incompatible on the affected platforms). If we continue to build and package into the install sets stlport on Linux x86, but not actually build OOo itself against it, its quite likely that stuff will work out ok (i.e. legacy binary x86 extensions that link against stlport will continue to work) as there's no explicit use of stl types in the public ure interfaces. Not 100% certain about that though :-) I always thought there actually were traces of STLport in the URE ABI, in some obscure corner of it. And I am pretty sure I actually checked that, a long time ago. Anyway, checking on DEV300_m77 unxlngi6, it appears there are no such traces, not in the ABI designated by those dynamic libraries not listed as "private" in ure/source/README (apart from the STLport library itself, of course). Of course, it turns out that my recent checking was conducted in the wrong way (I simply grepped for traces of STLport-exported symbols in the mangled C++ symbols exported from the URE API libs). Looking more closely, it turns out that the URE ABI *is* tainted by STLport after all: Classes cppu::OPropertySetHelper (cppuhelper/propshlp.hxx) and cppu::UnoUrlDescriptor and cppu::UnoUrl (both cppuhelper/unourl.hxx) each have a std::auto_ptr member and non-inline constructors etc. (And even if one would argue that those classes are not used in OOo extensions---which would probably hold true for the UnoUrl stuff, at least---it would still be unsound to recompile URE without STLport: Thanks to three layer OOo extracting out URE, multiple office installations, old and new, can share a single URE installation, and at least OPropertySetHelper is used within non-URE OOo code. The only sound way out of that problem is to change URE incompatibly, which brings us back to where we started...) :( -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: [releases] recommended stlport settings?
On 04/26/10 10:43, Caolán McNamara wrote:
On Sun, 2010-04-25 at 19:44 +0200, Rene Engelhard wrote:
We can only improve things here when we eventually drop the STLport-requirement
(and become URE-incompatible on the affected platforms).
If we continue to build and package into the install sets stlport on
Linux x86, but not actually build OOo itself against it, its quite
likely that stuff will work out ok (i.e. legacy binary x86 extensions
that link against stlport will continue to work) as there's no explicit
use of stl types in the public ure interfaces. Not 100% certain about
that though :-)
I always thought there actually were traces of STLport in the URE ABI,
in some obscure corner of it. And I am pretty sure I actually checked
that, a long time ago. Anyway, checking on DEV300_m77 unxlngi6, it
appears there are no such traces, not in the ABI designated by those
dynamic libraries not listed as "private" in ure/source/README (apart
from the STLport library itself, of course).
So, I made a quick hack to verify that not building against our STLport
would actually work, see patch below. Some notes:
The hack for now is only for the Hamburg setsolar environment
(solenv/config/sdev300.ini), configure.in would still need to be
adapted. There is a new build environment variable,
OOO_INCLUDE_STLPORT; for USE_SYSTEM_STL!=YES it controls whether to
include (and thus build) OOo's STLport library in installation sets
nonetheless. (stlport/makefile.mk now only controls whether to build
STLport, while the new stlport/systemstl/makefile.mk controls whether to
copy the stlport/systemstl wrapper files to solver.)
The hack for now is only for unxlngi6. And at least for Linux, it
appears, there is not even a need to explicitly link executables that
can load OOo extensions (uno.bin, soffice.bin) against the STLport
library, so that legacy extension libraries linking against the STLport
library can find it: The Linux dynamic loader apparently uses the
executable's RPATH, among other places, to locate an extension library's
dependencies, so finds the STLport library in ure/lib via that.
This sounds promising, I would say.
-Stephan
diff -r 331c22de59dc scp2/source/ooo/makefile.mk
--- a/scp2/source/ooo/makefile.mk Thu Apr 22 18:47:26 2010 +0200
+++ b/scp2/source/ooo/makefile.mk Mon May 10 09:35:29 2010 +0200
@@ -123,6 +123,10 @@
SCPDEFS+=-DUSE_SYSTEM_STL
.ENDIF
+.IF "$(OOO_INCLUDE_STLPORT)" == "TRUE"
+SCPDEFS+=-DOOO_INCLUDE_STLPORT
+.ENDIF
+
.IF "$(WITH_MOZILLA)" == "NO"
SCPDEFS+=-DWITHOUT_MOZILLA
.ENDIF
diff -r 331c22de59dc scp2/source/ooo/ure.scp
--- a/scp2/source/ooo/ure.scp Thu Apr 22 18:47:26 2010 +0200
+++ b/scp2/source/ooo/ure.scp Mon May 10 09:35:29 2010 +0200
@@ -842,7 +842,8 @@
#endif
#if !defined USE_SYSTEM_STL || \
-(defined USE_SYSTEM_STL && defined _C52 && defined IS_LP64)
+(defined USE_SYSTEM_STL && defined _C52 && defined IS_LP64) || \
+defined OOO_INCLUDE_STLPORT
File gid_File_Dl_Stlport
TXT_FILE_BODY;
Dir = SCP2_URE_DL_DIR;
diff -r 331c22de59dc solenv/config/sdev300.ini
--- a/solenv/config/sdev300.ini Thu Apr 22 18:47:26 2010 +0200
+++ b/solenv/config/sdev300.ini Mon May 10 09:35:29 2010 +0200
@@ -631,6 +631,8 @@
SOLAR_OJDK16PATH
%SOLAR_ENV_ROOT%/openjdk-6-b08-linux-i586
SO_PACK %SOLAR_ENV_ROOT%/pack/%WORK_STAMP%
SRC_ROOT
%SOLAR_SOURCE_ROOT%/%WORK_STAMP%/ooo%UPDMINOREXT%
+USE_SYSTEM_STL YES
+OOO_INCLUDE_STLPORT TRUE
}
common2
{
diff -r 331c22de59dc stlport/makefile.mk
--- a/stlport/makefile.mk Thu Apr 22 18:47:26 2010 +0200
+++ b/stlport/makefile.mk Mon May 10 09:35:29 2010 +0200
@@ -34,29 +34,7 @@
.INCLUDE : settings.mk
-.IF "$(USE_SYSTEM_STL)"=="YES"
-
-.IF "$(OS)"=="SOLARIS" && "$(COM)"!="GCC"
-# System STL when building with SunStudio is just a version of STLport
-# which comes with the compiler
-all:
- @echo "Nothing to do"
-.ELSE #"$(OS)"=="SOLARIS" && "$(COM)"!="GCC"
-#
-# If you choose to build without stlport, some headers will be used to bring
the
-# sgi extensions into the std namespace:
-$(INCCOM)$/stlport$/functional \
-$(INCCOM)$/stlport$/hash_map \
-$(INCCOM)$/stlport$/hash_set \
-$(INCCOM)$/stlport$/numeric \
-$(INCCOM)$/stlport$/slist \
-$(INCCOM)$/stlport$/rope \
-$(INCCOM)$/stlport$/vector: systemstl$/$$(@:f)
-$(MKDIRHIER) $(@:d)
-$(COPY) $< $@
-.ENDIF #"$(OS)"=="SOLARIS" && "$(COM)"!="GCC"
-
-.ELSE # "$(USE_SYSTEM_STL)"
+.IF "$(USE_SYSTEM_STL)" != "YES" || "$(OOO_INCLUDE_STLPORT)" == "TRUE"
# --- Files
.EXPORT : CC CXX
@@ -161,12 +139,14 @@
BUILD_FLAGS=-f sunpro6.mak
.ENDIF # "$(CCNUMVER)">="00050008"
-OUT2INC= \
-stlport$/SC5$/*.SUNWCCh
+.IF "$(USE_SYSTEM_STL)" != "YES"
+OUT2INC = stlport$/SC5$/*.SUNWCCh
+.END
.ENDIF
-OUTDIR2INC= \
-stlport
+
Re: [dev] Re: [releases] recommended stlport settings?
Hi, On Mon, Apr 26, 2010 at 09:43:28AM +0100, Caolán McNamara wrote: > On Sun, 2010-04-25 at 19:44 +0200, Rene Engelhard wrote: > > We can only improve things here when we eventually drop the > > STLport-requirement > > (and become URE-incompatible on the affected platforms). (Note that I didn't say that) > If we continue to build and package into the install sets stlport on > Linux x86, but not actually build OOo itself against it, its quite > likely that stuff will work out ok (i.e. legacy binary x86 extensions > that link against stlport will continue to work) as there's no explicit > use of stl types in the public ure interfaces. Not 100% certain about Yeah. Or that. (As AFAIR SuSE does already) Grüße/Regards, René - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: [releases] recommended stlport settings?
On Sun, 2010-04-25 at 19:44 +0200, Rene Engelhard wrote: > We can only improve things here when we eventually drop the > STLport-requirement > (and become URE-incompatible on the affected platforms). If we continue to build and package into the install sets stlport on Linux x86, but not actually build OOo itself against it, its quite likely that stuff will work out ok (i.e. legacy binary x86 extensions that link against stlport will continue to work) as there's no explicit use of stl types in the public ure interfaces. Not 100% certain about that though :-) C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [releases] recommended stlport settings?
[ releases is not the correct list for that, X-posting to dev@ ] Hi, On Sun, Apr 25, 2010 at 04:24:51PM +0200, Andreas Radke wrote: > So far i686 needed --with-stlport to be able to use 3rd party > extensions. > > DEV300_m77 introduced cppunit requirement and now i686 configure fails: Not really. Was there before too, just that there always the internal hacked version was used. Now sb118 introduced the possinbility to use system-cppunit. (And note the default is still internal cppunit) > checking which cppunit to use... external OK, so you use --with-system-cppunit. (or --with-system-libs which of course implies --with-system-cppunit).. > checking for CPPUNIT... yes > checking STL compatibility... configure: error: to use system cppunit > you need to use --without-stlport > > > What the recommended way now? --without-stlport now for all > architectures? I build x86_64 and i686 for ArchLinux. You can use internal cppunit. Either only on i386 or everywhere. Though I don't like this either. See Issue 109791, we can't apply the same workarounds here like for mysqlc and graphite. To quote sb: --- snip --- > Wrt STLport: no way, if you really have a STL conflict (like we ha(d/ve) with > graphite and mysqlc) apply a workaround like the one caolan did for graphite > already (see issue 106157); it is bad to use system-cppunit on everything > except i386. Better all or none You unfortunately cannot work around that here. The interface of CppUnit is full of std-types, so the OOo test code calling CppUnit and CppUnit itself have to use the same STL implementation. However, the OOo test code also shall access OOo code that has std-types in its respective interface, so those two need to use the same STL implementation, too. We can only improve things here when we eventually drop the STLport-requirement (and become URE-incompatible on the affected platforms). --- snip --- An other reason why not dropping STLport when we could have (last major release AKA 3.0.0) was a seriously bad thing... Grüße/Regards, René - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
