Hi Simon,
On 20/09/2018 7:48 AM, Simon Nash wrote:
On 19/09/2018 07:44, David Holmes wrote:
Hi Bob,
On 18/09/2018 11:17 PM, Bob Vandette wrote:
I only did some basic testing of the hard-float abi. Bell SW has
offered to do more extensive testing
as part of this JEP.
I have no way of
This is the first part towards a better framework in the build for
handling compiler warnings. The basic idea is that we should have
consistent way for all compilers to:
1) enable all (relevant) warnings
2) disable individual warnings, on a global scale (if 1 enables too much)
In particular,
Looks good.
/Erik
On 2018-09-20 11:42, Magnus Ihse Bursie wrote:
On 2018-09-20 19:47, Erik Joelsson wrote:
On 2018-09-20 10:24, Magnus Ihse Bursie wrote:
On 2018-09-20 18:59, Aleksey Shipilev wrote:
On 09/20/2018 06:48 PM, Magnus Ihse Bursie wrote:
A long time ago, we supported
Looks ok.
/Erik
On 2018-09-20 01:32, Magnus Ihse Bursie wrote:
There's a lot of weird stuff going on with libjli and the launchers.
Most of it stems from the old build system, which was just copied
verbatim into the new build system. This is the final part of getting
JLI to behave like most
On 2018-09-20 19:47, Erik Joelsson wrote:
On 2018-09-20 10:24, Magnus Ihse Bursie wrote:
On 2018-09-20 18:59, Aleksey Shipilev wrote:
On 09/20/2018 06:48 PM, Magnus Ihse Bursie wrote:
A long time ago, we supported different "variants" of the JDK
build, like "normal" and "embedded".
The
On 2018-09-20 11:35, Aleksey Shipilev wrote:
I guess the question is how much variability is there in day-to-day builds. As
the guy who builds
lots of different configurations, I see great simplicity in maintaining current
static label that
captures most of the usual variability. For example,
On 09/20/2018 07:24 PM, Magnus Ihse Bursie wrote:
> Currently the default format looks like this:
> "linux-x86_64-normal-server-release", that is
> . The selection of these
> configuration
> parameters feels a bit arbitrary. Some examples of other parameters we could
> have included, but
>
On 2018-09-20 10:24, Magnus Ihse Bursie wrote:
On 2018-09-20 18:59, Aleksey Shipilev wrote:
On 09/20/2018 06:48 PM, Magnus Ihse Bursie wrote:
A long time ago, we supported different "variants" of the JDK build,
like "normal" and "embedded".
The --with-jdk-variant and associated machinery has
On 2018-09-20 18:59, Aleksey Shipilev wrote:
On 09/20/2018 06:48 PM, Magnus Ihse Bursie wrote:
A long time ago, we supported different "variants" of the JDK build, like "normal" and
"embedded".
The --with-jdk-variant and associated machinery has been kept in place, even
though it's not
On 09/20/2018 06:48 PM, Magnus Ihse Bursie wrote:
> A long time ago, we supported different "variants" of the JDK build, like
> "normal" and "embedded".
> The --with-jdk-variant and associated machinery has been kept in place, even
> though it's not doing
> anyting. Time to remove it.
>
> I
A long time ago, we supported different "variants" of the JDK build,
like "normal" and "embedded". The --with-jdk-variant and associated
machinery has been kept in place, even though it's not doing anyting.
Time to remove it.
I chose to keep the "-normal-" in the build output name so as not
Looks good to me.
/Erik
On 2018-09-20 08:09, Severin Gehwolf wrote:
Hi,
Could someone please review this JDK 8u only change. When building with
extra linker flags, namely -Wl,-z,defs, the build fails on linux in the
serviciability agent. The reason for this is missing -ldl on the link
Hello,
Looks good.
/Erik
On 2018-09-20 04:43, Magnus Ihse Bursie wrote:
Allow --with-boot-jdk-jvmargs to work during the configure phase. Also
report the usages of _JAVA_OPTIONS and JAVA_TOOL_OPTIONS environment
variables, which can seriously mess up the build.
Bug:
Looks good.
/Erik
On 2018-09-20 01:35, Magnus Ihse Bursie wrote:
We're currently filtering out -xc99=%none from CFLAGS_JDKLIB in
liblcms. We do not need to to this. Appending -xc99=no_lib using
CFLAGS_solaris is enough to override.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210949
Looks good.
/Erik
On 2018-09-20 00:05, Magnus Ihse Bursie wrote:
Currently, we are filtering out -MD and replacing it with -MT when
building libwindowsaccessbridge. This has just been a way to replicate
the behavior of old build system, and there's no point in doing so.
In fact, it is
Looks good.
/Erik
On 2018-09-19 23:44, Magnus Ihse Bursie wrote:
We have been filtering out the -xregs=no%appl when compiling libsunec
for sparc. This is just an remnant of the old build system, where this
were not properly set. (The recommendation is to use it for dlls.) To
mimic the old
Hi,
Could someone please review this JDK 8u only change. When building with
extra linker flags, namely -Wl,-z,defs, the build fails on linux in the
serviciability agent. The reason for this is missing -ldl on the link
command. Note that JDK 9+ with the new build system have that already.
On Thu, Sep 20, 2018 at 7:36 PM Magnus Ihse Bursie
wrote:
>
> On 2018-09-20 12:41, Ao Qi wrote:
>
> On Thu, Sep 20, 2018 at 4:10 PM Magnus Ihse Bursie
> wrote:
>
> On 2018-09-20 09:26, Ao Qi wrote:
>
> Hi,
>
> Is there any options or methods that I can pass additional jdk options
> to the boot
On 20/09/2018 12:31, Magnus Ihse Bursie wrote:
I'm pretty sure I've run at least the instrument tests, but I'll rerun
it just to make sure. Does :jdk_instrument and :jdk_launcher sound
reasonable?
Yes that will run them.
At some point I hope we can get the JPLIS agent in libinstrument
On 19/09/2018 07:44, David Holmes wrote:
Hi Bob,
On 18/09/2018 11:17 PM, Bob Vandette wrote:
I only did some basic testing of the hard-float abi. Bell SW has
offered to do more extensive testing
as part of this JEP.
I have no way of knowing if any of the other profiles are being used
but I
Allow --with-boot-jdk-jvmargs to work during the configure phase. Also
report the usages of _JAVA_OPTIONS and JAVA_TOOL_OPTIONS environment
variables, which can seriously mess up the build.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210960
WebRev:
On 2018-09-20 12:41, Ao Qi wrote:
On Thu, Sep 20, 2018 at 4:10 PM Magnus Ihse Bursie
wrote:
On 2018-09-20 09:26, Ao Qi wrote:
Hi,
Is there any options or methods that I can pass additional jdk options
to the boot jdk when I configure jdk/jdk? I found
--with-boot-jdk-jvmargs, but I think it
On 2018-09-20 13:24, Alan Bateman wrote:
On 20/09/2018 09:32, Magnus Ihse Bursie wrote:
There's a lot of weird stuff going on with libjli and the launchers.
Most of it stems from the old build system, which was just copied
verbatim into the new build system. This is the final part of getting
The time has come to start phasing out the old test running framework
("cd test && make"). This patch will change the behavior of "make test"
to use the new run-test framework, instead of the old.
The old framework is still available as of now by using "cd test && make".
The "run-test" target
On Thu, Sep 20, 2018 at 4:10 PM Magnus Ihse Bursie
wrote:
>
> On 2018-09-20 09:26, Ao Qi wrote:
>
> Hi,
>
> Is there any options or methods that I can pass additional jdk options
> to the boot jdk when I configure jdk/jdk? I found
> --with-boot-jdk-jvmargs, but I think it is effective during
We're currently filtering out -xc99=%none from CFLAGS_JDKLIB in liblcms.
We do not need to to this. Appending -xc99=no_lib using CFLAGS_solaris
is enough to override.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210949
Patch inline:
diff --git a/make/lib/Awt2dLibraries.gmk
There's a lot of weird stuff going on with libjli and the launchers.
Most of it stems from the old build system, which was just copied
verbatim into the new build system. This is the final part of getting
JLI to behave like most other libraries.
This patch will:
* store libjli in the standard
On 2018-09-20 09:26, Ao Qi wrote:
Hi,
Is there any options or methods that I can pass additional jdk options
to the boot jdk when I configure jdk/jdk? I found
--with-boot-jdk-jvmargs, but I think it is effective during building
the jdk, not configuring the jdk.
You are correct, the additional
Hi,
Is there any options or methods that I can pass additional jdk options
to the boot jdk when I configure jdk/jdk? I found
--with-boot-jdk-jvmargs, but I think it is effective during building
the jdk, not configuring the jdk.
I used _JAVA_OPTIONS, but it failed to configure (fail to detect jdk
Currently, we are filtering out -MD and replacing it with -MT when
building libwindowsaccessbridge. This has just been a way to replicate
the behavior of old build system, and there's no point in doing so.
In fact, it is recommended *not* to mix -MT and -MD in dlls and
executable, as that
We have been filtering out the -xregs=no%appl when compiling libsunec
for sparc. This is just an remnant of the old build system, where this
were not properly set. (The recommendation is to use it for dlls.) To
mimic the old behavior, we chose to filter it out when converting the
old build
31 matches
Mail list logo
