Looks good to me.
/Magnus
> 7 apr 2015 kl. 17:21 skrev Erik Joelsson :
>
> (corrected subject)
>
>> On 2015-04-07 17:15, Erik Joelsson wrote:
>> Hello,
>>
>> When upgrading the toolchain to VS2013, management.dll stopped working on
>> certain Windows hosts. I've identified this to be related
Pete,
I think Erik's suggestion in the bug report is more appropriate. If this
is only a source bundle issue then the build instructions for javadoc
should either be Windows specific, or else check for source existence.
David
On 8/04/2015 3:51 PM, Pete Brunet wrote:
Please review/approve th
This API is only available on windows but not other platforms. I think
src/windows/classes is the right location.
Mandy
On 4/7/2015 10:51 PM, Pete Brunet wrote:
Please review/approve the following patch.
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
The recent push for JDK-807
Please review/approve the following patch.
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
The recent push for JDK-8076182 caused a build break, i.e. a problem for
the creation of the Javadoc in the environment used by the nightly
build. This was because a newly opened package
com.su
Looks good!
Thanks,
/Staffan
> On 7 apr 2015, at 17:15, Erik Joelsson wrote:
>
> Hello,
>
> When upgrading the toolchain to VS2013, management.dll stopped working on
> certain Windows hosts. I've identified this to be related to the call to
> GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1
Erik-
Looks good to me.
Tim
On 04/07/15 08:21, Erik Joelsson wrote:
(corrected subject)
On 2015-04-07 17:15, Erik Joelsson wrote:
Hello,
When upgrading the toolchain to VS2013, management.dll stopped
working on certain Windows hosts. I've identified this to be related
to the call to GetPr
Be careful placing older versions of Xcode in /Applications. I've had MAS
auto-update Xcode deleting old versions in the process.
-DrD-
> Pete, have you tried
> sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/
> ?
> It seems that the configure doesn't pick the correct path from th
Pete, have you tried
sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/
?
It seems that the configure doesn't pick the correct path from the
xcode-select.
Although I successfully built jdk8u on 10.10 with both xcode-select and
--with-xcode-path
BTW, the correct path for xcode-select
(corrected subject)
On 2015-04-07 17:15, Erik Joelsson wrote:
Hello,
When upgrading the toolchain to VS2013, management.dll stopped working
on certain Windows hosts. I've identified this to be related to the
call to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to CFLAGS,
the problem goe
Hello,
When upgrading the toolchain to VS2013, management.dll stopped working
on certain Windows hosts. I've identified this to be related to the call
to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to CFLAGS, the
problem goes away.
Bug: https://bugs.openjdk.java.net/browse/JDK-8076557
Hi, I need some help so I can build on MacOSX to fix a build break.
First since I had Xcode 6.1.1 and configure complained that I didn't
have v4 I installed v4.6.3. After installing 4.6.3 and doing
sudo xcode-select -s /Applications/Xcode\ 4.6.3.app/
I got past that. Then for some reason my comp
On 2015-04-02 15:05, Erik Joelsson wrote:
Our top level clean targets need some improvement.
* There is no clean-docs
* dist-clean does not remove everything configure creates on all
platforms
For the latter, moving a lot of the files generated by configure into
a separate sub dir of the out
Hello,
That's a fair point. We did aim for 2012 when trying to do this work for
JDK 8, but it hasn't been tried (at least not that I know) for a while
now. I agree that perhaps 2010 should be prioritized before 2012 since
it has been an official compiler. On the other hand, 2012 is much closer
13 matches
Mail list logo
