On Thu, 7 Mar 2024 19:53:35 GMT, Andrew John Hughes wrote:
>>> Also, it might be worth repeating one of my long-standing wishes: that the
>>> version string should not be hard-coded into the build, but e.g. stored as
>>> a string in the `release` file, and read from there. If we did that, the
On Thu, 7 Mar 2024 17:11:18 GMT, Magnus Ihse Bursie wrote:
> Also, it might be worth repeating one of my long-standing wishes: that the
> version string should not be hard-coded into the build, but e.g. stored as a
> string in the `release` file, and read from there. If we did that, the cost
>
On Mon, 18 Dec 2023 17:06:51 GMT, Frederic Thevenet
wrote:
> [JDK-8320763](https://bugs.openjdk.org/browse/JDK-8320763) fixed the
> consistency of spaces around the assignment operators in spec.gmk.in (as it
> was called then).
> Unfortunately [JDK-8321374](https://bugs.openjdk.or
[JDK-8320763](https://bugs.openjdk.org/browse/JDK-8320763) fixed the
consistency of spaces around the assignment operators in spec.gmk.in (as it was
called then).
Unfortunately [JDK-8321374](https://bugs.openjdk.org/browse/JDK-8321374)
re-introduced one such inconsistency and so this follow-up a
On Fri, 8 Dec 2023 10:48:51 GMT, Magnus Ihse Bursie wrote:
>> When building OpenJDK on the Windows platform, version information are
>> embedded as compiled resources into every native library and executable,
>> which typically contain version numbers, copyright information, product name
>> an
On Tue, 5 Dec 2023 11:15:18 GMT, Frederic Thevenet
wrote:
> When building OpenJDK on the Windows platform, version information are
> embedded as compiled resources into every native library and executable,
> which typically contain version numbers, copyright information, product na
On Wed, 6 Dec 2023 18:30:58 GMT, Erik Joelsson wrote:
>> When building OpenJDK on the Windows platform, version information are
>> embedded as compiled resources into every native library and executable,
>> which typically contain version numbers, copyright information, product name
>> and ven
On Tue, 5 Dec 2023 11:15:18 GMT, Frederic Thevenet
wrote:
> When building OpenJDK on the Windows platform, version information are
> embedded as compiled resources into every native library and executable,
> which typically contain version numbers, copyright information, product na
When building OpenJDK on the Windows platform, version information are embedded
as compiled resources into every native library and executable, which typically
contain version numbers, copyright information, product name and vendor name
(called "Company name" in this context).
Currently, the va
.
This is just our own reason for having this as an option, but it could
probably prove useful in other situations too.
On 05/12/2023 15:19, Frederic Thevenet wrote:
Hi Magnus,
On 05/12/2023 13:58, Magnus Ihse Bursie wrote:
So this is really a "--with-jdk-rc-vendor-name", since
he "CompanyName"
RC field *if* "--with-jdk-rc-vendor/company-name" is also used.
--
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France<https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92
-rc-name" can be used to override the values of
"File description" and "Product name".
If "--with-jdk-rc-company-name" isn't used, then the vendor-name value
is used instead, reproducing the same behavior than without this patch.
[1]
https://learn.microso
On Wed, 4 Oct 2023 16:27:09 GMT, Frederic Thevenet
wrote:
> When building OpenJDK on Windows using "--with-native-debug-info=external",
> the resulting debug symbols are saved in files located in the same folder as
> the corresponding executable or library and named by swa
On Wed, 25 Oct 2023 13:07:18 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or libra
On Tue, 24 Oct 2023 22:21:00 GMT, Magnus Ihse Bursie wrote:
>> Frederic Thevenet has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added a test to verify that symbols are available
>
> You don't have
ymbols (i.e. when
> "--with-external-symbols-in-bundles=public" is used).
>
> The PR also removes the existing filtering for java.pdb, jimage.pdb and
> jpackage.pdb used to guaranty the dll symbols were bundled over the ones from
> the exe, since we no longer need that.
F
On Tue, 24 Oct 2023 10:29:32 GMT, Frederic Thevenet
wrote:
> This PR addresses OS detection not working properly when running
> test-prebuilt on MSYS2, which causes some Windows specific tests to misbehave
> or fail in Github Actions.
This pull request has now been integrated.
On Wed, 25 Oct 2023 08:46:52 GMT, Frederic Thevenet
wrote:
>> This PR addresses OS detection not working properly when running
>> test-prebuilt on MSYS2, which causes some Windows specific tests to
>> misbehave or fail in Github Actions.
>
> Frederic Thevenet has
On Tue, 24 Oct 2023 21:18:44 GMT, Erik Joelsson wrote:
>> Frederic Thevenet has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use 'else ifeq' statement
>
> make/RunTestsPrebuilt.gmk line
> This PR addresses OS detection not working properly when running
> test-prebuilt on MSYS2, which causes some Windows specific tests to misbehave
> or fail in Github Actions.
Frederic Thevenet has updated the pull request incrementally with one
additional commit since the last
This PR addresses OS detection not working properly when running test-prebuilt
on MSYS2, which causes some Windows specific tests to misbehave or fail in
Github Actions.
-
Commit messages:
- 8318669: Target OS detection in 'test-prebuilt' makefile target is incorrect
when running
On Mon, 9 Oct 2023 10:21:58 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or libra
On Mon, 9 Oct 2023 10:21:58 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or libra
On Fri, 20 Oct 2023 13:46:35 GMT, Magnus Ihse Bursie wrote:
>> Indeed, I see no reason to rush the integration for this before we've
>> resolved the failing test.
>>
>> I can confirm that outside of the context of GHA, the `test-prebuilt` target
>> does not properly resolve _relative_ paths th
On Mon, 9 Oct 2023 10:21:58 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or libra
On Mon, 9 Oct 2023 10:21:58 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or libra
On Mon, 9 Oct 2023 10:21:58 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or libra
On Tue, 10 Oct 2023 16:17:17 GMT, Erik Joelsson wrote:
> In our internal build-and-test system, we provide SYMBOLS_IMAGE_DIR as an env
> variable when invoking test-prebuilt, and the test passes in this setup. From
> your description it seems our GHA are supposed to be setup in the same way,
>
On Mon, 9 Oct 2023 10:21:58 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or libra
On Mon, 9 Oct 2023 10:21:58 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or libra
On Mon, 9 Oct 2023 10:21:58 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or libra
On Mon, 9 Oct 2023 10:21:58 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or libra
On Thu, 5 Oct 2023 15:12:06 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or libra
ymbols (i.e. when
> "--with-external-symbols-in-bundles=public" is used).
>
> The PR also removes the existing filtering for java.pdb, jimage.pdb and
> jpackage.pdb used to guaranty the dll symbols were bundled over the ones from
> the exe, since we no longer need that.
F
On Fri, 6 Oct 2023 05:23:24 GMT, Julian Waters wrote:
>> Frederic Thevenet has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fixed further places where win symbol files names expected the old
>> convention.
ymbols (i.e. when
> "--with-external-symbols-in-bundles=public" is used).
>
> The PR also removes the existing filtering for java.pdb, jimage.pdb and
> jpackage.pdb used to guaranty the dll symbols were bundled over the ones from
> the exe, since we no longer need that.
Fre
On Wed, 4 Oct 2023 16:27:09 GMT, Frederic Thevenet
wrote:
> When building OpenJDK on Windows using "--with-native-debug-info=external",
> the resulting debug symbols are saved in files located in the same folder as
> the corresponding executable or library and named by swa
When building OpenJDK on Windows using "--with-native-debug-info=external", the
resulting debug symbols are saved in files located in the same folder as the
corresponding executable or library and named by swapping the extension ".exe"
or ".dll" for a ".pdb" one (or "diz" if option
"--with-nati
Hi,
I have logged a ticket over on JBS for this:
https://bugs.openjdk.org/browse/JDK-8317510
The associated PR is: https://github.com/openjdk/jdk/pull/16039
Thanks,
On 02/10/2023 20:21, Frederic Thevenet wrote:
Hi,
I would like to submit the following proposal for discussion on this
list
d as any. I would be interested to hear from others with more
experience developing and debugging on Windows though.
/Erik
[1]
https://polystream.com/behind-the-curtain-understanding-the-magic-behind-loading-symbols-in-visual-studio/
--
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Ha
named "java.pdb" (though of course I can't rule out the
possibility that there are). Overall, it seems to me a much riskier
approach.
Cheers,
David
--
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France<https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92
it is in fact stored within
the PE header of the artifact, which is how the debugger knows how to
match them. See
https://polystream.com/behind-the-curtain-understanding-the-magic-behind-loading-symbols-in-visual-studio/
--
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France<https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92
42 matches
Mail list logo
