Hi folks,

I'd like to get some feedback on what compilers you are using to build
your own POV-Ray binaries (if applicable).

More specifically, I'd like to know whether anyone is using something
*OTHER* than one of the following:

- Microsoft Visual Studio 2015 or later.
- Gnu Compiler Collection 4.8.1 or later.
- Clang 3.3 or later.

So if you are using an older version of the above compilers, or an
entirely different compiler, please let us know.


The ultimate purpose of this survey is to determine which C++11 features
might be safe to use in the POV-Ray source code.

Post a reply to this message

Le 20/06/2017 à 16:27, clipka a écrit :
> Hi folks,
> 
> I'd like to get some feedback on what compilers you are using to build
> your own POV-Ray binaries (if applicable).
> 
> More specifically, I'd like to know whether anyone is using something
> *OTHER* than one of the following:
> 
> - Microsoft Visual Studio 2015 or later.
> - Gnu Compiler Collection 4.8.1 or later.
> - Clang 3.3 or later.
> 
> So if you are using an older version of the above compilers, or an
> entirely different compiler, please let us know.
> 

3 Compilers in use here (64 bits, intel processor):
* Intel icpc 17.0.4 (from intel parallel studio XE 2017 update 4, for Linux)
* Gnu g++ 6.3.0 (from ubuntu 17.04)
* Clang 4.0.0 (from ubuntu) 17.04)


> 
> The ultimate purpose of this survey is to determine which C++11 features
> might be safe to use in the POV-Ray source code.
> 

Did you known there is C++14 and ...
Winter is coming... no, C++17 is coming!

Post a reply to this message

Am 20.06.2017 um 22:39 schrieb Le_Forgeron:
>> More specifically, I'd like to know whether anyone is using something
>> *OTHER* than one of the following:
>>
>> - Microsoft Visual Studio 2015 or later.
>> - Gnu Compiler Collection 4.8.1 or later.
>> - Clang 3.3 or later.
>>
>> So if you are using an older version of the above compilers, or an
>> entirely different compiler, please let us know.
>>
> 
> 3 Compilers in use here (64 bits, intel processor):
> * Intel icpc 17.0.4 (from intel parallel studio XE 2017 update 4, for Linux)

Intel claims full C++11 support as of version 15.0, so that should be ok.

> * Gnu g++ 6.3.0 (from ubuntu 17.04)
> * Clang 4.0.0 (from ubuntu) 17.04)

They should certainly be fine.

>> The ultimate purpose of this survey is to determine which C++11 features
>> might be safe to use in the POV-Ray source code.
>>
> 
> Did you known there is C++14 and ...
> Winter is coming... no, C++17 is coming!

I am well aware of that. But C++14 is currently a no-go -- even if we
could rely on all of our users (those that want to run their own builds
at any rate) having access to a C++14-capable compiler, we're still
stuck with MSVC 2015, GCC 4.8.4 and clang 4.2 on the machines we run our
automated build tests on; of those, only clang will do a reasonable
subset of C++14. You do want us to run automated build tests, don't you? ;)

As a matter of fact, one of our automated build services (the one we
also happen to need to run our automated static code analysis) is still
running Ubuntu 12.04 by default, with GCC still at 4.6 and thus not even
C++11-complete. It was only recently that I learned that they do provide
14.04 images, but they still seem to flag them as beta.

Post a reply to this message

Povray compiles just fine on for me:

* FreeBSD 11 with Clang 3.8
* Ubuntu 16.04 with gcc 5.4.0
* Ubuntu running under Windows Subsystem for Linux

Post a reply to this message

Am 22.06.2017 um 00:52 schrieb jhu:
> Povray compiles just fine on for me:
> 
> * FreeBSD 11 with Clang 3.8
> * Ubuntu 16.04 with gcc 5.4.0
> * Ubuntu running under Windows Subsystem for Linux

The latter, too, would be GCC 5.4.0.

Post a reply to this message

On 06/20/2017 04:39 PM, Le_Forgeron wrote:
> Le 20/06/2017 à 16:27, clipka a écrit :
> 
> 3 Compilers in use here (64 bits, intel processor):
> * Intel icpc 17.0.4 (from intel parallel studio XE 2017 update 4, for Linux)
> * Gnu g++ 6.3.0 (from ubuntu 17.04)
> * Clang 4.0.0 (from ubuntu) 17.04)
> 
> 

Jérôme,
I was just playing around with libpng16 on Ubuntu 16.04 (normally uses 
libpng12) and I found moving to png16 removed my libsdl1.2 for some reason.

