You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Damjan Jovanovic <da...@apache.org> on 2012/10/17 06:11:55 UTC
Build fails in main/drawinglayer/source/texture/texture3d.cxx
Hi
With the latest SVN, on Ubuntu 12.04 amd64, I am getting this error
when building:
[ build CXX ] drawinglayer/source/texture/texture3d
/path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx: In member
function 'sal_uInt8
drawinglayer::texture::GeoTexSvxBitmapEx::impGetTransparence(sal_Int32&,
sal_Int32&) const':
/path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx:135:70:
error: call of overloaded 'Color(BitmapColor)' is ambiguous
/path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx:135:70:
note: candidates are:
/path/to/AOO/main/solver/350/unxlngx6.pro/inc/tools/color.hxx:120:7:
note: Color::Color(ColorData)
/path/to/AOO/main/solver/350/unxlngx6.pro/inc/tools/color.hxx:113:23:
note: Color::Color(const Color&)
make: *** [/path/to/AOO/main/solver/350/unxlngx6.pro/workdir/CxxObject/drawinglayer/source/texture/texture3d.o]
Error 1
dmake: Error code 2, while making 'all'
Please help?
Damjan
Re: Build fails in main/drawinglayer/source/texture/texture3d.cxx
Posted by Herbert Duerr <hd...@apache.org>.
Answering myself:
On 19.10.2012 15:19, I wrote:
> Option (c) could be even better: removal of both the dangerous
> conversion BitmapColor::operator sal_uInt8() and the implicit
> construction of a BitmapColor from a sal_uInt8.
>
> But binfilter depends on their behind the scenes conversions and nobody
> should or would want to touch binfilter to make it compile again after
> such a change.
FWIW I just committed revision 1400130 to allow cleanups in header files
that are common to the general code base and binfilter without having to
touch binfilter.
To do this I added a define BINFILTER_COMPAT that is only active when
compiling binfilter source files. Be careful when using the define
because you need to make sure that the different code paths remain
binary compatible.
> Yet another reason to get rid of binfilter...
When we finally get rid of binfilter the macro BINFILTER_COMPAT can be
grepped and easily be eliminated again.
Herbert
Re: Build fails in main/drawinglayer/source/texture/texture3d.cxx
Posted by Herbert Duerr <hd...@apache.org>.
On 18.10.2012 14:14, Armin Le Grand wrote:
> [...]
> ..but will convert BitmapColor to sal_uInt8 (because there is a inline
> operator in the class BitmapColor), then casting to sal_uInt32 (since
> ColorData is a typedef to sal_uInt32) and thus would be wrong. Sigh.
>
> Herbert is right, these operators are dangerous. I found two ways:
> (a) extract RGB by feet from BitmapColor and construct a Color with it
> (b) use the 'operator Color()' : '== aBitmapColor.operator Color()'
>
> Where (a) will need more code, and (b) looks ugly.
> I tend to (b) currently...
Option (c) could be even better: removal of both the dangerous
conversion BitmapColor::operator sal_uInt8() and the implicit
construction of a BitmapColor from a sal_uInt8.
But binfilter depends on their behind the scenes conversions and nobody
should or would want to touch binfilter to make it compile again after
such a change. Yet another reason to get rid of binfilter...
Herbert
Re: Build fails in main/drawinglayer/source/texture/texture3d.cxx
Posted by Armin Le Grand <Ar...@me.com>.
Hi Damjan,
okay, done. Revisions are 1399608 and 1399610, so use the latter please.
Sincerely,
Armin
On 18.10.2012 14:14, Armin Le Grand wrote:
> Hi Damjan,
>
> On 18.10.2012 12:02, Damjan Jovanovic wrote:
>> On Thu, Oct 18, 2012 at 11:42 AM, Armin Le Grand
>> <Ar...@me.com> wrote:
> --snip--
--snip--
--
ALG
Re: Build fails in main/drawinglayer/source/texture/texture3d.cxx
Posted by Armin Le Grand <Ar...@me.com>.
Hi Damjan,
On 18.10.2012 12:02, Damjan Jovanovic wrote:
> On Thu, Oct 18, 2012 at 11:42 AM, Armin Le Grand <Ar...@me.com> wrote:
--snip--
>
> Here they are in plain text then:
>
> --snip--
> Index: main/drawinglayer/source/texture/texture3d.cxx
> ===================================================================
> --- main/drawinglayer/source/texture/texture3d.cxx (revision 1399340)
> +++ main/drawinglayer/source/texture/texture3d.cxx (working copy)
> @@ -134,7 +134,7 @@
> {
> const BitmapColor
> aBitmapColor(mpReadBitmap->GetColor(rY, rX));
>
> - if(maBitmapEx.GetTransparentColor() == Color(aBitmapColor))
> + if(maBitmapEx.GetTransparentColor() ==
> Color((ColorData)aBitmapColor))
> {
> return 255;
> }
> --snip--
>
>
> which could be simpler (combine it with your previous patch), if it's
> even correct, and
..but will convert BitmapColor to sal_uInt8 (because there is a inline
operator in the class BitmapColor), then casting to sal_uInt32 (since
ColorData is a typedef to sal_uInt32) and thus would be wrong. Sigh.
Herbert is right, these operators are dangerous. I found two ways:
(a) extract RGB by feet from BitmapColor and construct a Color with it
(b) use the 'operator Color()' : '== aBitmapColor.operator Color()'
Where (a) will need more code, and (b) looks ugly.
I tend to (b) currently...
Build nearly finished...
Sincerely,
Armin
>
> --snip--
> Index: main/svx/source/sdr/contact/objectcontacttools.cxx
> ===================================================================
> --- main/svx/source/sdr/contact/objectcontacttools.cxx (revision 1399340)
> +++ main/svx/source/sdr/contact/objectcontacttools.cxx (working copy)
> @@ -77,18 +77,18 @@
> return new
> drawinglayer::processor2d::VclPixelProcessor2D(rViewInformation2D,
> rTargetOutDev);
> //}
> #else
> - static bool bTryTestCanvas(false);
> -
> - if(bTryTestCanvas)
> - {
> - // create test-cancas-Processor
> - return new
> drawinglayer::processor2d::canvasProcessor2D(rViewInformation2D,
> rTargetOutDev);
> - }
> - else
> - {
> +// static bool bTryTestCanvas(false);
> +//
> +// if(bTryTestCanvas)
> +// {
> +// // create test-cancas-Processor
> +// return new
> drawinglayer::processor2d::canvasProcessor2D(rViewInformation2D,
> rTargetOutDev);
> +// }
> +// else
> +// {
> // create Pixel Vcl-Processor
> return new
> drawinglayer::processor2d::VclPixelProcessor2D(rViewInformation2D,
> rTargetOutDev);
> - }
> +// }
> #endif
> }
> }
> --snip--
>
> Thank you and I appreciate your efforts
> Damjan
>
--
ALG
Re: Build fails in main/drawinglayer/source/texture/texture3d.cxx
Posted by Damjan Jovanovic <da...@gmail.com>.
On Thu, Oct 18, 2012 at 11:42 AM, Armin Le Grand <Ar...@me.com> wrote:
> Hi Damjan,
>
>
> On 17.10.2012 20:12, Damjan Jovanovic wrote:
>>
>> On Wed, Oct 17, 2012 at 10:29 AM, Armin Le Grand <Ar...@me.com>
>> wrote:
>>>
>>> Hi,
>>>
>>>
> --snip--
>
>
>>
>> It's most definitely NOT fixed, even in revision 1399319:
>>
>> [ build CXX ] drawinglayer/source/texture/texture3d
>> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx: In member
>> function 'sal_uInt8
>> drawinglayer::texture::GeoTexSvxBitmapEx::impGetTransparence(sal_Int32&,
>> sal_Int32&) const':
>> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx:137:78:
>> error: call of overloaded 'Color(const BitmapColor&)' is ambiguous
>> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx:137:78:
>> note: candidates are:
>> /path/to/AOO/main/solver/350/unxlngx6.pro/inc/tools/color.hxx:120:7:
>> note: Color::Color(ColorData)
>> /path/to/AOO/main/solver/350/unxlngx6.pro/inc/tools/color.hxx:113:23:
>> note: Color::Color(const Color&)
>> make: ***
>> [/path/to/AOO/main/solver/350/unxlngx6.pro/workdir/CxxObject/drawinglayer/source/texture/texture3d.o]
>> Error 1
>> dmake: Error code 2, while making 'all'
>
>
> Sorry, but I'm normally building on Win (as I mentioned) and there the error
> does not happen. I had no access to a linux box yesterday, but I started a
> fresh checkout&build on linux one hour ago.
>
>
>>
>>
>> Attached is a possible patch (texture3d.patch) which gets it to
>> compile successfully but I don't want to apply it because it could be
>> semantically wrong.
>
>
> Patches are automatically removed on the lists, as it seems.
>
Here they are in plain text then:
--snip--
Index: main/drawinglayer/source/texture/texture3d.cxx
===================================================================
--- main/drawinglayer/source/texture/texture3d.cxx (revision 1399340)
+++ main/drawinglayer/source/texture/texture3d.cxx (working copy)
@@ -134,7 +134,7 @@
{
const BitmapColor
aBitmapColor(mpReadBitmap->GetColor(rY, rX));
- if(maBitmapEx.GetTransparentColor() == Color(aBitmapColor))
+ if(maBitmapEx.GetTransparentColor() ==
Color((ColorData)aBitmapColor))
{
return 255;
}
--snip--
which could be simpler (combine it with your previous patch), if it's
even correct, and
--snip--
Index: main/svx/source/sdr/contact/objectcontacttools.cxx
===================================================================
--- main/svx/source/sdr/contact/objectcontacttools.cxx (revision 1399340)
+++ main/svx/source/sdr/contact/objectcontacttools.cxx (working copy)
@@ -77,18 +77,18 @@
return new
drawinglayer::processor2d::VclPixelProcessor2D(rViewInformation2D,
rTargetOutDev);
//}
#else
- static bool bTryTestCanvas(false);
-
- if(bTryTestCanvas)
- {
- // create test-cancas-Processor
- return new
drawinglayer::processor2d::canvasProcessor2D(rViewInformation2D,
rTargetOutDev);
- }
- else
- {
+// static bool bTryTestCanvas(false);
+//
+// if(bTryTestCanvas)
+// {
+// // create test-cancas-Processor
+// return new
drawinglayer::processor2d::canvasProcessor2D(rViewInformation2D,
rTargetOutDev);
+// }
+// else
+// {
// create Pixel Vcl-Processor
return new
drawinglayer::processor2d::VclPixelProcessor2D(rViewInformation2D,
rTargetOutDev);
- }
+// }
#endif
}
}
--snip--
Thank you and I appreciate your efforts
Damjan
Re: Build fails in main/drawinglayer/source/texture/texture3d.cxx
Posted by Armin Le Grand <Ar...@me.com>.
Hi Damjan,
On 17.10.2012 20:12, Damjan Jovanovic wrote:
> On Wed, Oct 17, 2012 at 10:29 AM, Armin Le Grand <Ar...@me.com> wrote:
>> Hi,
>>
>>
--snip--
>
> It's most definitely NOT fixed, even in revision 1399319:
>
> [ build CXX ] drawinglayer/source/texture/texture3d
> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx: In member
> function 'sal_uInt8
> drawinglayer::texture::GeoTexSvxBitmapEx::impGetTransparence(sal_Int32&,
> sal_Int32&) const':
> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx:137:78:
> error: call of overloaded 'Color(const BitmapColor&)' is ambiguous
> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx:137:78:
> note: candidates are:
> /path/to/AOO/main/solver/350/unxlngx6.pro/inc/tools/color.hxx:120:7:
> note: Color::Color(ColorData)
> /path/to/AOO/main/solver/350/unxlngx6.pro/inc/tools/color.hxx:113:23:
> note: Color::Color(const Color&)
> make: *** [/path/to/AOO/main/solver/350/unxlngx6.pro/workdir/CxxObject/drawinglayer/source/texture/texture3d.o]
> Error 1
> dmake: Error code 2, while making 'all'
Sorry, but I'm normally building on Win (as I mentioned) and there the
error does not happen. I had no access to a linux box yesterday, but I
started a fresh checkout&build on linux one hour ago.
>
>
> Attached is a possible patch (texture3d.patch) which gets it to
> compile successfully but I don't want to apply it because it could be
> semantically wrong.
Patches are automatically removed on the lists, as it seems.
> Also attached is another patch (objectcontacttools.patch) for a
> problem that breaks the build later on, because
> "drawinglayer::processor2d::canvasProcessor2D" doesn't exist
> (according to grep). Simply commenting out that section of code gets
> it to compile. It seems that someone has already done similar
> commenting for Windows in the "#ifdef WIN32" just above my patch?
> Since when was AOO a Windows-only project?
I will also check this; It's not a win-only project, but when developing
it's not easy to build on all plattforms to check. This should certainly
be done for bigger changes and a branch should be used, but even then
there will be a time gap between this and the trunk integration.
> Also it was necessary to use ld.gold for at least part of the build.
>
> Please use those buildbots and keep AOO compiling on all platforms.
Yes, these build the trunk, so they check after checkin, too.
I'm on it...
Sorry again, but these implicit conversons seem to be triggered
differently on different systems.
> Regards
> Damjan
>
Sincerely,
Armin
--
ALG
Re: Build fails in main/drawinglayer/source/texture/texture3d.cxx
Posted by Damjan Jovanovic <da...@apache.org>.
On Wed, Oct 17, 2012 at 10:29 AM, Armin Le Grand <Ar...@me.com> wrote:
> Hi,
>
>
> On 17.10.2012 06:24, Pedro Giffuni wrote:
>>
>>
>>
>> ----- Original Message -----
>>>
>>> From: Damjan Jovanovic
>>
>> ...
>>>
>>>
>>> Hi
>>>
>>> With the latest SVN, on Ubuntu 12.04 amd64, I am getting this error
>>> when building:
>>>
>>> [ build CXX ] drawinglayer/source/texture/texture3d
>>> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx: In member
>>> function 'sal_uInt8
>>> drawinglayer::texture::GeoTexSvxBitmapEx::impGetTransparence(sal_Int32&,
>>> sal_Int32&) const':
>>> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx:135:70:
>>> error: call of overloaded 'Color(BitmapColor)' is ambiguous
>>> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx:135:70:
>>> note: candidates are:
>>> /path/to/AOO/main/solver/350/unxlngx6.pro/inc/tools/color.hxx:120:7:
>>> note: Color::Color(ColorData)
>>> /path/to/AOO/main/solver/350/unxlngx6.pro/inc/tools/color.hxx:113:23:
>>> note: Color::Color(const Color&)
>>> make: ***
>>>
>>> [/path/to/AOO/main/solver/350/unxlngx6.pro/workdir/CxxObject/drawinglayer/source/texture/texture3d.o]
>>> Error 1
>>> dmake: Error code 2, while making 'all'
>
>
> I made some changes, got no errors on win (what means nothing as we know).
> It's strange since ColorData is just a typedef (to sal_Int32) and I see no
> way to auto-convert BitmapColor to it, so 'operator Color()' in class Color
> should be used.
> Made that more explicit now in revision 1399148, please have a try.
>
> Armin
>
It's most definitely NOT fixed, even in revision 1399319:
[ build CXX ] drawinglayer/source/texture/texture3d
/path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx: In member
function 'sal_uInt8
drawinglayer::texture::GeoTexSvxBitmapEx::impGetTransparence(sal_Int32&,
sal_Int32&) const':
/path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx:137:78:
error: call of overloaded 'Color(const BitmapColor&)' is ambiguous
/path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx:137:78:
note: candidates are:
/path/to/AOO/main/solver/350/unxlngx6.pro/inc/tools/color.hxx:120:7:
note: Color::Color(ColorData)
/path/to/AOO/main/solver/350/unxlngx6.pro/inc/tools/color.hxx:113:23:
note: Color::Color(const Color&)
make: *** [/path/to/AOO/main/solver/350/unxlngx6.pro/workdir/CxxObject/drawinglayer/source/texture/texture3d.o]
Error 1
dmake: Error code 2, while making 'all'
Attached is a possible patch (texture3d.patch) which gets it to
compile successfully but I don't want to apply it because it could be
semantically wrong.
Also attached is another patch (objectcontacttools.patch) for a
problem that breaks the build later on, because
"drawinglayer::processor2d::canvasProcessor2D" doesn't exist
(according to grep). Simply commenting out that section of code gets
it to compile. It seems that someone has already done similar
commenting for Windows in the "#ifdef WIN32" just above my patch?
Since when was AOO a Windows-only project?
Also it was necessary to use ld.gold for at least part of the build.
Please use those buildbots and keep AOO compiling on all platforms.
Regards
Damjan
Re: Build fails in main/drawinglayer/source/texture/texture3d.cxx
Posted by Armin Le Grand <Ar...@me.com>.
Hi Herbert,
On 17.10.2012 13:48, Herbert Duerr wrote:
> On 17.10.2012 10:29, Armin Le Grand wrote:
>> I made some changes, got no errors on win (what means nothing as we
>> know). It's strange since ColorData is just a typedef (to sal_Int32) and
>> I see no way to auto-convert BitmapColor to it, so 'operator Color()' in
>> class Color should be used.
>
> BitmapColor has implicit conversion operators for both
> BitmapColor::operator Color()
> and
> BitmapColor::operator sal_uInt8()
> Since Color has a constructor for an unsigned integer
> Color( sal_uInt32 nColor)
> the conversion is ambiguous, even if the second alternative needs an
> extra type conversion from sal_uInt8 to sal_uInt32.
Ah! That's the implicit one I've missed. That's really dangerous...
> This shows again that implicit conversions are very tricky even for
> experienced developers. So I suggest to prefer explicit constructors
> over implicit ones. Unfortunately explicit conversion operators are only
> available since C++11.
>
> Things like e.g. the implicit conversion from BitmapColor to sal_uInt8
> are too slick for my taste anyway and they should IMHO be made explicit
> by replacing their uses by something like GetIndex(), so the C++11
> feature of explicit conversion operators can be dispensed with.
>
> Herbert
>
--
ALG
Re: Build fails in main/drawinglayer/source/texture/texture3d.cxx
Posted by Herbert Duerr <hd...@apache.org>.
On 17.10.2012 10:29, Armin Le Grand wrote:
> I made some changes, got no errors on win (what means nothing as we
> know). It's strange since ColorData is just a typedef (to sal_Int32) and
> I see no way to auto-convert BitmapColor to it, so 'operator Color()' in
> class Color should be used.
BitmapColor has implicit conversion operators for both
BitmapColor::operator Color()
and
BitmapColor::operator sal_uInt8()
Since Color has a constructor for an unsigned integer
Color( sal_uInt32 nColor)
the conversion is ambiguous, even if the second alternative needs an
extra type conversion from sal_uInt8 to sal_uInt32.
This shows again that implicit conversions are very tricky even for
experienced developers. So I suggest to prefer explicit constructors
over implicit ones. Unfortunately explicit conversion operators are only
available since C++11.
Things like e.g. the implicit conversion from BitmapColor to sal_uInt8
are too slick for my taste anyway and they should IMHO be made explicit
by replacing their uses by something like GetIndex(), so the C++11
feature of explicit conversion operators can be dispensed with.
Herbert
Re: Build fails in main/drawinglayer/source/texture/texture3d.cxx
Posted by Armin Le Grand <Ar...@me.com>.
Hi,
On 17.10.2012 06:24, Pedro Giffuni wrote:
>
>
> ----- Original Message -----
>> From: Damjan Jovanovic
> ...
>>
>> Hi
>>
>> With the latest SVN, on Ubuntu 12.04 amd64, I am getting this error
>> when building:
>>
>> [ build CXX ] drawinglayer/source/texture/texture3d
>> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx: In member
>> function 'sal_uInt8
>> drawinglayer::texture::GeoTexSvxBitmapEx::impGetTransparence(sal_Int32&,
>> sal_Int32&) const':
>> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx:135:70:
>> error: call of overloaded 'Color(BitmapColor)' is ambiguous
>> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx:135:70:
>> note: candidates are:
>> /path/to/AOO/main/solver/350/unxlngx6.pro/inc/tools/color.hxx:120:7:
>> note: Color::Color(ColorData)
>> /path/to/AOO/main/solver/350/unxlngx6.pro/inc/tools/color.hxx:113:23:
>> note: Color::Color(const Color&)
>> make: ***
>> [/path/to/AOO/main/solver/350/unxlngx6.pro/workdir/CxxObject/drawinglayer/source/texture/texture3d.o]
>> Error 1
>> dmake: Error code 2, while making 'all'
I made some changes, got no errors on win (what means nothing as we
know). It's strange since ColorData is just a typedef (to sal_Int32) and
I see no way to auto-convert BitmapColor to it, so 'operator Color()' in
class Color should be used.
Made that more explicit now in revision 1399148, please have a try.
Armin
> FWIW,
>
> I am also getting similar issues in drawinglayer today.
>
> Pedro.
>
--
ALG
Re: Build fails in main/drawinglayer/source/texture/texture3d.cxx
Posted by Andrew Rist <an...@oracle.com>.
On 10/16/2012 9:24 PM, Pedro Giffuni wrote:
>
> ----- Original Message -----
>> From: Damjan Jovanovic
> ...
>> Hi
>>
>> With the latest SVN, on Ubuntu 12.04 amd64, I am getting this error
>> when building:
>>
>> [ build CXX ] drawinglayer/source/texture/texture3d
>> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx: In member
>> function 'sal_uInt8
>> drawinglayer::texture::GeoTexSvxBitmapEx::impGetTransparence(sal_Int32&,
>> sal_Int32&) const':
>> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx:135:70:
>> error: call of overloaded 'Color(BitmapColor)' is ambiguous
>> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx:135:70:
>> note: candidates are:
>> /path/to/AOO/main/solver/350/unxlngx6.pro/inc/tools/color.hxx:120:7:
>> note: Color::Color(ColorData)
>> /path/to/AOO/main/solver/350/unxlngx6.pro/inc/tools/color.hxx:113:23:
>> note: Color::Color(const Color&)
>> make: ***
>> [/path/to/AOO/main/solver/350/unxlngx6.pro/workdir/CxxObject/drawinglayer/source/texture/texture3d.o]
>> Error 1
>> dmake: Error code 2, while making 'all'
>>
> FWIW,
>
> I am also getting similar issues in drawinglayer today.
>
> Pedro.
The Linux 64bit buildbot that has been stable for a while also hit the
issue.
A.
Re: Build fails in main/drawinglayer/source/texture/texture3d.cxx
Posted by Pedro Giffuni <pf...@apache.org>.
----- Original Message -----
> From: Damjan Jovanovic
...
>
> Hi
>
> With the latest SVN, on Ubuntu 12.04 amd64, I am getting this error
> when building:
>
> [ build CXX ] drawinglayer/source/texture/texture3d
> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx: In member
> function 'sal_uInt8
> drawinglayer::texture::GeoTexSvxBitmapEx::impGetTransparence(sal_Int32&,
> sal_Int32&) const':
> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx:135:70:
> error: call of overloaded 'Color(BitmapColor)' is ambiguous
> /path/to/AOO/main/drawinglayer/source/texture/texture3d.cxx:135:70:
> note: candidates are:
> /path/to/AOO/main/solver/350/unxlngx6.pro/inc/tools/color.hxx:120:7:
> note: Color::Color(ColorData)
> /path/to/AOO/main/solver/350/unxlngx6.pro/inc/tools/color.hxx:113:23:
> note: Color::Color(const Color&)
> make: ***
> [/path/to/AOO/main/solver/350/unxlngx6.pro/workdir/CxxObject/drawinglayer/source/texture/texture3d.o]
> Error 1
> dmake: Error code 2, while making 'all'
>
FWIW,
I am also getting similar issues in drawinglayer today.
Pedro.