Building SPARC CPU code for Zero

[John Paul Adrian Glaubitz]

Hi!

I am currently working on fixing JDK-8186578:

   Zero fails to build on linux-sparc due to sparc-specific code

One necessary change to be able to fix this bug is to build the
SPARC-specific source memset_with_concurrent_readers_sparc.cpp on
Zero as well. This is necessary because on SPARC, we have to use
the custom implementation of memset() to be able to have a working
memset_with_concurrent_readers, the glibc version doesn't work in
this case.

Now, my first suggested way of addressing this problem was to move
memset_with_concurrent_readers_sparc.cpp into the same location
as memset_with_concurrent_readers.hpp and just make the code in
the former compilation unit conditional so it's built on SPARC
only [1].

Unfortunately, this proposed change was rejected due to the fact
that it moves SPARC code into a generic location. So, I'm now looking
for a way to tell the build system to build memset_with_concurrent_\
readers_sparc.cpp when building Zero if SPARC is defined.

Can any build wizard shed some light on this and say whether it's
possible to achieve that?

Adrian


[1] http://cr.openjdk.java.net/~glaubitz/8186578/webrev.00/


--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: CompileJavaModule.gmk overrides values from a custom extension gmk

[Erik Joelsson]

If you have signed the OCA, you can post your proposed change here and I 
or someone else will sponsor it once we agree that it looks good.


/Erik


On 2017-08-30 14:27, Jason Yong wrote:

Thanks Eric,

Is the next step is to get a sponsor for the change or should I post 
my proposed change first?


Jason

Regards,

*Jason Yong*
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud



*Phone:*44-1962-815256*
E-mail:*_yon...@uk.ibm.com_ *
Find me on:*LinkedIn: http://uk.linkedin.com/pub/jason-yong/90/998/b22 
*and within IBM 
on:*IBM Connections: 
https://w3-connections.ibm.com/profiles/html/profileView.do?key=acdaa606-99cf-4e69-bdd5-2ea7f0396035 
 


IBM

Hursley Park
Hursley, SO212JN
United Kingdom







From: Erik Joelsson 
To: Jason Yong , build-dev@openjdk.java.net
Date: 29/08/2017 12:55
Subject: Re: CompileJavaModule.gmk overrides values from a custom 
extension gmk





Hello Jason,

Your suggestion makes sense. The only reason these variables have :=
today is that we (at Oracle) haven't had a need for appending to those
particular variables (yet).

/Erik


On 2017-08-29 11:31, Jason Yong wrote:
> Hello,
>
> I've had an issue where I've had a custom extension to 
CompileJavaModules.gmk with the variable java.base_COPY set to files 
that I wanted to be copied across but its value was overwritten by 
CompileJavaModules.gmk.

>
> I would like to propose changes that would allow a custom extensions 
to update variables listed in CompileJavaModules.gmk. This issue is 
similar to bug JDK-8064372 
(https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8064372&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_pd0JudnAMtzyOP3NkOCP7ozDRbZ9ukki8lLmogKLJI&m=qG_YEjgXnzBfNvN5ztSbjIVP3nZ5SaZCibl7SHJjTfc&s=2mMmeC6jKTJu1OgK0Lssib1LKQvOFX3BwzIcJAebSeU&e=) 
but affects all the other variables such as:

>
> java.activation_SETUP
> java.base_ADD_JAVAC_FLAGS
> java.base_COPY
> java.base_CLEAN
> etc
>
> The fix is also similar, changing := to += allowing the custom 
extension to append to the variable if already set and create it if 
its not.
> I would appreciate any feedback and help on what the next steps 
would be.

>
> Thanks
>
> Jason
>
>
> Jason Yong
> CEng MEng MIET
> Software Engineer, IBM Runtime Technologies
> IBM Hybrid Cloud
> Phone: 44-1962-815256
> E-mail: yon...@uk.ibm.com
> Find me on:  and within IBM on:
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
PO6 3AU

>




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with 
number 741598.

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: Building SPARC CPU code for Zero

[Magnus Ihse Bursie]

On 2017-08-30 14:02, John Paul Adrian Glaubitz wrote:

Hi!

I am currently working on fixing JDK-8186578:

   Zero fails to build on linux-sparc due to sparc-specific code

One necessary change to be able to fix this bug is to build the
SPARC-specific source memset_with_concurrent_readers_sparc.cpp on
Zero as well. This is necessary because on SPARC, we have to use
the custom implementation of memset() to be able to have a working
memset_with_concurrent_readers, the glibc version doesn't work in
this case.

Now, my first suggested way of addressing this problem was to move
memset_with_concurrent_readers_sparc.cpp into the same location
as memset_with_concurrent_readers.hpp and just make the code in
the former compilation unit conditional so it's built on SPARC
only [1].

Unfortunately, this proposed change was rejected due to the fact
that it moves SPARC code into a generic location. So, I'm now looking
for a way to tell the build system to build memset_with_concurrent_\
readers_sparc.cpp when building Zero if SPARC is defined.

Can any build wizard shed some light on this and say whether it's
possible to achieve that?


I'm sure it's *possible*. I'm also fairly certain it will be messy. :)

Unfortunately, the usage of various defines in presence of zero seems 
not very well defined. That is, should SPARC be defined alongside ZERO, 
or should it not be defined when ZERO is defined, if building zero on sparc.


The current effect, if I remember correctly, is that both ZERO and SPARC 
are defined if building zero on sparc, but only SPARC if building a 
"normal" sparc build. There is also a ZERO_LIBARCH, but I fail to 
understand the purpose of this.


But your problem seems to be that the file itself is not included. I'm 
not sure how the hotspot include logic determines which platform 
specific files to include. Possibly they have a "and !definied(ZERO)" in 
the logic.


/Magnus



Adrian


[1] http://cr.openjdk.java.net/~glaubitz/8186578/webrev.00/