I see Ubuntu 17.04 is using libpng16 by default. Have you had any 
trouble with the sdl1.2 preview display on 17.04?

libsdl1.2 was updated too for 17.04 so I'm thinking things OK if 
releases aligned, but I couldn't see any updated directly related to 
libpng, so not sure.

Thanks for your time.
Bill P.

Post a reply to this message

Le 24/06/2017 à 14:08, William F Pokorny a écrit :
> On 06/20/2017 04:39 PM, Le_Forgeron wrote:
>> Le 20/06/2017 à 16:27, clipka a écrit :
>>
>> 3 Compilers in use here (64 bits, intel processor):
>> * Intel icpc 17.0.4 (from intel parallel studio XE 2017 update 4, for
>> Linux)
>> * Gnu g++ 6.3.0 (from ubuntu 17.04)
>> * Clang 4.0.0 (from ubuntu) 17.04)
>>
>>
> 
> Jérôme,
> I was just playing around with libpng16 on Ubuntu 16.04 (normally uses
> libpng12) and I found moving to png16 removed my libsdl1.2 for some reason.
> 
> I see Ubuntu 17.04 is using libpng16 by default. Have you had any
> trouble with the sdl1.2 preview display on 17.04?
> 
> libsdl1.2 was updated too for 17.04 so I'm thinking things OK if
> releases aligned, but I couldn't see any updated directly related to
> libpng, so not sure.
> 

So far, I have installed on my system:
libpng-dev (1.6.28-1)
libpng++-dev (0.2.9-1)
libsdl1.2-dev (1.2.15+dsfg1-4)
libsdl2-2.0-0 (2.0.5+dfsg1-2ubuntu3)

I do not see any direct conflict on the listed dependencies of
libsdl1.2-dev to libpng.

Interestingly, there is a libsdl2-dev which can be installed in parallel
to libsdl1.2-dev

I also have the libpng12-0 (as runtime), along with libpng16-16.

But I remember that upgrade of release usually try to remove a lot of
"unnecessary" packages, aka packages it does not see the need for... and
it is not good at it when you have locally compiled applications.


> Thanks for your time.
> Bill P.

Post a reply to this message

On 06/24/2017 02:16 PM, Le_Forgeron wrote:
> Le 24/06/2017 à 14:08, William F Pokorny a écrit :
>> On 06/20/2017 04:39 PM, Le_Forgeron wrote:
>>
>> Jérôme,
>> I was just playing around with libpng16 on Ubuntu 16.04 (normally uses
>> libpng12) and I found moving to png16 removed my libsdl1.2 for some reason.
>>
>> I see Ubuntu 17.04 is using libpng16 by default. Have you had any
>> trouble with the sdl1.2 preview display on 17.04?
>>
>> libsdl1.2 was updated too for 17.04 so I'm thinking things OK if
>> releases aligned, but I couldn't see any updated directly related to
>> libpng, so not sure.
>>
> 
> So far, I have installed on my system:
> libpng-dev (1.6.28-1)
> libpng++-dev (0.2.9-1)
> libsdl1.2-dev (1.2.15+dsfg1-4)
> libsdl2-2.0-0 (2.0.5+dfsg1-2ubuntu3)
> 
> I do not see any direct conflict on the listed dependencies of
> libsdl1.2-dev to libpng.

Good to know you have no issues having libsdl1.2-dev installed with 
png16. Your sdl1.2 version is the newer one. The one that got removed 
for me was 1.2.15+dsfg1-3.

> 
> Interestingly, there is a libsdl2-dev which can be installed in parallel
> to libsdl1.2-dev

Yes, I have this dual set up on my main Ubuntu 16.04 machine. SDL2 is a 
non-compatible alternative to the much older SDL1.2, so we cannot just 
switch to it. See: http://wiki.libsdl.org/MigrationGuide

I've have on my to-play-with list to try and update our code and build 
system to work with SDL2 - in addition to 1.2 initially. I've only 
managed to compile small sdl2 example programs thus far as I'm still 
learning c++ so we'll see.

With SDL2 it looks like we can probably do our 2D window display scaling 
with built in functions making use of the graphics hardware / gpu 
functionality instead of the custom c++ scaling code we have today.

SDL2: "Simple 2D rendering API that can use Direct3D, OpenGL, OpenGL ES, 
or software rendering behind the scenes"

> 
> I also have the libpng12-0 (as runtime), along with libpng16-16.
> 
> But I remember that upgrade of release usually try to remove a lot of
> "unnecessary" packages, aka packages it does not see the need for... and
> it is not good at it when you have locally compiled applications.
>

Post a reply to this message