On Thu, 12 May 2022 04:25:24 GMT, David Holmes wrote:
>> This change seem to have made this group of declarations obsolete:
>> `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow
>> the [link](
>> https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368
On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote:
>> Currently we set _WIN32_WINNT at various places in the codebase; this is
>> used to target a minimum Windows version we want to support. See also for
>> more detailled information :
>> https://docs.microsoft.com/en-us/windows/win32/win
On Thu, 14 Apr 2022 12:00:56 GMT, Andrew Leonard wrote:
>> @mkartashev thanks. So at the moment we are only using this assembly header
>> for gcc tooling, see NativeCompliation.gmk change.
>> So maybe I change this to specifically state gcc and it's effect on linux
>> debuginfo ?
>
> updated
@
On Wed, 13 Apr 2022 13:55:59 GMT, Andrew Leonard wrote:
>> This PR removes the need for relative object file linking introduced by
>> JDK-8284437 for linux libraries, by specifying
>> .file directives in the linux .S source files. The
>> source files specify a .file ASSEMBLY_SRC_FILE
>> where
On Mon, 11 Apr 2022 14:05:54 GMT, Andrew Leonard wrote:
>> This PR removes the need for relative object file linking introduced by
>> JDK-8284437 for linux libraries, by specifying
>> .file directives in the linux .S source files. The
>> source files specify a .file ASSEMBLY_SRC_FILE
>> where
On Fri, 8 Apr 2022 14:42:34 GMT, Andrew Leonard wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Trigger checks
>
> I am not sure why without the explicit .file directive that the FILE symbol
> in the ELF info co
On Fri, 8 Apr 2022 14:16:03 GMT, Maxim Kartashev wrote:
>> @mkartashev Why don't you try building with clang as two different users, in
>> two different directories, and see if the build is non-reproducible without
>> this patch, but is reproducible with it (incl. y
On Fri, 8 Apr 2022 14:11:56 GMT, Magnus Ihse Bursie wrote:
>> I did some experiments both with `gcc` and `clang`. Both respect the `.file`
>> directive and put into the resulting ELF whatever was written after that
>> keyword, so no path mapping is necessary. However, debug information suffers
On Wed, 6 Apr 2022 13:30:28 GMT, Andrew Leonard wrote:
>> This PR fixes the non-deterministic behavior when building on linux with
>> different userids or within
>> different workspace folders.
>> It fixes the following issues:
>> - MakeZipReproducible.java used to produce reproducible src.zip r
On Fri, 8 Apr 2022 13:23:23 GMT, Andrew Leonard wrote:
> I can't seem to find any online assembly documentation(?) that states that a
> .file symbol pointing to the absolute object file name is produced, but it
> obviously does! In fact maybe it's to do with how the linker generates them,
> as
On Fri, 8 Apr 2022 12:57:58 GMT, Andrew Leonard wrote:
> That is simply because I have not test full reproducibility on MacOS, the
> intention of this PR was for Linux platforms.
> Although MacOS is my next port of investigation for reproducibility as a
> whole..
@andrew-m-leonard Thank you fo
On Wed, 6 Apr 2022 13:30:28 GMT, Andrew Leonard wrote:
>> This PR fixes the non-deterministic behavior when building on linux with
>> different userids or within
>> different workspace folders.
>> It fixes the following issues:
>> - MakeZipReproducible.java used to produce reproducible src.zip r
On Wed, 6 Apr 2022 13:30:28 GMT, Andrew Leonard wrote:
>> This PR fixes the non-deterministic behavior when building on linux with
>> different userids or within
>> different workspace folders.
>> It fixes the following issues:
>> - MakeZipReproducible.java used to produce reproducible src.zip r
On Fri, 4 Feb 2022 10:55:40 GMT, Maxim Kartashev wrote:
> Some dll/exe files end up having absolute path names embedded in them despite
> the use of `--disable-absolute-paths-in-output` build option. This option
> effectively translates into adding `-pathmap` to compilation l
vert Unix-style paths to what is understood by Windows.
>
> For example:
>
> $ build/windows-x86_64-server-release/fixpath print
> -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s
> -pathmap:C:cygwin64homemaximworkrepr.build.1=s
>
> However, if a "normal&qu
On Fri, 4 Feb 2022 18:37:51 GMT, Maxim Kartashev wrote:
>> Some dll/exe files end up having absolute path names embedded in them
>> despite the use of `--disable-absolute-paths-in-output` build option. This
>> option effectively translates into adding `-pathmap` to compilat
On Fri, 4 Feb 2022 20:49:14 GMT, Erik Joelsson wrote:
> would be good if Magnus could take a look as well.
Now that a good part of the PR is authored by you, `jcheck` wouldn't have it
any other way :-)
-
PR: https://git.openjdk.java.net/jdk/pull/7344
vert Unix-style paths to what is understood by Windows.
>
> For example:
>
> $ build/windows-x86_64-server-release/fixpath print
> -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s
> -pathmap:C:cygwin64homemaximworkrepr.build.1=s
>
> However, if a "normal&qu
pre-processes all commands on Windows prior to running
>> them and is supposed to convert Unix-style paths to what is understood by
>> Windows.
>>
>> For example:
>>
>> $ build/windows-x86_64-server-release/fixpath print
>> -pathmap:C:\cygwin64\home\maxim\w
vert Unix-style paths to what is understood by Windows.
>
> For example:
>
> $ build/windows-x86_64-server-release/fixpath print
> -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s
> -pathmap:C:cygwin64homemaximworkrepr.build.1=s
>
> However, if a "normal&qu
od by Windows.
For example:
$ build/windows-x86_64-server-release/fixpath print
-pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s
-pathmap:C:cygwin64homemaximworkrepr.build.1=s
However, if a "normal" Unix-style path is provided, it gets converted correctly:
$ build/windows-x86_64
On Tue, 30 Nov 2021 12:48:48 GMT, Magnus Ihse Bursie wrote:
>> Corrects spelling mistakes in the documentation and one configure script
>> message.
>
> @mkartashev I can sponsor this, once you have done `/integrate`.
@magicus Thanks for a quick review!
-
PR: https://git.openjdk.ja
On Tue, 30 Nov 2021 09:47:31 GMT, Maxim Kartashev wrote:
> Corrects spelling mistakes in the documentation and one configure script
> message.
This pull request has now been integrated.
Changeset: 01cefc94
Author: Maxim Kartashev
Committer: Magnus Ihse Bursie
URL:
Corrects spelling mistakes in the documentation and one configure script
message.
-
Commit messages:
- 8277977: Incorrect references to --enable-reproducible-builds in docs
Changes: https://git.openjdk.java.net/jdk/pull/6609/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk
On Mon, 24 May 2021 14:03:45 GMT, Maxim Kartashev
wrote:
> This commit adds the `-fno-delete-null-pointer-checks` compiler option to
> clang builds, which is going to become necessary starting from clang version
> 12.0.0 (see the [bug
> report](https://bugs.openjdk.java.ne
On Tue, 1 Jun 2021 13:23:49 GMT, Erik Joelsson wrote:
>> This commit adds the `-fno-delete-null-pointer-checks` compiler option to
>> clang builds, which is going to become necessary starting from clang version
>> 12.0.0 (see the [bug
>> report](https://bugs.openjdk.java.net/browse/JDK-8265431
On Tue, 1 Jun 2021 13:23:49 GMT, Erik Joelsson wrote:
> I left a comment in the bug that you haven't answered.
Sorry, don't have write access to the bug.
To answer your comment
> You seem to be mixing up -fno-delete-null-pointer-checks and
> -fdelete-null-pointer-checks between the descriptio
Hello All,
I'd appreciate it very much if someone could take a look at my PR:
https://github.com/openjdk/jdk/pull/4166
Thanks in advance,
Maxim.
This commit adds the `-fno-delete-null-pointer-checks` compiler option to clang
builds, which is going to become necessary starting from clang version 12.0.0
(see the [bug report](https://bugs.openjdk.java.net/browse/JDK-8265431) for
more info).
Verified on Linux (with both gcc and clang toolch
Am 12.07.2011 23:10, schrieb Gary Meyer:
> On Jul 12, 2011, at 1:54 PM, Maxim wrote:
>
>
>> @Mike Swingler: Java until version 1.6 runs successfully on PPC. I'm
>> sure Apple did its own PPC port, didn't it?
>>
>>
> No. Apple never h
Original-Nachricht
Betreff:Re: Help me to build openjdk on my machine
Datum: Tue, 12 Jul 2011 22:52:02 +0200
Von:Maxim
An: Mike Swingler
Am 10.07.2011 22:37, schrieb Mike Swingler:
> [snip]
> Just to set some expectations, the Mac OS X porting proje
Original-Nachricht
Betreff:Re: Help me to build openjdk on my machine
Datum: Tue, 12 Jul 2011 22:40:29 +0200
Von:Maxim
An: Erik Trimble
Am 10.07.2011 20:24, schrieb Erik Trimble:
> [snip]
>
> It certainly would be nice for someone to come forwa
tag dates.
So, it looks like I have the current source, but it doesn't build on
OS X 10.6.1. Does anybody know of a way to get the build working on OS
X?
Thanks,
- max
On Sep 26, 2009, at 12:53 AM, Maxim Porges wrote:
Hmm, perhaps not. Thanks for the tip -I'll give it another
Hmm, perhaps not. Thanks for the tip -I'll give it another shot with
this build.
- max
On Sep 25, 2009, at 1:20 PM, "John Coomes" wrote:
> Maxim Porges (maxim.por...@highwinds.com) wrote:
>> Hi,
>>
>>I've been following Stephen Bannasch's v
Hi,
I've been following Stephen Bannasch's very thorough and detailed
article (http://confluence.concord.org/display/CCTR/Build+OpenJDK+Java+1.7.0+on+Mac+OS+X+10.5
) for installing OpenJDK 1.7.0 on OS X (thanks very much to Stephen
for putting that together). I'm actually trying to install
35 matches
Mail list logo
