RFR: JDK-8138694: Devkit build on Macosx still requires Xcode to be installed

[Erik Joelsson]

Hello,

While trying the macosx build using devkits again, I happened to be on a 
system where some Xcode install/update error had left the /usr/include 
directory missing. This shouldn't be an issue since we have all the 
necessary include files in the SDK inside the devkit/Xcode application.


Getting this to work required several changes and cleanups that will 
actually improve build consistency overall. It will also guarantee that 
we use the correct system headers in all cases.


* Setup SYSROOT_*FLAGS before detecting toolchain and make those flags 
available to the configure toolchain tests.
* Setup the user supplied extra flags before toolchain detection so that 
those are also used during configure toolchain tests.
* When not cross compiling, use the SYSROOT_*FLAGS also when compiling 
build tools, like adlc in hotspot, and gensrc tools in jdk.


Bug: https://bugs.openjdk.java.net/browse/JDK-8138694
Webrev: http://cr.openjdk.java.net/~erikj/8138694/webrev.top.01/

/Erik

RFR: JDK-8138739: Enable devkit on macosx in JPRT (again)

[Erik Joelsson]

Hello,

Please review this minor fix to the jprt configuration, which again 
enables the use of devkits for macosx.


This will be pushed to jdk9/client as that's where the final fixes 
needed for this are gathered.


Bug: https://bugs.openjdk.java.net/browse/JDK-8138739
Patch:
diff -r 1e64ec3d1c60 make/jprt.properties
--- a/make/jprt.properties
+++ b/make/jprt.properties
@@ -127,6 +127,8 @@
 ${jprt.i586.build.configure.args}
 jprt.windows_x64.build.configure.args=\
 --with-devkit=$VS2013_HOME
+jprt.macosx_x64.build.configure.args=\
+--with-devkit=$XCODE_511_HOME

 
 #

RFR: JDK-8138761 Improved handling of libffi, and cleanup of libraries.m4

[Magnus Ihse Bursie]

To build zero, we need libffi. However, the code in configure to handle 
libffi is not up to normal library handling standards, so it is not 
possible to set it using configure arguments.


When trying to rectify this, I finally got tired of the mess that 
libraries.m4 is. I have split it into parts, where each prominent 
library gets it's own file, and I've switched the logic on dependencies 
to be positive (i.e. linux needs alsa, not "macosx does NOT need alsa").


The cleanup includes:
* Split libraries.m4.
* Remove builddeps.
* Remove last references to pulse.
* Remove HAVE_ALTZONE.
* Separate handling of bundled libs.
* Set LIBM properly.

The libffi support means that we now have --with-libffi[-libs/-include], 
just like for other libraries. Also, we sanity check that we can 
actually compile with libffi.


Bug: https://bugs.openjdk.java.net/browse/JDK-8138761
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8138761-libffi-and-libraries-cleanup/webrev.01


/Magnus

Re: RFR: JDK-8138694: Devkit build on Macosx still requires Xcode to be installed

[Magnus Ihse Bursie]

On 2015-10-02 15:34, Erik Joelsson wrote:

Hello,

While trying the macosx build using devkits again, I happened to be on 
a system where some Xcode install/update error had left the 
/usr/include directory missing. This shouldn't be an issue since we 
have all the necessary include files in the SDK inside the 
devkit/Xcode application.


Getting this to work required several changes and cleanups that will 
actually improve build consistency overall. It will also guarantee 
that we use the correct system headers in all cases.


* Setup SYSROOT_*FLAGS before detecting toolchain and make those flags 
available to the configure toolchain tests.
* Setup the user supplied extra flags before toolchain detection so 
that those are also used during configure toolchain tests.
* When not cross compiling, use the SYSROOT_*FLAGS also when compiling 
build tools, like adlc in hotspot, and gensrc tools in jdk.


Bug: https://bugs.openjdk.java.net/browse/JDK-8138694
Webrev: http://cr.openjdk.java.net/~erikj/8138694/webrev.top.01/


Your changes looks good. However, I notice that there is a problem with 
the code that you moved. In FLAGS_SETUP_SYSROOT_FLAGS, there is a test:


elif test "x$OPENJDK_TARGET_OS" = xmacosx; then
# Apple only wants -isysroot , but we also need 
-iframework/System/Library/Frameworks
SYSROOT_CFLAGS="-isysroot $SYSROOT -iframework 
$SYSROOT/System/Library/Frameworks"

SYSROOT_LDFLAGS=$SYSROOT_CFLAGS

but this is incorrect. Remove this and instead add the -iframework stuff 
at the end. There is already a macosx test for adding framework flags, 
the -iframework addition fits in perfect there.


/Magnus

Re: RFR: JDK-8138739: Enable devkit on macosx in JPRT (again)

[Magnus Ihse Bursie]

On 2015-10-02 10:13, Erik Joelsson wrote:

Hello,

Please review this minor fix to the jprt configuration, which again 
enables the use of devkits for macosx.


This will be pushed to jdk9/client as that's where the final fixes 
needed for this are gathered.


