Since long time ago, native libraries in JDK has been compiled with -g1 instead
of -g, when doing a fastdebug build with gcc. (This does not apply to hotspot
which is always compiled with -g.)
This means that the debug information generated is limited. The gcc manual says
this about level 1:
"
Hi,
In "make/Docs.gmk" We have found 2 issues which required to be fixed in
OpenJDK,
1)
-JDK_MODULES := $(sort $(DOCS_MODULES))
+JDK_MODULES := $(sort $(filter-out $(MODULES_FILTER), $(DOCS_MODULES)))
==> This is an OpenJDK bug as this should be filtering out the
MODULES_FILTER modules... he
On solstudio, we have used -g for generating debug information when compiling C
files, but -g0 when compiling C++ programs.
This is due to the fact that -g, when compiling C++ programs, will prohibit
inlining. We do not want that, since we build with debug symbols even in
release builds, to get
Hello David,
On 2018-03-07 21:35, David Holmes wrote:
On 8/03/2018 7:24 AM, Erik Joelsson wrote:
When we bumped the feature version from 10 to 11, we forgot to also
update the required versions of the boot and build jdk. This is an
easy mistake to do, so we should make sure it is easy and intu
Looks good!
/Erik
On 2018-03-08 07:44, Magnus Ihse Bursie wrote:
On solstudio, we have used -g for generating debug information when compiling C
files, but -g0 when compiling C++ programs.
This is due to the fact that -g, when compiling C++ programs, will prohibit
inlining. We do not want t
Looks good!
/Erik
On 2018-03-08 06:19, Magnus Ihse Bursie wrote:
Since long time ago, native libraries in JDK has been compiled with -g1 instead
of -g, when doing a fastdebug build with gcc. (This does not apply to hotspot
which is always compiled with -g.)
This means that the debug informa
Hello,
On 2018-03-08 06:51, Archana Nogriya wrote:
Hi,
In "make/Docs.gmk" We have found 2 issues which required to be fixed in
OpenJDK,
1)
-JDK_MODULES := $(sort $(DOCS_MODULES))
+JDK_MODULES := $(sort $(filter-out $(MODULES_FILTER), $(DOCS_MODULES)))
==> This is an OpenJDK bug as this should
The change in JDK-8198859 unfortunately broke solaris x64. While we (at
Oracle) aren't building this platform regularly anymore, we still have a
weird dependency on it so need to keep it building for a while more.
The simplest fix is to only do the elfedit on sparc.
Bug: https://bugs.openjdk.j
Looks good to me.
/Magnus
> 8 mars 2018 kl. 18:46 skrev Erik Joelsson :
>
> The change in JDK-8198859 unfortunately broke solaris x64. While we (at
> Oracle) aren't building this platform regularly anymore, we still have a
> weird dependency on it so need to keep it building for a while more.
This is in the main JDK repo: notice the second line, "ExecuteWithLog is"
-- Jon
Building targets 'jdk-image docs-jdk-api' in configuration
'linux-x86_64-normal-server-release'
ExecuteWithLog is
Finished building targets 'jdk-image docs-jdk-api' in configuration
'linux-x86_64-normal-server-r
Hi,
On 9/03/2018 12:51 AM, Archana Nogriya wrote:
Hi,
In "make/Docs.gmk" We have found 2 issues which required to be fixed in
OpenJDK,
1)
-JDK_MODULES := $(sort $(DOCS_MODULES))
+JDK_MODULES := $(sort $(filter-out $(MODULES_FILTER), $(DOCS_MODULES)))
==> This is an OpenJDK bug as this should
The Jib artifact resolver is not very good at telling us why things go
wrong. The reason is that it swallows exceptions. This patch changes the
API from throwing a FileNotFoundException, which I don't really think
fits correctly in all cases, to a new API specific exception.
I have greped for
For some time, we have used two different ways of handling debug symbols on
Windows. Hotspot has been built using -Z7, and the JDK libraries using -Zi. -Z7
is preferable, since it does not create separate .pdb files for each source
file; instead debug data is embedded in the .obj file, just like
Looks good.
/Erik
On 2018-03-08 14:10, Magnus Ihse Bursie wrote:
For some time, we have used two different ways of handling debug symbols on
Windows. Hotspot has been built using -Z7, and the JDK libraries using -Zi. -Z7
is preferable, since it does not create separate .pdb files for each so
Hi Erik,
to avoid incompatibility, you could have just made ArtifactResolverException a
subclass of java.io.FileNotFoundException.
it seems you forgot to add ArtifactResolverException.java file to the repo.
a minor nit: in JibArtifactManager::newInstance, you pass "Could not resolve "
+ JIB_SE
On 2018-03-08 15:24, Igor Ignatyev wrote:
Hi Erik,
Thanks for looking at this!
to avoid incompatibility, you could have just made ArtifactResolverException a
subclass of java.io.FileNotFoundException.
This is correct, but I don't think the exception should be of type
FileNotFoundException. IM
Looks good to me.
-- Igor
> On Mar 8, 2018, at 4:06 PM, Erik Joelsson wrote:
>
> On 2018-03-08 15:24, Igor Ignatyev wrote:
>> Hi Erik,
> Thanks for looking at this!
>> to avoid incompatibility, you could have just made ArtifactResolverException
>> a subclass of java.io.FileNotFoundException.
>
> 9 mars 2018 kl. 01:06 skrev Erik Joelsson :
>
>> On 2018-03-08 15:24, Igor Ignatyev wrote:
>> Hi Erik,
> Thanks for looking at this!
>> to avoid incompatibility, you could have just made ArtifactResolverException
>> a subclass of java.io.FileNotFoundException.
> This is correct, but I don't th
18 matches
Mail list logo
