Hi Staffan,
Seems fine as a spot fix but I'm wondering if this shouldn't be a common
option for all the dlls now we are building with VS2013?
Thanks,
David
On 4/05/2015 4:52 PM, Staffan Larsen wrote:
This is a P1 bug that surfaced when changes from jdk9/dev and jdk9/hs-rt met in
jdk9/hs. In
> On 4 maj 2015, at 09:27, David Holmes wrote:
>
> Hi Staffan,
>
> Seems fine as a spot fix but I'm wondering if this shouldn't be a common
> option for all the dlls now we are building with VS2013?
I’ll let the build team comment on that.
/Staffan
>
> Thanks,
> David
>
> On 4/05/2015 4:5
> 4 maj 2015 kl. 09:27 skrev David Holmes :
>
> Hi Staffan,
>
> Seems fine as a spot fix but I'm wondering if this shouldn't be a common
> option for all the dlls now we are building with VS2013?
Or maybe as a define in the source code before the include section for the
specific source code t
> On 4 maj 2015, at 09:54, Magnus Ihse Bursie
> wrote:
>
>
>> 4 maj 2015 kl. 09:27 skrev David Holmes :
>>
>> Hi Staffan,
>>
>> Seems fine as a spot fix but I'm wondering if this shouldn't be a common
>> option for all the dlls now we are building with VS2013?
>
> Or maybe as a define in t
Hello,
I think this looks good enough. The flags handling is still a big mess
so even if there were a better place for this, I couldn't say where.
/Erik
On 2015-04-30 07:26, David Holmes wrote:
Hi Nevill,
Just realized this was sent to hotspot-dev (attempting bcc) but is not
a hotspot issu
On 2015-05-04 10:25, Staffan Larsen wrote:
On 4 maj 2015, at 09:54, Magnus Ihse Bursie
wrote:
4 maj 2015 kl. 09:27 skrev David Holmes :
Hi Staffan,
Seems fine as a spot fix but I'm wondering if this shouldn't be a common option
for all the dlls now we are building with VS2013?
Or maybe
Thanks for the reviews - the fix is now in the JPRT queue.
/Staffan
> On 4 maj 2015, at 11:11, Erik Joelsson wrote:
>
>
> On 2015-05-04 10:25, Staffan Larsen wrote:
>>> On 4 maj 2015, at 09:54, Magnus Ihse Bursie
>>> wrote:
>>>
>>>
4 maj 2015 kl. 09:27 skrev David Holmes :
Hello,
Please review this small patch to configure which enables building on
Cygwin 2.0 and newer. Instead of explicitly testing for all versions we
know work, I inverted the check to exclude the ones we know won't work.
Hitting a known bad Cygwin version should be very rare anyway since 1.7
Hello,
This bug has been marked as won't fix since the code it affects is going
to be removed. However, until that removal happens, we can't build using
VS2013 SP4. I'm in the process of updating the compilers used internally
at Oracle to that specific version and to be able to continue that w
Why not just for the library that needs it?
/Magnus
> 4 maj 2015 kl. 11:05 skrev Erik Joelsson :
>
> Hello,
>
> I think this looks good enough. The flags handling is still a big mess so
> even if there were a better place for this, I couldn't say where.
>
> /Erik
>
>> On 2015-04-30 07:26, Da
Right, that does make sense. This isn't a toolchain global flag like
some others we've had to deal with lately, but rather seems pretty
specific to the png code, or am I missing something? If that's the case,
then it's better added for the specific library.
/Erik
On 2015-05-04 16:43, Magnus I
Looks good!
Thanks,
/Staffan
> On 4 maj 2015, at 15:46, Erik Joelsson wrote:
>
> Hello,
>
> This bug has been marked as won't fix since the code it affects is going to
> be removed. However, until that removal happens, we can't build using VS2013
> SP4. I'm in the process of updating the com
Erik:
Looks good to me.
Tim
Please review this small patch to configure which enables building on
Cygwin 2.0 and newer. Instead of explicitly testing for all versions
we know work, I inverted the check to exclude the ones we know won't
work. Hitting a known bad Cygwin version should be very
Erik:
Looks good to me as well.
Tim
On 05/04/15 08:13, Staffan Larsen wrote:
Looks good!
Thanks,
/Staffan
On 4 maj 2015, at 15:46, Erik Joelsson wrote:
Hello,
This bug has been marked as won't fix since the code it affects is going to be
removed. However, until that removal happens, we
14 matches
Mail list logo