Bug: https://bugs.openjdk.java.net/browse/JDK-8138739
Patch:
diff -r 1e64ec3d1c60 make/jprt.properties
--- a/make/jprt.properties
+++ b/make/jprt.properties
@@ -127,6 +127,8 @@
 ${jprt.i586.build.configure.args}
 jprt.windows_x64.build.configure.args=\
 --with-devkit=$VS2013_HOME
+jprt.macosx_x64.build.configure.args=\
+--with-devkit=$XCODE_511_HOME

 
 #



Woho! :-D Ship it.

/Magnus

RFR 8133151: Preferred provider configuration for JCE

[Anthony Scarpino]

Hi all,

I'm need a review of the last developement piece to JEP 246, the 
configuration changes.


I've copied the build-dev in case there were any comments on the minor 
changes in the make directory related to the java.security file.


http://cr.openjdk.java.net/~ascarpino/8133151/webrev/

thanks

Tony

Re: Building Valhalla

[Maurizio Cimadamore]

I believe this has been caused by the latest push...

try doing:

make jimages

afaik that should not run the last verification step ;-)

Maurizio

On 02/10/15 20:59, Mani Sarkar wrote:

Hi guys,

I get the below build error half way through build the valhalla build of
OpenJDK:










*ERROR: Failed module access verificationgmake[3]: *** [checkdeps] Error
1gmake[3]: Leaving directory
`'>gmake[2]:
*** [verify-modules] Error 1gmake[2]: Leaving directory
`'>make[1]:
*** [main] Error 1make[1]: Leaving directory
`'>make:
*** [images] Error 2Build step 'Execute shell' marked build as
failureArchiving artifacts*

Here's the link to the detailed logs -
https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/project-valhalla-OpenJDK/3/consoleFull

Whats the fix to the verify modules issue ? Any flags that would help ?
There are a number of errors like "inaccessible reference:
valhalla.model3.Model3Converter (java.base) ->
com.sun.tools.classfile.AccessFlags (jdk.compiler)".

For your info, I'm building from the
http://hg.openjdk.java.net/valhalla/valhalla/
 repo.

Cheers,
Mani

Building Valhalla

[Mani Sarkar]

Hi guys,

I get the below build error half way through build the valhalla build of
OpenJDK:










*ERROR: Failed module access verificationgmake[3]: *** [checkdeps] Error
1gmake[3]: Leaving directory
`'>gmake[2]:
*** [verify-modules] Error 1gmake[2]: Leaving directory
`'>make[1]:
*** [main] Error 1make[1]: Leaving directory
`'>make:
*** [images] Error 2Build step 'Execute shell' marked build as
failureArchiving artifacts*

Here's the link to the detailed logs -
https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/project-valhalla-OpenJDK/3/consoleFull

Whats the fix to the verify modules issue ? Any flags that would help ?
There are a number of errors like "inaccessible reference:
valhalla.model3.Model3Converter (java.base) ->
com.sun.tools.classfile.AccessFlags (jdk.compiler)".

For your info, I'm building from the
http://hg.openjdk.java.net/valhalla/valhalla/
 repo.

Cheers,
Mani

-- 
@theNeomatrix369 *  |  **Blog
**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
*  |  **Bitbucket
* * |  **Github
* * |  **LinkedIn
*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

Re: Building Valhalla

[Mani Sarkar]

Maurizio,

Thanks for the suggestion - would it build the much useful JRE and JDK
images ?

Cheers,
Mani

On Fri, Oct 2, 2015 at 9:36 PM, Maurizio Cimadamore <
maurizio.cimadam...@oracle.com> wrote:

> I believe this has been caused by the latest push...
>
> try doing:
>
> make jimages
>
> afaik that should not run the last verification step ;-)
>
> Maurizio
>
> On 02/10/15 20:59, Mani Sarkar wrote:
>
>> Hi guys,
>>
>> I get the below build error half way through build the valhalla build of
>> OpenJDK:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *ERROR: Failed module access verificationgmake[3]: *** [checkdeps] Error
>> 1gmake[3]: Leaving directory
>> `<
>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla/make
>> <
>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla/make
>> >'>gmake[2]:
>> *** [verify-modules] Error 1gmake[2]: Leaving directory
>> `<
>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla
>> <
>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla
>> >'>make[1]:
>> *** [main] Error 1make[1]: Leaving directory
>> `<
>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla
>> <
>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla
>> >'>make:
>> *** [images] Error 2Build step 'Execute shell' marked build as
>> failureArchiving artifacts*
>>
>> Here's the link to the detailed logs -
>>
>> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/project-valhalla-OpenJDK/3/consoleFull
>>
>> Whats the fix to the verify modules issue ? Any flags that would help ?
>> There are a number of errors like "inaccessible reference:
>> valhalla.model3.Model3Converter (java.base) ->
>> com.sun.tools.classfile.AccessFlags (jdk.compiler)".
>>
>> For your info, I'm building from the
>> http://hg.openjdk.java.net/valhalla/valhalla/
>>  repo.
>>
>> Cheers,
>> Mani
>>
>>
>


-- 
@theNeomatrix369 *  |  **Blog
**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
*  |  **Bitbucket
* * |  **Github
* * |  **LinkedIn
*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*