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
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
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
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
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
[ 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.