Re: Building SPARC CPU code for Zero

[Magnus Ihse Bursie]

On 2017-08-30 15:22, Magnus Ihse Bursie wrote:

On 2017-08-30 14:02, John Paul Adrian Glaubitz wrote:

Hi!

I am currently working on fixing JDK-8186578:

   Zero fails to build on linux-sparc due to sparc-specific code

One necessary change to be able to fix this bug is to build the
SPARC-specific source memset_with_concurrent_readers_sparc.cpp on
Zero as well. This is necessary because on SPARC, we have to use
the custom implementation of memset() to be able to have a working
memset_with_concurrent_readers, the glibc version doesn't work in
this case.

Now, my first suggested way of addressing this problem was to move
memset_with_concurrent_readers_sparc.cpp into the same location
as memset_with_concurrent_readers.hpp and just make the code in
the former compilation unit conditional so it's built on SPARC
only [1].

Unfortunately, this proposed change was rejected due to the fact
that it moves SPARC code into a generic location. So, I'm now looking
for a way to tell the build system to build memset_with_concurrent_\
readers_sparc.cpp when building Zero if SPARC is defined.

Can any build wizard shed some light on this and say whether it's
possible to achieve that?


I'm sure it's *possible*. I'm also fairly certain it will be messy. :)

Unfortunately, the usage of various defines in presence of zero seems 
not very well defined. That is, should SPARC be defined alongside 
ZERO, or should it not be defined when ZERO is defined, if building 
zero on sparc.


The current effect, if I remember correctly, is that both ZERO and 
SPARC are defined if building zero on sparc, but only SPARC if 
building a "normal" sparc build. There is also a ZERO_LIBARCH, but I 
fail to understand the purpose of this.


But your problem seems to be that the file itself is not included. I'm 
not sure how the hotspot include logic determines which platform 
specific files to include. Possibly they have a "and !definied(ZERO)" 
in the logic.

Aha, now I see. It's a .cpp file in cpu/sparc. Hm.

