[ 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: [email protected] For additional commands, e-mail: [email protected]
