Hi Magnus , I think it is not a separate toolchain , just another compiler
frontend offered by the xlc toolchain of xlc16 .
Our current toolchains are :
# These toolchains are valid on different platforms
VALID_TOOLCHAINS_linux="gcc clang"
VALID_TOOLCHAINS_solaris="solstudio"
VALID_TOOLCHAIN
On 2019-02-12 15:42, Alexey Ivanov wrote:
On 12/02/2019 14:37, Magnus Ihse Bursie wrote:
There has been some fallout due to the mapfile/linking changes made
in JDK 12 that affected JNICALL. However, that should not be
affecting JDK 11.
Wasn't it done in JDK 11?
If my memory serves me right,
On 2019-02-15 09:31, Baesken, Matthias wrote:
Hi Magnus , I think it is not a separate toolchain , just another compiler
frontend offered by the xlc toolchain of xlc16 .
So will this distinction between xlc and xlclang be needed elsewhere? Or
is it just the -g flag? I was worried that this
Hi Magnus,
we are currently able to build (+ test 😊 )jdk/jdk on AIX with the
xlclang++ based build .
Only needed are this change ,
plus a one-liner in harfhuzz is needed (we try to get this upstream into
harbuzz directly, in case the next harfhuzz update to jdk/jdk is in t
On 2019-02-15 12:53, Baesken, Matthias wrote:
Hi Magnus,
we are currently able to build (+ test 😊 )jdk/jdk on AIX with the
xlclang++ based build .
Only needed are this change ,
plus a one-liner in harfhuzz is needed (we try to get this upstream into
harbuzz directly, in cas
>
> Are they both pointing to the same binary, and the mode of operation
> (legacy xlc vs xlclang) is determined by the name of the executable?
>
Hello, in the installation I use I have separate binaries .
>
> Is xlclang++ always available for version 16+ of xlc?
>
I think so, as least I
Hi Alan, Mandy,
Here is the next round of this change:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/06/webrev/
It now also has tests which don't require objcopy to be present on test
machines as well as being integrated with --strip-debug (once JDK-
8218913 is pushed). --list-plugins
Like with sources in java and native compilation, this patch allows
automatic override of license files in the legal dir by just providing a
"custom" file with the same name.
Bug: https://bugs.openjdk.java.net/browse/JDK-8219129
Webrev: http://cr.openjdk.java.net/~erikj/8219129/webrev.01/
/Er
Thanks for the input. Here is a new webrev that only tries to disable
the "smart" extension if it is present.
http://cr.openjdk.java.net/~erikj/8217032/webrev.02/index.html
/Erik
On 2019-02-14 23:34, Magnus Ihse Bursie wrote:
On 2019-02-15 00:26, Erik Joelsson wrote:
Please review this minor
The incremental build of src.zip is broken. The cause of this is a bit
complex. To create the correct layout for the files in src.zip, we
create a set of directories with symlinks back to the real source. When
we then run find over these symlinked directories to figure out the make
dependencies
How about having the variable be called something like PANDOC_MARKDOWN_FLAG,
and have the value include “markdown”?
Cheers,
Mikael
> On Feb 15, 2019, at 11:57 AM, Erik Joelsson wrote:
>
> Thanks for the input. Here is a new webrev that only tries to disable the
> "smart" extension if it is
That would look better. Here is a new webrev:
http://cr.openjdk.java.net/~erikj/8217032/webrev.03/index.html
/Erik
On 2019-02-15 14:04, Mikael Vidstedt wrote:
How about having the variable be called something like PANDOC_MARKDOWN_FLAG,
and have the value include “markdown”?
Cheers,
Mikael
This is a "redo" of JDK-8218057, which was backed out in JDK-8218084.
The underlying issue has been resolved so we can now put this change in
again. The patch is the same as last time.
Bug: https://bugs.openjdk.java.net/browse/JDK-8218135
Webrev: http://cr.openjdk.java.net/~erikj/8218135/webre
+1
Cheers,
Mikael
> On Feb 15, 2019, at 2:28 PM, Erik Joelsson wrote:
>
> That would look better. Here is a new webrev:
> http://cr.openjdk.java.net/~erikj/8217032/webrev.03/index.html
>
> /Erik
>
> On 2019-02-15 14:04, Mikael Vidstedt wrote:
>> How about having the variable be called some
Hi Magnus,
http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/
Moved all files from "posix" to "unix" folder and reverted
Lib-jdk.jpackage.gmk changes.
Webrev updated with files moved, instead of add/remove.
Thanks,
Alexander
On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote:
On 2019-02
Yes, removing --debug-mode enables a 32 bits compilation, with warnings.
Thanks!
El vie., 15 de feb. de 2019 a la(s) 08:05, Magnus Ihse Bursie (
magnus.ihse.bur...@oracle.com) escribió:
>
>
> On 2019-02-12 15:42, Alexey Ivanov wrote:
> > On 12/02/2019 14:37, Magnus Ihse Bursie wrote:
> >> There h
16 matches
Mail list logo