Would it be painful to duplicate the function in cpu/zero? I realize 
this is not elegant, but we don't have a good story for sharing 
platform-specific functionality with zero. :(


/Magnus




/Magnus



Adrian


[1] http://cr.openjdk.java.net/~glaubitz/8186578/webrev.00/

Re: Building SPARC CPU code for Zero

[John Paul Adrian Glaubitz]

On 08/30/2017 03:22 PM, Magnus Ihse Bursie wrote:

I'm sure it's *possible*. I'm also fairly certain it will be messy. :)


I already guess that.


Unfortunately, the usage of various defines in presence of zero seems
not very well defined. That is, should SPARC be defined alongside ZERO,
or should it not be defined when ZERO is defined, if building zero on sparc.


As far as I know, VAR_CPU is always defined, independent of the build type.


The current effect, if I remember correctly, is that both ZERO and SPARC
are defined if building zero on sparc, but only SPARC if building a "normal"
sparc build.


That's what I observed as well.


There is also a ZERO_LIBARCH, but I fail to understand the
purpose of this.


I see.


But your problem seems to be that the file itself is not included. I'm not
sure how the hotspot include logic determines which platform specific files
to include. Possibly they have a "and !definied(ZERO)" in the logic.

It's actually a .cpp file as you mentioned in your second mail. I was already
pondering converting the file to a header file and then including it. However,
the specific path where the SPARC-version of memset is located is not accessible
on Zero due to a missing -I directive.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Building SPARC CPU code for Zero

[John Paul Adrian Glaubitz]

On 08/30/2017 03:25 PM, Magnus Ihse Bursie wrote:

Would it be painful to duplicate the function in cpu/zero? I realize this
is not elegant, but we don't have a good story for sharing platform-specific
functionality with zero. :(


But then we could also just move it into src/share/vm/gc/shared/, couldn't we?

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: CompileJavaModule.gmk overrides values from a custom extension gmk

[Jason Yong]

Hi Eric,

With regards to the OCA I believe IBM has signed a contributors agreement 
which should cover me for that.


So here's the mercurial export of the CompileJavaModule.java with my 
changes in




Regards,


Jason Yong

CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:  


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 13:47
Subject:Re: CompileJavaModule.gmk overrides values from a custom 
extension gmk



If you have signed the OCA, you can post your proposed change here and I 
or someone else will sponsor it once we agree that it looks good.
/Erik

On 2017-08-30 14:27, Jason Yong wrote:
Thanks Eric, 

Is the next step is to get a sponsor for the change or should I post my 
proposed change first? 

Jason 

Regards, 

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:   


Hursley Park
Hursley, SO212JN
United Kingdom






From:Erik Joelsson  
To:Jason Yong , build-dev@openjdk.java.net 
Date:29/08/2017 12:55 
Subject:Re: CompileJavaModule.gmk overrides values from a custom 
extension gmk 



Hello Jason,

Your suggestion makes sense. The only reason these variables have := 
today is that we (at Oracle) haven't had a need for appending to those 
particular variables (yet).

/Erik


On 2017-08-29 11:31, Jason Yong wrote:
> Hello,
>   
> I've had an issue where I've had a custom extension to 
CompileJavaModules.gmk with the variable java.base_COPY set to files that 
I wanted to be copied across but its value was overwritten by 
CompileJavaModules.gmk.
>   
> I would like to propose changes that would allow a custom extensions to 
update variables listed in CompileJavaModules.gmk. This issue is similar 
to bug JDK-8064372 (
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8064372&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_pd0JudnAMtzyOP3NkOCP7ozDRbZ9ukki8lLmogKLJI&m=qG_YEjgXnzBfNvN5ztSbjIVP3nZ5SaZCibl7SHJjTfc&s=2mMmeC6jKTJu1OgK0Lssib1LKQvOFX3BwzIcJAebSeU&e=
 
) but affects all the other variables such as:
>   
> java.activation_SETUP
> java.base_ADD_JAVAC_FLAGS
> java.base_COPY
> java.base_CLEAN
> etc
>   
> The fix is also similar, changing := to += allowing the custom extension 
to append to the variable if already set and create it if its not.
> I would appreciate any feedback and help on what the next steps would 
be.
>
> Thanks
>
> Jason
>
>
> Jason Yong
> CEng MEng MIET
> Software Engineer, IBM Runtime Technologies
> IBM Hybrid Cloud
> Phone: 44-1962-815256
> E-mail: yon...@uk.ibm.com
> Find me on:  and within IBM on:
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
>




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: CompileJavaModule.gmk overrides values from a custom extension gmk

[Erik Joelsson]

Hello,

Changing the assignment on COPY, CLEAN and FLAGS variables makes sense, 
but please revert the SETUP variables as those are not lists but single 
value types.


Otherwise this looks good to me.

/Erik


On 2017-08-30 15:37, Jason Yong wrote:

Hi Eric,

With regards to the OCA I believe IBM has signed a contributors agreement
which should cover me for that.


So here's the mercurial export of the CompileJavaModule.java with my
changes in




Regards,


Jason Yong

CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 13:47
Subject:Re: CompileJavaModule.gmk overrides values from a custom
extension gmk



If you have signed the OCA, you can post your proposed change here and I
or someone else will sponsor it once we agree that it looks good.
/Erik

On 2017-08-30 14:27, Jason Yong wrote:
Thanks Eric,

Is the next step is to get a sponsor for the change or should I post my
proposed change first?

Jason

Regards,

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom






From:Erik Joelsson 
To:Jason Yong , build-dev@openjdk.java.net
Date:29/08/2017 12:55
Subject:Re: CompileJavaModule.gmk overrides values from a custom
extension gmk



Hello Jason,

Your suggestion makes sense. The only reason these variables have :=
today is that we (at Oracle) haven't had a need for appending to those
particular variables (yet).

/Erik


On 2017-08-29 11:31, Jason Yong wrote:

Hello,
   
I've had an issue where I've had a custom extension to

CompileJavaModules.gmk with the variable java.base_COPY set to files that
I wanted to be copied across but its value was overwritten by
CompileJavaModules.gmk.
   
I would like to propose changes that would allow a custom extensions to

update variables listed in CompileJavaModules.gmk. This issue is similar
to bug JDK-8064372 (
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8064372&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_pd0JudnAMtzyOP3NkOCP7ozDRbZ9ukki8lLmogKLJI&m=qG_YEjgXnzBfNvN5ztSbjIVP3nZ5SaZCibl7SHJjTfc&s=2mMmeC6jKTJu1OgK0Lssib1LKQvOFX3BwzIcJAebSeU&e=
) but affects all the other variables such as:
   
java.activation_SETUP

java.base_ADD_JAVAC_FLAGS
java.base_COPY
java.base_CLEAN
etc
   
The fix is also similar, changing := to += allowing the custom extension

to append to the variable if already set and create it if its not.

I would appreciate any feedback and help on what the next steps would

be.

Thanks

Jason


Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtime Technologies
IBM Hybrid Cloud
Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number

741598.

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6

3AU



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: CompileJavaModule.gmk overrides values from a custom extension gmk

[Jason Yong]

Hi Eric,

I've removed the SETUP changes as requested...



On a side note, I noticed that the attachment got stripped out in the post 
to the mailing list. Should I actually be copying and pasting the entire 
diff in the message? Its a couple of hundred lines... or is somewhere to 
put the attachment? 


Regards,

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:  


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 14:43
Subject:Re: CompileJavaModule.gmk overrides values from a custom 
extension gmk



Hello,

Changing the assignment on COPY, CLEAN and FLAGS variables makes sense, 
but please revert the SETUP variables as those are not lists but single 
value types.

Otherwise this looks good to me.

/Erik


On 2017-08-30 15:37, Jason Yong wrote:
> Hi Eric,
>
> With regards to the OCA I believe IBM has signed a contributors 
agreement
> which should cover me for that.
>
>
> So here's the mercurial export of the CompileJavaModule.java with my
> changes in
>
>
>
>
> Regards,
>
>
> Jason Yong
>
> CEng MEng MIET
> Software Engineer, IBM Runtimes Technology
> IBM Hybrid Cloud
>
>
> Phone: 44-1962-815256
> E-mail: yon...@uk.ibm.com
> Find me on:  and within IBM on:
>
>
> Hursley Park
> Hursley, SO212JN
> United Kingdom
>
>
>
>
>
> From:   Erik Joelsson 
> To: Jason Yong 
> Cc: build-dev@openjdk.java.net
> Date:   30/08/2017 13:47
> Subject:Re: CompileJavaModule.gmk overrides values from a custom
> extension gmk
>
>
>
> If you have signed the OCA, you can post your proposed change here and I
> or someone else will sponsor it once we agree that it looks good.
> /Erik
>
> On 2017-08-30 14:27, Jason Yong wrote:
> Thanks Eric,
>
> Is the next step is to get a sponsor for the change or should I post my
> proposed change first?
>
> Jason
>
> Regards,
>
> Jason Yong
> CEng MEng MIET
> Software Engineer, IBM Runtimes Technology
> IBM Hybrid Cloud
>
>
> Phone: 44-1962-815256
> E-mail: yon...@uk.ibm.com
> Find me on:  and within IBM on:
>
>
> Hursley Park
> Hursley, SO212JN
> United Kingdom
>
>
>
>
>
>
> From:Erik Joelsson 
> To:Jason Yong , 
build-dev@openjdk.java.net
> Date:29/08/2017 12:55
> Subject:Re: CompileJavaModule.gmk overrides values from a custom
> extension gmk
>
>
>
> Hello Jason,
>
> Your suggestion makes sense. The only reason these variables have :=
> today is that we (at Oracle) haven't had a need for appending to those
> particular variables (yet).
>
> /Erik
>
>
> On 2017-08-29 11:31, Jason Yong wrote:
>> Hello,
>> 
>> I've had an issue where I've had a custom extension to
> CompileJavaModules.gmk with the variable java.base_COPY set to files 
that
> I wanted to be copied across but its value was overwritten by
> CompileJavaModules.gmk.
>> 
>> I would like to propose changes that would allow a custom extensions to
> update variables listed in CompileJavaModules.gmk. This issue is similar
> to bug JDK-8064372 (
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8064372&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_pd0JudnAMtzyOP3NkOCP7ozDRbZ9ukki8lLmogKLJI&m=qG_YEjgXnzBfNvN5ztSbjIVP3nZ5SaZCibl7SHJjTfc&s=2mMmeC6jKTJu1OgK0Lssib1LKQvOFX3BwzIcJAebSeU&e=

> ) but affects all the other variables such as:
>> 
>> java.activation_SETUP
>> java.base_ADD_JAVAC_FLAGS
>> java.base_COPY
>> java.base_CLEAN
>> etc
>> 
>> The fix is also similar, changing := to += allowing the custom 
extension
> to append to the variable if already set and create it if its not.
>> I would appreciate any feedback and help on what the next steps would
> be.
>> Thanks
>>
>> Jason
>>
>>
>> Jason Yong
>> CEng MEng MIET
>> Software Engineer, IBM Runtime Technologies
>> IBM Hybrid Cloud
>> Phone: 44-1962-815256
>> E-mail: yon...@uk.ibm.com
>> Find me on:  and within IBM on:
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with 
number
> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: CompileJavaModule.gmk overrides values from a custom extension gmk

[Erik Joelsson]

Hello Jason,

I took the liberty of creating an issue for this: 
https://bugs.openjdk.java.net/browse/JDK-8186983


The mailing list server removes attachments. This makes it difficult for 
new people to send in their patches until they have an openjdk user so 
they can upload to cr.openjdk.java.net. Since you addressed the mail 
directly to me as well, I received the attachment and have created a 
webrev from it here:


http://cr.openjdk.java.net/~erikj/8186983/webrev.01/

I think the patch looks good now, but will leave it here until tomorrow 
to give other reviewers a chance to look at.


/Erik


On 2017-08-30 16:20, Jason Yong wrote:

Hi Eric,

I've removed the SETUP changes as requested...



On a side note, I noticed that the attachment got stripped out in the post
to the mailing list. Should I actually be copying and pasting the entire
diff in the message? Its a couple of hundred lines... or is somewhere to
put the attachment?


Regards,

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 14:43
Subject:Re: CompileJavaModule.gmk overrides values from a custom
extension gmk



Hello,

Changing the assignment on COPY, CLEAN and FLAGS variables makes sense,
but please revert the SETUP variables as those are not lists but single
value types.

Otherwise this looks good to me.

/Erik


On 2017-08-30 15:37, Jason Yong wrote:

Hi Eric,

With regards to the OCA I believe IBM has signed a contributors

agreement

which should cover me for that.


So here's the mercurial export of the CompileJavaModule.java with my
changes in




Regards,


Jason Yong

CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 13:47
Subject:Re: CompileJavaModule.gmk overrides values from a custom
extension gmk



If you have signed the OCA, you can post your proposed change here and I
or someone else will sponsor it once we agree that it looks good.
/Erik

On 2017-08-30 14:27, Jason Yong wrote:
Thanks Eric,

Is the next step is to get a sponsor for the change or should I post my
proposed change first?

Jason

Regards,

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom






From:Erik Joelsson 
To:Jason Yong ,

build-dev@openjdk.java.net

Date:29/08/2017 12:55
Subject:Re: CompileJavaModule.gmk overrides values from a custom
extension gmk



Hello Jason,

Your suggestion makes sense. The only reason these variables have :=
today is that we (at Oracle) haven't had a need for appending to those
particular variables (yet).

/Erik


On 2017-08-29 11:31, Jason Yong wrote:

Hello,

I've had an issue where I've had a custom extension to

CompileJavaModules.gmk with the variable java.base_COPY set to files

that

I wanted to be copied across but its value was overwritten by
CompileJavaModules.gmk.

I would like to propose changes that would allow a custom extensions to

update variables listed in CompileJavaModules.gmk. This issue is similar
to bug JDK-8064372 (


https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8064372&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_pd0JudnAMtzyOP3NkOCP7ozDRbZ9ukki8lLmogKLJI&m=qG_YEjgXnzBfNvN5ztSbjIVP3nZ5SaZCibl7SHJjTfc&s=2mMmeC6jKTJu1OgK0Lssib1LKQvOFX3BwzIcJAebSeU&e=


) but affects all the other variables such as:

java.activation_SETUP
java.base_ADD_JAVAC_FLAGS
java.base_COPY
java.base_CLEAN
etc

The fix is also similar, changing := to += allowing the custom

extension

to append to the variable if already set and create it if its not.

I would appreciate any feedback and help on what the next steps would

be.

Thanks

Jason


Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtime Technologies
IBM Hybrid Cloud
Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with

number

741598.

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6

3AU



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6

3AU



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6

3AU




Unl

Re: CompileJavaModule.gmk overrides values from a custom extension gmk

[Gary Adams]

Is the expectation that all of the := will be changed to += for these 
variables?


 468 jdk.internal.vm.ci_ADD_JAVAC_FLAGS := -parameters -Xlint:-exports 
-XDstringConcat=inline

Do the closed makefiles also need to be updated?

On 8/30/17, 10:36 AM, Erik Joelsson wrote:

Hello Jason,

I took the liberty of creating an issue for this: 
https://bugs.openjdk.java.net/browse/JDK-8186983


The mailing list server removes attachments. This makes it difficult 
for new people to send in their patches until they have an openjdk 
user so they can upload to cr.openjdk.java.net. Since you addressed 
the mail directly to me as well, I received the attachment and have 
created a webrev from it here:


http://cr.openjdk.java.net/~erikj/8186983/webrev.01/

I think the patch looks good now, but will leave it here until 
tomorrow to give other reviewers a chance to look at.


/Erik


On 2017-08-30 16:20, Jason Yong wrote:

Hi Eric,

I've removed the SETUP changes as requested...



On a side note, I noticed that the attachment got stripped out in the 
post

to the mailing list. Should I actually be copying and pasting the entire
diff in the message? Its a couple of hundred lines... or is somewhere to
put the attachment?


Regards,

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 14:43
Subject:Re: CompileJavaModule.gmk overrides values from a custom
extension gmk



Hello,

Changing the assignment on COPY, CLEAN and FLAGS variables makes sense,
but please revert the SETUP variables as those are not lists but single
value types.

Otherwise this looks good to me.

/Erik


On 2017-08-30 15:37, Jason Yong wrote:

Hi Eric,

With regards to the OCA I believe IBM has signed a contributors

agreement

which should cover me for that.


So here's the mercurial export of the CompileJavaModule.java with my
changes in




Regards,


Jason Yong

CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 13:47
Subject:Re: CompileJavaModule.gmk overrides values from a 
custom

extension gmk



If you have signed the OCA, you can post your proposed change here 
and I

or someone else will sponsor it once we agree that it looks good.
/Erik

On 2017-08-30 14:27, Jason Yong wrote:
Thanks Eric,

Is the next step is to get a sponsor for the change or should I post my
proposed change first?

Jason

Regards,

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom






From:Erik Joelsson 
To:Jason Yong ,

build-dev@openjdk.java.net

Date:29/08/2017 12:55
Subject:Re: CompileJavaModule.gmk overrides values from a 
custom

extension gmk



Hello Jason,

Your suggestion makes sense. The only reason these variables have :=
today is that we (at Oracle) haven't had a need for appending to those
particular variables (yet).

/Erik


On 2017-08-29 11:31, Jason Yong wrote:

Hello,

I've had an issue where I've had a custom extension to

CompileJavaModules.gmk with the variable java.base_COPY set to files

that

I wanted to be copied across but its value was overwritten by
CompileJavaModules.gmk.
I would like to propose changes that would allow a custom 
extensions to
update variables listed in CompileJavaModules.gmk. This issue is 
similar

to bug JDK-8064372 (

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8064372&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_pd0JudnAMtzyOP3NkOCP7ozDRbZ9ukki8lLmogKLJI&m=qG_YEjgXnzBfNvN5ztSbjIVP3nZ5SaZCibl7SHJjTfc&s=2mMmeC6jKTJu1OgK0Lssib1LKQvOFX3BwzIcJAebSeU&e= 




) but affects all the other variables such as:

java.activation_SETUP
java.base_ADD_JAVAC_FLAGS
java.base_COPY
java.base_CLEAN
etc

The fix is also similar, changing := to += allowing the custom

extension

to append to the variable if already set and create it if its not.

I would appreciate any feedback and help on what the next steps would

be.

Thanks

Jason


Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtime Technologies
IBM Hybrid Cloud
Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with

number

741598.

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6

3AU



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with 
numb

Re: CompileJavaModule.gmk overrides values from a custom extension gmk

[Erik Joelsson]

Hello,


On 2017-08-30 16:48, Gary Adams wrote:
Is the expectation that all of the := will be changed to += for these 
variables?


 468 jdk.internal.vm.ci_ADD_JAVAC_FLAGS := -parameters -Xlint:-exports 
-XDstringConcat=inline



Good catch! I missed that when just reviewing the patch file.

Do the closed makefiles also need to be updated?

No, they should be fine as they are.

/Erik


On 8/30/17, 10:36 AM, Erik Joelsson wrote:

Hello Jason,

I took the liberty of creating an issue for this: 
https://bugs.openjdk.java.net/browse/JDK-8186983


The mailing list server removes attachments. This makes it difficult 
for new people to send in their patches until they have an openjdk 
user so they can upload to cr.openjdk.java.net. Since you addressed 
the mail directly to me as well, I received the attachment and have 
created a webrev from it here:


http://cr.openjdk.java.net/~erikj/8186983/webrev.01/

I think the patch looks good now, but will leave it here until 
tomorrow to give other reviewers a chance to look at.


/Erik


On 2017-08-30 16:20, Jason Yong wrote:

Hi Eric,

I've removed the SETUP changes as requested...



On a side note, I noticed that the attachment got stripped out in 
the post
to the mailing list. Should I actually be copying and pasting the 
entire
diff in the message? Its a couple of hundred lines... or is 
somewhere to

put the attachment?


Regards,

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 14:43
Subject:Re: CompileJavaModule.gmk overrides values from a 
custom

extension gmk



Hello,

Changing the assignment on COPY, CLEAN and FLAGS variables makes sense,
but please revert the SETUP variables as those are not lists but single
value types.

Otherwise this looks good to me.

/Erik


On 2017-08-30 15:37, Jason Yong wrote:

Hi Eric,

With regards to the OCA I believe IBM has signed a contributors

agreement

which should cover me for that.


So here's the mercurial export of the CompileJavaModule.java with my
changes in




Regards,


Jason Yong

CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 13:47
Subject:Re: CompileJavaModule.gmk overrides values from a 
custom

extension gmk



If you have signed the OCA, you can post your proposed change here 
and I

or someone else will sponsor it once we agree that it looks good.
/Erik

On 2017-08-30 14:27, Jason Yong wrote:
Thanks Eric,

Is the next step is to get a sponsor for the change or should I 
post my

proposed change first?

Jason

Regards,

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom






From:Erik Joelsson 
To:Jason Yong ,

build-dev@openjdk.java.net

Date:29/08/2017 12:55
Subject:Re: CompileJavaModule.gmk overrides values from a 
custom

extension gmk



Hello Jason,

Your suggestion makes sense. The only reason these variables have :=
today is that we (at Oracle) haven't had a need for appending to those
particular variables (yet).

/Erik


On 2017-08-29 11:31, Jason Yong wrote:

Hello,

I've had an issue where I've had a custom extension to

CompileJavaModules.gmk with the variable java.base_COPY set to files

that

I wanted to be copied across but its value was overwritten by
CompileJavaModules.gmk.
I would like to propose changes that would allow a custom 
extensions to
update variables listed in CompileJavaModules.gmk. This issue is 
similar

to bug JDK-8064372 (

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8064372&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_pd0JudnAMtzyOP3NkOCP7ozDRbZ9ukki8lLmogKLJI&m=qG_YEjgXnzBfNvN5ztSbjIVP3nZ5SaZCibl7SHJjTfc&s=2mMmeC6jKTJu1OgK0Lssib1LKQvOFX3BwzIcJAebSeU&e= 




) but affects all the other variables such as:

java.activation_SETUP
java.base_ADD_JAVAC_FLAGS
java.base_COPY
java.base_CLEAN
etc

The fix is also similar, changing := to += allowing the custom

extension

to append to the variable if already set and create it if its not.

I would appreciate any feedback and help on what the next steps would

be.

Thanks

Jason


Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtime Technologies
IBM Hybrid Cloud
Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with

number

741598.
Registered offic

[RFR]: 8187004: No valid toolchains defined for BSD

[John Paul Adrian Glaubitz]

Hello!

I started working on fixing OpenJDK on BSD today and already ran into
the first issue which is the configure script being unable to find a
usable toolchain.

This happens because there are no valid toolchains defined for BSD in
common/autoconf/toolchain.m4. Since both clang and gcc are supported
on most BSD systems, this can be trivially resolved with:

diff -r 1147dee33745 common/autoconf/toolchain.m4
--- a/common/autoconf/toolchain.m4  Tue Aug 29 17:17:57 2017 +0200
+++ b/common/autoconf/toolchain.m4  Wed Aug 30 22:22:49 2017 +0200
@@ -42,6 +42,7 @@
 VALID_TOOLCHAINS_macosx="gcc clang"
 VALID_TOOLCHAINS_aix="xlc"
 VALID_TOOLCHAINS_windows="microsoft"
+VALID_TOOLCHAINS_bsd="gcc clang"
 
 # Toolchain descriptions

 TOOLCHAIN_DESCRIPTION_clang="clang/LLVM"

Webrev can be found in [1].

Adrian


[1] http://cr.openjdk.java.net/~glaubitz/8187004/webrev.00/


--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Building SPARC CPU code for Zero

[David Holmes]

Hi Magnus,

On 30/08/2017 11:25 PM, Magnus Ihse Bursie wrote:

On 2017-08-30 15:22, Magnus Ihse Bursie wrote:

On 2017-08-30 14:02, John Paul Adrian Glaubitz wrote:

Hi!

I am currently working on fixing JDK-8186578:

   Zero fails to build on linux-sparc due to sparc-specific code

One necessary change to be able to fix this bug is to build the
SPARC-specific source memset_with_concurrent_readers_sparc.cpp on
Zero as well. This is necessary because on SPARC, we have to use
the custom implementation of memset() to be able to have a working
memset_with_concurrent_readers, the glibc version doesn't work in
this case.

Now, my first suggested way of addressing this problem was to move
memset_with_concurrent_readers_sparc.cpp into the same location
as memset_with_concurrent_readers.hpp and just make the code in
the former compilation unit conditional so it's built on SPARC
only [1].

Unfortunately, this proposed change was rejected due to the fact
that it moves SPARC code into a generic location. So, I'm now looking
for a way to tell the build system to build memset_with_concurrent_\
readers_sparc.cpp when building Zero if SPARC is defined.

Can any build wizard shed some light on this and say whether it's
possible to achieve that?


I'm sure it's *possible*. I'm also fairly certain it will be messy. :)

Unfortunately, the usage of various defines in presence of zero seems 
not very well defined. That is, should SPARC be defined alongside 
ZERO, or should it not be defined when ZERO is defined, if building 
zero on sparc.


The current effect, if I remember correctly, is that both ZERO and 
SPARC are defined if building zero on sparc, but only SPARC if 
building a "normal" sparc build. There is also a ZERO_LIBARCH, but I 
fail to understand the purpose of this.


But your problem seems to be that the file itself is not included. I'm 
not sure how the hotspot include logic determines which platform 
specific files to include. Possibly they have a "and !definied(ZERO)" 
in the logic.

Aha, now I see. It's a .cpp file in cpu/sparc. Hm.

Would it be painful to duplicate the function in cpu/zero? I realize 
this is not elegant, but we don't have a good story for sharing 
platform-specific functionality with zero. :(


Can't we just expand the set of source files to be built when building 
Zero for sparc? (Similar to how we reduce the set of source files to 
build when building the minimal VM). Sadly I no longer know where such 
things are controlled in the build.


Thanks,
David


/Magnus




/Magnus



Adrian


[1] http://cr.openjdk.java.net/~glaubitz/8186578/webrev.00/

Re: CompileJavaModule.gmk overrides values from a custom extension gmk

[David Holmes]

On 31/08/2017 12:36 AM, Erik Joelsson wrote:

Hello Jason,

I took the liberty of creating an issue for this: 
https://bugs.openjdk.java.net/browse/JDK-8186983


The mailing list server removes attachments. This makes it difficult for 
new people to send in their patches until they have an openjdk user so 
they can upload to cr.openjdk.java.net. Since you addressed the mail 
directly to me as well, I received the attachment and have created a 
webrev from it here:


http://cr.openjdk.java.net/~erikj/8186983/webrev.01/

I think the patch looks good now, but will leave it here until tomorrow 
to give other reviewers a chance to look at.


This seems okay, though I do want to point out that even with this 
change there is still limited ability to combine custom values with 
standard ones - the standard ones are always added last and so 
potentially could conflict with or override the intent of the custom 
settings.


It is good to know that someone else is actually using the customization 
mechanism though! :)


Cheers,
David


/Erik


On 2017-08-30 16:20, Jason Yong wrote:

Hi Eric,

I've removed the SETUP changes as requested...



On a side note, I noticed that the attachment got stripped out in the 
post

to the mailing list. Should I actually be copying and pasting the entire
diff in the message? Its a couple of hundred lines... or is somewhere to
put the attachment?


Regards,

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 14:43
Subject:    Re: CompileJavaModule.gmk overrides values from a custom
extension gmk



Hello,

Changing the assignment on COPY, CLEAN and FLAGS variables makes sense,
but please revert the SETUP variables as those are not lists but single
value types.

Otherwise this looks good to me.

/Erik


On 2017-08-30 15:37, Jason Yong wrote:

Hi Eric,

With regards to the OCA I believe IBM has signed a contributors

agreement

which should cover me for that.


So here's the mercurial export of the CompileJavaModule.java with my
changes in




Regards,


Jason Yong

CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 13:47
Subject:    Re: CompileJavaModule.gmk overrides values from a custom
extension gmk



If you have signed the OCA, you can post your proposed change here and I
or someone else will sponsor it once we agree that it looks good.
/Erik

On 2017-08-30 14:27, Jason Yong wrote:
Thanks Eric,

Is the next step is to get a sponsor for the change or should I post my
proposed change first?

Jason

Regards,

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom






From:    Erik Joelsson 
To:    Jason Yong ,

build-dev@openjdk.java.net

Date:    29/08/2017 12:55
Subject:    Re: CompileJavaModule.gmk overrides values from a custom
extension gmk



Hello Jason,

Your suggestion makes sense. The only reason these variables have :=
today is that we (at Oracle) haven't had a need for appending to those
particular variables (yet).

/Erik


On 2017-08-29 11:31, Jason Yong wrote:

Hello,

I've had an issue where I've had a custom extension to

CompileJavaModules.gmk with the variable java.base_COPY set to files

that

I wanted to be copied across but its value was overwritten by
CompileJavaModules.gmk.

I would like to propose changes that would allow a custom extensions to

update variables listed in CompileJavaModules.gmk. This issue is similar
to bug JDK-8064372 (

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8064372&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_pd0JudnAMtzyOP3NkOCP7ozDRbZ9ukki8lLmogKLJI&m=qG_YEjgXnzBfNvN5ztSbjIVP3nZ5SaZCibl7SHJjTfc&s=2mMmeC6jKTJu1OgK0Lssib1LKQvOFX3BwzIcJAebSeU&e= 




) but affects all the other variables such as:

java.activation_SETUP
java.base_ADD_JAVAC_FLAGS
java.base_COPY
java.base_CLEAN
etc

The fix is also similar, changing := to += allowing the custom

extension

to append to the variable if already set and create it if its not.

I would appreciate any feedback and help on what the next steps would

be.

Thanks

Jason


Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtime Technologies
IBM Hybrid Cloud
Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with

number

741598.

Registered office: 

Re: [RFR]: 8187004: No valid toolchains defined for BSD

[Thomas Stüfe]

Hi Adrian,

this looks fine. Thanks for taking on BSD (I'm a bit confused though, I
thought BSD is already buildable).

Best Regards, Thomas

On Wed, Aug 30, 2017 at 10:30 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hello!
>
> I started working on fixing OpenJDK on BSD today and already ran into
> the first issue which is the configure script being unable to find a
> usable toolchain.
>
> This happens because there are no valid toolchains defined for BSD in
> common/autoconf/toolchain.m4. Since both clang and gcc are supported
> on most BSD systems, this can be trivially resolved with:
>
> diff -r 1147dee33745 common/autoconf/toolchain.m4
> --- a/common/autoconf/toolchain.m4  Tue Aug 29 17:17:57 2017 +0200
> +++ b/common/autoconf/toolchain.m4  Wed Aug 30 22:22:49 2017 +0200
> @@ -42,6 +42,7 @@
>  VALID_TOOLCHAINS_macosx="gcc clang"
>  VALID_TOOLCHAINS_aix="xlc"
>  VALID_TOOLCHAINS_windows="microsoft"
> +VALID_TOOLCHAINS_bsd="gcc clang"
>   # Toolchain descriptions
>  TOOLCHAIN_DESCRIPTION_clang="clang/LLVM"
>
> Webrev can be found in [1].
>
> Adrian
>
> [1] http://cr.openjdk.java.net/~glaubitz/8187004/webrev.00/
>>
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

Re: [RFR]: 8187004: No valid toolchains defined for BSD

[David Holmes]

On 31/08/2017 4:14 PM, Thomas Stüfe wrote:

Hi Adrian,

this looks fine. Thanks for taking on BSD (I'm a bit confused though, I
thought BSD is already buildable).


Thomas you beat me to it - on both counts! I too recall others building 
for BSD.


David


Best Regards, Thomas

On Wed, Aug 30, 2017 at 10:30 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:


Hello!

I started working on fixing OpenJDK on BSD today and already ran into
the first issue which is the configure script being unable to find a
usable toolchain.

This happens because there are no valid toolchains defined for BSD in
common/autoconf/toolchain.m4. Since both clang and gcc are supported
on most BSD systems, this can be trivially resolved with:

diff -r 1147dee33745 common/autoconf/toolchain.m4
--- a/common/autoconf/toolchain.m4  Tue Aug 29 17:17:57 2017 +0200
+++ b/common/autoconf/toolchain.m4  Wed Aug 30 22:22:49 2017 +0200
@@ -42,6 +42,7 @@
  VALID_TOOLCHAINS_macosx="gcc clang"
  VALID_TOOLCHAINS_aix="xlc"
  VALID_TOOLCHAINS_windows="microsoft"
+VALID_TOOLCHAINS_bsd="gcc clang"
   # Toolchain descriptions
  TOOLCHAIN_DESCRIPTION_clang="clang/LLVM"

Webrev can be found in [1].

Adrian

[1] http://cr.openjdk.java.net/~glaubitz/8187004/webrev.00/




--
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [RFR]: 8187004: No valid toolchains defined for BSD

[Thomas Stüfe]

Looking through my Mails quick, all mails at bsd-port-dev seem to refer to
jdk8.

toolchain.m4 changed a bit since jdk8. Maybe noone attempted to build jdk10
yet on BSD and
Adrian ran into new errors.

..Thomas

On Thu, Aug 31, 2017 at 8:25 AM, David Holmes 
wrote:

> On 31/08/2017 4:14 PM, Thomas Stüfe wrote:
>
>> Hi Adrian,
>>
>> this looks fine. Thanks for taking on BSD (I'm a bit confused though, I
>> thought BSD is already buildable).
>>
>
> Thomas you beat me to it - on both counts! I too recall others building
> for BSD.
>
> David
>
>
> Best Regards, Thomas
>>
>> On Wed, Aug 30, 2017 at 10:30 PM, John Paul Adrian Glaubitz <
>> glaub...@physik.fu-berlin.de> wrote:
>>
>> Hello!
>>>
>>> I started working on fixing OpenJDK on BSD today and already ran into
>>> the first issue which is the configure script being unable to find a
>>> usable toolchain.
>>>
>>> This happens because there are no valid toolchains defined for BSD in
>>> common/autoconf/toolchain.m4. Since both clang and gcc are supported
>>> on most BSD systems, this can be trivially resolved with:
>>>
>>> diff -r 1147dee33745 common/autoconf/toolchain.m4
>>> --- a/common/autoconf/toolchain.m4  Tue Aug 29 17:17:57 2017 +0200
>>> +++ b/common/autoconf/toolchain.m4  Wed Aug 30 22:22:49 2017 +0200
>>> @@ -42,6 +42,7 @@
>>>   VALID_TOOLCHAINS_macosx="gcc clang"
>>>   VALID_TOOLCHAINS_aix="xlc"
>>>   VALID_TOOLCHAINS_windows="microsoft"
>>> +VALID_TOOLCHAINS_bsd="gcc clang"
>>># Toolchain descriptions
>>>   TOOLCHAIN_DESCRIPTION_clang="clang/LLVM"
>>>
>>> Webrev can be found in [1].
>>>
>>> Adrian
>>>
>>> [1] http://cr.openjdk.java.net/~glaubitz/8187004/webrev.00/
>>>


>>> --
>>>   .''`.  John Paul Adrian Glaubitz
>>> : :' :  Debian Developer - glaub...@debian.org
>>> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>>>`-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>>>
>>>

Re: [RFR]: 8187004: No valid toolchains defined for BSD

[Magnus Ihse Bursie]

On 2017-08-31 08:25, David Holmes wrote:

On 31/08/2017 4:14 PM, Thomas Stüfe wrote:

Hi Adrian,

this looks fine. Thanks for taking on BSD (I'm a bit confused though, I
thought BSD is already buildable).


Thomas you beat me to it - on both counts! I too recall others 
building for BSD.


BSD is buildable for jdk9 in the separate, hardly-maintained bsd-port 
only. :-(


I posted a set of patches for jdk9 mainline for building jdk9 on BSD, 
that was rejected. :( They ended up in the bsd-port, but this has not 
been pushed upstream to the mainline, and the bsd port is only 
sporadically updated from mainline.


Since those changes are either a) general cleanups that all platforms 
should benefit from, or b) no-risk bsd-only changes, I'd really like to 
see them go into the mainline build system. But for that to happen, we 
apparently need to change some policy about accepting code for platforms 
not tested by Oracle. :-(


The changes, btw, look good.

/Magnus



David


Best Regards, Thomas

On Wed, Aug 30, 2017 at 10:30 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:


Hello!

I started working on fixing OpenJDK on BSD today and already ran into
the first issue which is the configure script being unable to find a
usable toolchain.

This happens because there are no valid toolchains defined for BSD in
common/autoconf/toolchain.m4. Since both clang and gcc are supported
on most BSD systems, this can be trivially resolved with:

diff -r 1147dee33745 common/autoconf/toolchain.m4
--- a/common/autoconf/toolchain.m4  Tue Aug 29 17:17:57 2017 +0200
+++ b/common/autoconf/toolchain.m4  Wed Aug 30 22:22:49 2017 +0200
@@ -42,6 +42,7 @@
  VALID_TOOLCHAINS_macosx="gcc clang"
  VALID_TOOLCHAINS_aix="xlc"
  VALID_TOOLCHAINS_windows="microsoft"
+VALID_TOOLCHAINS_bsd="gcc clang"
   # Toolchain descriptions
  TOOLCHAIN_DESCRIPTION_clang="clang/LLVM"

Webrev can be found in [1].

Adrian

[1] http://cr.openjdk.java.net/~glaubitz/8187004/webrev.00/




--
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [RFR]: 8187004: No valid toolchains defined for BSD

[John Paul Adrian Glaubitz]

On 08/31/2017 08:41 AM, Thomas Stüfe wrote:
> Looking through my Mails quick, all mails at bsd-port-dev seem to refer to 
> jdk8.
> 
> toolchain.m4 changed a bit since jdk8. Maybe noone attempted to build jdk10 
> yet on BSD and
> Adrian ran into new errors.

Well, "bsd" is also missing from jdk/src/java.base which means building the JDK
also currently isn't possible. I guess, there is quite some work to be done 
here.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913