On Tue, 16 Jul 2024 20:50:32 GMT, Lutz Schmidt wrote:
> On MacOS, files may have extended attributes attached. These attributes are
> copied together with the files. To prevent issues during further processing,
> the extended attributes of the copies must be removed. This action was
>
On Tue, 9 Apr 2024 19:43:27 GMT, Erik Joelsson wrote:
> Since we are now able to update the autoconf build-aux files, I think it's
> prudent to semi regularly do just that. I'm not aware of any particular
> platform that has been improved that would affect OpenJDK and I don't think
> we can
On Tue, 9 Apr 2024 19:43:27 GMT, Erik Joelsson wrote:
> Since we are now able to update the autoconf build-aux files, I think it's
> prudent to semi regularly do just that. I'm not aware of any particular
> platform that has been improved that would affect OpenJDK and I don't think
> we can
On Thu, 28 Mar 2024 11:33:57 GMT, Magnus Ihse Bursie wrote:
>> On AIX, we need a static libjli, since the linker cannot find other
>> libraries (like libjvm.so and libjava.so) using a relative path, as on other
>> platforms.
>>
>> However, for reasons unclear, we still build a dynamic
On Thu, 28 Mar 2024 11:30:14 GMT, Magnus Ihse Bursie wrote:
> I have pushed what I believe should be a fix.
OK, great. Testing started. I'll let you know the results.
-
PR Comment: https://git.openjdk.org/jdk/pull/18497#issuecomment-2025609933
On Tue, 26 Mar 2024 19:48:24 GMT, Magnus Ihse Bursie wrote:
> @MBaesken @RealCLanger I will need your assistance for testing this on AIX.
>
> I believe all refactorings I have done will keep the static jli build
> identical on AIX (apart from the name, of course). I have searched for jli
>
On Tue, 26 Mar 2024 09:19:19 GMT, Magnus Ihse Bursie wrote:
> The file building.{md,html} indicates the required minimum version of Xcode
> to use. When the required minimum version of Clang was updated to 13
> ([JDK-8325878](https://bugs.openjdk.org/browse/JDK-8325878)), the minimum
> Xcode
On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken wrote:
> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in
> the AIX build into this failure :
>
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLibraries.gmk:194:
On Mon, 25 Mar 2024 15:40:45 GMT, Aleksey Shipilev wrote:
> When doing [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960), I
> missed the case when sysroot would be restored from the cache. This would
> skip the configure and build steps, because it would only consult the status
> for
On Wed, 7 Feb 2024 19:50:51 GMT, Christoph Langer wrote:
> The
> [change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0)
> for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke
> get-jtreg because the way to determine t
On Thu, 8 Feb 2024 07:31:15 GMT, Magnus Ihse Bursie wrote:
>> The
>> [change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0)
>> for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke
>> get-jtreg because the way to determine the build jdk was not
On Thu, 8 Feb 2024 07:40:50 GMT, Christoph Langer wrote:
> > I don't like this approach. There must be better ways to achieve this, like
> > inputting the correct value as input to the action, or setting it as a
> > global gh variable. Where does even the `$JAVA_HOME_1
On Thu, 8 Feb 2024 07:31:15 GMT, Magnus Ihse Bursie wrote:
> I don't like this approach. There must be better ways to achieve this, like
> inputting the correct value as input to the action, or setting it as a global
> gh variable. Where does even the `$JAVA_HOME_17_arm64` come from? Is it
>
The
[change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0)
for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke get-jtreg
because the macro to determine the build jdk was not correct.
I fix this by reverting to the originally proposed way to
On Wed, 7 Feb 2024 19:30:17 GMT, George Adams wrote:
> > Opened [JDK-8325444](https://bugs.openjdk.org/browse/JDK-8325444) and
> > trying a fix in https://github.com/RealCLanger/jdk/actions/runs/7820130826
>
> I like your approach, it feels more robust
Yeah, but didn't work. Here's a PR with
On Sat, 3 Feb 2024 21:55:25 GMT, George Adams wrote:
>> Now that macOS M1 executors are [available in GitHub
>> actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/)
>> it makes sense to move the build to run on M1
On Wed, 7 Feb 2024 15:59:00 GMT, Aleksey Shipilev wrote:
> Okay, this one regressed GHA for new PRs:
> https://github.com/stefank/jdk/actions/runs/7817217154/job/21324582843
>
> ```
> Run # Build JTReg and move files to the proper locations
> realpath: bootjdk/jdk: No such file or directory
>
On Sat, 3 Feb 2024 21:55:25 GMT, George Adams wrote:
>> Now that macOS M1 executors are [available in GitHub
>> actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/)
>> it makes sense to move the build to run on M1
On Sat, 3 Feb 2024 11:49:24 GMT, George Adams wrote:
>> Now that macOS M1 executors are [available in GitHub
>> actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/)
>> it makes sense to move the build to run on M1
On Tue, 30 Jan 2024 10:34:40 GMT, Aleksey Shipilev wrote:
> See the description in the bug. This mitigates the issue by splitting out the
> only test job that has two test suites in it.
Marked as reviewed by clanger (Reviewer).
-
PR Review:
On Mon, 29 Jan 2024 13:13:44 GMT, Matthias Baesken wrote:
>> In the same spirit as
>> [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt
>> the AIX-specific code in hotspot so it uses the well-defined posix ``
>> functions, instead of `64`. By setting the define
On Mon, 29 Jan 2024 12:41:29 GMT, Julian Waters wrote:
>> In the same spirit as
>> [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt
>> the AIX-specific code in hotspot so it uses the well-defined posix ``
>> functions, instead of `64`. By setting the define
On Sat, 13 Jan 2024 17:29:58 GMT, Christoph Langer wrote:
> Hi all,
>
> This pull request contains a backport of
> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008), commit
> [68c42860](https://github.com/openjdk/jdk/commit/68c4286026bc2c0ec0f594e0b96fe03fe5
backported was authored by Matthias Baesken on 12 Jan 2024 and
was reviewed by Erik Joelsson, Christoph Langer and Magnus Ihse Bursie.
Thanks!
-
Commit messages:
- Backport 68c4286026bc2c0ec0f594e0b96fe03fe5624d6d
Changes: https://git.openjdk.org/jdk22/pull/70/files
Webrev: https
On Fri, 12 Jan 2024 13:39:33 GMT, Matthias Baesken wrote:
> > As I mentioned above, the autoconf inserting of those compiler flags can be
> > disabled by setting ac_prog_cc_stdc and >ac_prog_cxx_stdcxx to readonly
> > empty values. It's also a workaround, but is slightly less hacky than
> >
On Thu, 11 Jan 2024 14:31:47 GMT, Matthias Baesken wrote:
>> It was observed, that autoconf 2.72 added on macOS x86_64 the flag
>> -std=gnu++11 by default to CXX in the configure process .
>> This is not really wanted so better remove / filter out any -std* flags
>> added by autoconf from
On Thu, 11 Jan 2024 14:31:47 GMT, Matthias Baesken wrote:
>> It was observed, that autoconf 2.72 added on macOS x86_64 the flag
>> -std=gnu++11 by default to CXX in the configure process .
>> This is not really wanted so better remove / filter out any -std* flags
>> added by autoconf from
On Thu, 11 Jan 2024 13:08:52 GMT, Matthias Baesken wrote:
> Thanks , seems GREP was indeed 'harmed' by the parameters we use here. Btw
> there is a similar place here where we would run into the same issue
>
>
On Thu, 11 Jan 2024 11:19:01 GMT, Magnus Ihse Bursie wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust COPYRIGHT year
>
> make/autoconf/toolchain.m4 line 395:
>
>> 393: # filter out some unwanted
On Tue, 9 Jan 2024 16:18:08 GMT, Matthias Baesken wrote:
> Strange, I noticed that for some reason the
> UTIL_GET_NON_MATCHING_VALUES(cxx_filtered, $CXX, -std=c++11 -std=gnu++11)
> seems not to remove the flags as expected, did I misinterpret how
> UTIL_GET_NON_MATCHING_VALUES works ? Any
On Thu, 30 Nov 2023 09:39:54 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change will attempts to workaround an
>> issue in dsymutil?
>>
>> The previous attempt to use `--reproducer Off` has shown that it fails to
>> build on some other Xcode versions other than 14.3.1. Users
On Thu, 30 Nov 2023 10:04:49 GMT, Jaikiran Pai wrote:
> @RealCLanger Hello Christoph, in https://bugs.openjdk.org/browse/JDK-8320863
> you noted that you ran into a build issue with Xcode version 13.1. Would you
> be able to test this current proposed patch in this PR against that setup
>
On Fri, 17 Nov 2023 13:24:56 GMT, Magnus Ihse Bursie wrote:
>> The contents of the build README has been poorly kept up to date in places.
>> With the move to Github, the need to have markdown syntax that looks good on
>> Github has become apparent. The entire document has been in need for a
On Fri, 27 Oct 2023 10:43:58 GMT, Matthias Baesken wrote:
> Increase javacserver connection timeout values and max retry attempts for
> better make stability on some slower machines.
Looks good to me, these changes seem to have improved nightbuilds at SAP. But
somebody from build group should
On Thu, 12 Oct 2023 19:25:13 GMT, Mikael Vidstedt wrote:
> In GHA, the versions of macOS (note: the version used for build/test, **not**
> the target macOS version we compile for) and Xcode are starting to show age.
> It's time to update to more modern versions.
>
> This change bumps the
On Fri, 15 Sep 2023 13:27:13 GMT, Adam Farley wrote:
>> While building openjdk on aix, we see this build-fail error:
>>
>> The fopen system call failed on file
>> -f/home/.etce4tcetc./_BUILD_LIBJDWP_objectfilenames.txt
>>
>> This change expands the fix for the similar issue on macosx,
On Thu, 14 Sep 2023 14:07:20 GMT, Adam Farley wrote:
> While building openjdk on aix, we see this build-fail error:
>
> The fopen system call failed on file
> -f/home/.etce4tcetc./_BUILD_LIBJDWP_objectfilenames.txt
>
> This change expands the fix for the similar issue on macosx, and
On Fri, 25 Aug 2023 22:32:13 GMT, Xin Liu wrote:
> We are running hotspot:tier2 on github action(GHA). I have difficulty to
> execute this test on GHA:
> Runtime/cds/appcds/dynamicArchive/TestAutoCreateSharedArchiveUpgrade.java
>
> In GHA, the java property is gained from environment variable
On Wed, 9 Aug 2023 15:26:05 GMT, Andreas Steiner wrote:
>> On AIX we need the -X64 option for NM in the build. The handling is
>> equivalent to the other used tools flags like AR.
>> This change will replace the quick fix done in
>> https://bugs.openjdk.org/browse/JDK-8312466.
>
> Andreas
On Tue, 8 Aug 2023 20:14:55 GMT, Erik Joelsson wrote:
> > Looks good overall. I suggest to remove the BUILD_NM variable in this PR as
> > well. We should then wait with a final review until some folks from the
> > Oracle build team are back.
>
> What is the motivation for removing BUILD_NM? I
On Fri, 4 Aug 2023 14:42:37 GMT, Andreas Steiner wrote:
> > make/common/NativeCompilation.gmk uses NM too, is there a reason to avoid
> > the flag there? flags-other.m4 : the comment 'on AIX ...' is just stating
> > the obvious; maybe it should better mention that without -X64 we only
> >
On Fri, 4 Aug 2023 09:18:11 GMT, Aleksey Shipilev wrote:
> RISC-V is now the [official Debian
> architecture](https://lists.debian.org/debian-riscv/2023/07/msg00053.html).
> This means that the official repository is slowly building up the package
> set, while the old debian-ports repo is
On Fri, 4 Aug 2023 09:22:00 GMT, Andreas Steiner wrote:
> On AIX we need the -X64 option for NM in the build. The handling is
> equivalent to the other used tools flags like AR.
> This change will replace the quick fix done in
> https://bugs.openjdk.org/browse/JDK-8312466.
Looks good overall.
On Thu, 3 Aug 2023 16:14:06 GMT, Aleksey Shipilev wrote:
> We don't need the fully bootable Debian installation to build against.
> Therefore, we can bootstrap with `--variant=minbase`. The sysroots are about
> 5..10% smaller then.
>
> This would also make our builds more immune to issues
On Thu, 3 Aug 2023 08:16:55 GMT, Andreas Steiner wrote:
>> Add the default include location(/opt/freeware/include/) for cups on AIX.
>> With this set the additional configure parameter --with-cups-include can be
>> removed, which was needed on AIX.
>
> Andreas Steiner has updated the pull
On Wed, 2 Aug 2023 15:20:55 GMT, Andreas Steiner wrote:
>> Add the default include location(/opt/freeware/include/) for cups on AIX.
>> With this set the additional configure parameter --with-cups-include can be
>> removed, which was needed on AIX.
>
> Andreas Steiner has updated the pull
On Tue, 1 Aug 2023 16:01:44 GMT, Aleksey Shipilev wrote:
> All right then. (Puts on his own "I am actually in build group too" hat.)
Matthias is in it, too.
-
PR Comment: https://git.openjdk.org/jdk/pull/15093#issuecomment-1661178053
On Mon, 31 Jul 2023 18:17:03 GMT, Aleksey Shipilev wrote:
> Some GHA runs are now running into configuration problems after runner
> update. We need to bump the GCC versions to unbreak them.
>
> Additional testing:
> - [x] GHA
Oracle build folks seem ooo atm. But I think this one should go
On Tue, 1 Aug 2023 12:50:47 GMT, Andreas Steiner wrote:
>> Add the default include location(/opt/freeware/include/) for cups on AIX.
>> With this set the additional configure parameter --with-cups-include can be
>> removed, which was needed on AIX.
>
> Andreas Steiner has updated the pull
On Tue, 1 Aug 2023 07:28:02 GMT, Andreas Steiner wrote:
> Add the default include location(/opt/freeware/include/) for cups on AIX.
> With this set the additional configure parameter --with-cups-include can be
> removed, which was needed on AIX.
I think the check for the cups default location
On Mon, 31 Jul 2023 18:17:03 GMT, Aleksey Shipilev wrote:
> Some GHA runs are now running into configuration problems after runner
> update. We need to bump the GCC versions to unbreak them.
>
> Additional testing:
> - [x] GHA
Marked as reviewed by clanger (Reviewer).
-
PR
On Wed, 26 Jul 2023 10:29:25 GMT, Andreas Steiner wrote:
>> On AIX the 'nm' needs -X64 option.
>
> Andreas Steiner has updated the pull request incrementally with one
> additional commit since the last revision:
>
> correction of comment
No, I don't think flags-other.m4 is suited. If at
On Wed, 26 Jul 2023 10:29:25 GMT, Andreas Steiner wrote:
>> On AIX the 'nm' needs -X64 option.
>
> Andreas Steiner has updated the pull request incrementally with one
> additional commit since the last revision:
>
> correction of comment
I agree, this should be handled in toochain.m4
On Wed, 26 Jul 2023 07:21:13 GMT, Matthias Baesken wrote:
>> In case of issues in the configure step, we run into error messages like
>> this :
>>
>> configure: Current directory is /openjdk/jdk_4/build_mymachine.
>> configure: Since this is not the source root, configure will output the
>>
On Tue, 25 Jul 2023 12:00:56 GMT, Matthias Baesken wrote:
> In case of issues in the configure step, we run into error messages like this
> :
>
> configure: Current directory is /openjdk/jdk_4/build_mymachine.
> configure: Since this is not the source root, configure will output the
>
On Fri, 21 Jul 2023 11:38:13 GMT, Andreas Steiner wrote:
> When using xlc17 to build on AIX , the mentioned tool is
> /opt/IBM/openxlC/17.1.1/tools/ibm-llvm-cxxfilt instead of c++filt to check
> that global operators new and delete are not present in hotspot objects.
Marked as reviewed by
On Wed, 5 Jul 2023 15:01:52 GMT, Matthias Baesken wrote:
>> There are a few references to rt.jar in comments and in the codebase itself.
>> Some of them might be removed or adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit since the last
On Thu, 22 Jun 2023 09:21:29 GMT, Matthias Baesken wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
>> line 196:
>>
>>> 194:
>>> 195: /**
>>> 196: * Set whether or not to use ct.sym as an alternate
>>
>> As an alternate to what? This needs
On Fri, 30 Jun 2023 11:37:10 GMT, Matthias Baesken wrote:
>> There are a few references to rt.jar in comments and in the codebase itself.
>> Some of them might be removed or adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit since the last
On Mon, 19 Jun 2023 11:39:21 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which backports the fixes for
> https://bugs.openjdk.org/browse/JDK-8310259?
>
> This wasn't a clean backport because this also brings in
> https://bugs.openjdk.org/browse/JDK-8309934 which in
On Mon, 19 Jun 2023 11:39:21 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which backports the fixes for
> https://bugs.openjdk.org/browse/JDK-8310259?
>
> This wasn't a clean backport because this also brings in
> https://bugs.openjdk.org/browse/JDK-8309934 which in
On Fri, 2 Jun 2023 10:19:53 GMT, JoKern65 wrote:
> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared
> code https://github.com/openjdk/jdk/pull/14146
> It handles the part in security and servicability.
>
> Compiling on AIX with xlc17 which contains the new clang 15
On Thu, 27 Apr 2023 07:00:05 GMT, xpbob wrote:
> hi
>
> bash configure
>
> There is an warning message
>
> The following warnings were produced. Repeated here for convenience:
> WARNING: Ignoring value of GREP from the environment. Use command line
> variables instead.
Ah, yes, I must have
On Mon, 24 Apr 2023 21:44:00 GMT, Christoph Langer wrote:
>> This is an attempt to fix the issue on Windows when no cygwin Git is
>> installed or the Git for Windows installation has precedence in PATH lookup.
>> The path to the Windows GIT installation usually resides in `C:
On Mon, 24 Apr 2023 20:11:50 GMT, Christoph Langer wrote:
> This is an attempt to fix the issue on Windows when no cygwin Git is
> installed or the Git for Windows installation has precedence in PATH lookup.
> The path to the Windows GIT installation usually resides in `C:\Program
d everything else is moved into another
> macro called `BASIC_SETUP_TOOLS` that is invoked after path handling is set
> up correctly, which includes the lookup of git.
Christoph Langer has updated the pull request incrementally with one additional
commit since the last revision:
Adjust com
On Mon, 24 Apr 2023 21:04:50 GMT, Erik Joelsson wrote:
> I think this change makes sense. Given how small this set of tools is now, I
> think we should add a comment on `PLATFORM_SETUP_OPENJDK_BUILD_AND_TARGET` in
> platform.m4 saying something about needing to be careful to only use tools
>
This is an attempt to fix the issue on Windows when no cygwin Git is installed
or the Git for Windows installation has precedence in PATH lookup. The path to
the Windows GIT installation usually resides in `C:\Program Files` which
contains a space and thus needs some special handling.
There
On Fri, 21 Apr 2023 06:56:43 GMT, Christoph Langer wrote:
> We figured that seemingly the correct toolchain could be (and is) already
> installed by default on Github runners and it makes sense to skip the
> expensive installation operation which takes some 10+ minutes.
>
>
On Fri, 21 Apr 2023 12:21:39 GMT, Christoph Langer wrote:
>> We figured that seemingly the correct toolchain could be (and is) already
>> installed by default on Github runners and it makes sense to skip the
>> expensive installation operation which takes some 10+ minutes.
&g
ch would really
> need installing, e.g. 14.28.
Christoph Langer has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains four additional
commits since
On Fri, 21 Apr 2023 09:16:58 GMT, Aleksey Shipilev wrote:
>> Christoph Langer has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains one commit:
>>
>> JDK-8306658
>>
>> GHA: MSVC installat
On Fri, 21 Apr 2023 08:40:49 GMT, Christoph Langer wrote:
> This is the plain fix for the currently observed error in GHA.
>
> Will handle the optional install of the MSVC toolchain in a separate item.
Thanks for the reviews. Now the GHAs are merely done with only some jtregs for
On Fri, 21 Apr 2023 08:40:49 GMT, Christoph Langer wrote:
> This is the plain fix for the currently observed error in GHA.
>
> Will handle the optional install of the MSVC toolchain in a separate item.
This pull request has now been integrated.
Changeset: 5a00617b
Author:Christo
On Fri, 21 Apr 2023 07:51:00 GMT, Aleksey Shipilev wrote:
>> Christoph Langer has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains one commit:
>>
>> JDK-8306658
>>
>> GHA: MSVC installat
On Fri, 21 Apr 2023 08:51:31 GMT, Aleksey Shipilev wrote:
> Okay, as long as GHAs are green after this change.
It already got past the installation step. Will wait until GHA is done and
integrate if there are no new related issues.
-
PR Comment:
hich would need
> installing, e.g. 14.28.
Christoph Langer has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains one commit:
JDK-8306658
GHA: MSVC installation could be optional since it might already be
pre-installed
---
This is the plain fix for the currently observed error in GHA.
Will handle the optional install of the MSVC toolchain in a separate item.
-
Commit messages:
- JDK-8306543
Changes: https://git.openjdk.org/jdk/pull/13576/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=13576=00
On Fri, 21 Apr 2023 07:51:00 GMT, Aleksey Shipilev wrote:
> Okay, this sounds good to me. The synopsis is now incorrect, though: we do
> not fail because the component was already installed, we fail because of the
> backslashes. Suggestion: "GHA: MSVC installation should be skipped when it is
I did some more investigation for this issue.
The real root cause for the failing install seems to be that the option
--installPath nowadays needs a correct Windows path with backslashes. This
probably must have been different beforehand. So I corrected that.
However, as we figured that
On Thu, 20 Apr 2023 11:56:37 GMT, Aleksey Shipilev wrote:
> Currrent GHA fails on MSVC installation. Looks like the required versions are
> already installed in the runner image, and this is why the command fails. Our
> configure scripts look for the specific minor version, and the builds
On Thu, 20 Apr 2023 11:56:37 GMT, Aleksey Shipilev wrote:
> Currrent GHA fails on MSVC installation. Looks like the required versions are
> already installed in the runner image, and this is why the command fails. Our
> configure scripts look for the specific minor version, and the builds
On Thu, 20 Apr 2023 11:56:37 GMT, Aleksey Shipilev wrote:
> Currrent GHA fails on MSVC installation. Looks like the required versions are
> already installed in the runner image, and this is why the command fails. Our
> configure scripts look for the specific minor version, and the builds
On Thu, 20 Apr 2023 11:56:37 GMT, Aleksey Shipilev wrote:
> Currrent GHA fails on MSVC installation. Looks like the required versions are
> already installed in the runner image, and this is why the command fails. Our
> configure scripts look for the specific minor version, and the builds
On Thu, 20 Apr 2023 11:56:37 GMT, Aleksey Shipilev wrote:
> Currrent GHA fails on MSVC installation. Looks like the required versions are
> already installed in the runner image, and this is why the command fails. Our
> configure scripts look for the specific minor version, and the builds
On Mon, 6 Mar 2023 20:28:22 GMT, Christoph Langer wrote:
> When building Fedora based Linux devkits, rpm packages are downloaded from
> locations at the Fedora project.
> The latest/active versions reside under https://dl.fedoraproject.org while
> older, archived versions l
On Mon, 6 Mar 2023 20:28:22 GMT, Christoph Langer wrote:
> When building Fedora based Linux devkits, rpm packages are downloaded from
> locations at the Fedora project.
> The latest/active versions reside under https://dl.fedoraproject.org while
> older, archived versions l
On Mon, 6 Mar 2023 20:28:22 GMT, Christoph Langer wrote:
> When building Fedora based Linux devkits, rpm packages are downloaded from
> locations at the Fedora project.
> The latest/active versions reside under https://dl.fedoraproject.org while
> older, archived versions l
When building Fedora based Linux devkits, rpm packages are downloaded from
locations at the Fedora project.
The latest/active versions reside under https://dl.fedoraproject.org while
older, archived versions live at https://archives.fedoraproject.org.
It seems more releases have been archived
On Mon, 20 Feb 2023 16:34:32 GMT, Severin Gehwolf wrote:
>> The Eclipse Adoptium project recently moved its CI from ci.adoptopenjdk.net
>> to ci.adoptium.net. The link to jtreg builds needs updating
>>
>> See https://github.com/adoptium/infrastructure/issues/2932 for more context
>
> Looks
On Mon, 20 Feb 2023 14:22:40 GMT, George Adams wrote:
> The Eclipse Adoptium project recently moved its CI from ci.adoptopenjdk.net
> to ci.adoptium.net. The link to jtreg builds needs updating
>
> See https://github.com/adoptium/infrastructure/issues/2932 for more context
Marked as reviewed
On Mon, 23 Jan 2023 21:50:32 GMT, Erik Joelsson wrote:
> For a long time, we have been stuck with very old versions of the autoconf
> build-aux (config.guess and config.sub) files. Now we have legal approval for
> updating these files to versions 2022-09-17.
>
> I have gone through all the
On Mon, 23 Jan 2023 21:50:32 GMT, Erik Joelsson wrote:
> For a long time, we have been stuck with very old versions of the autoconf
> build-aux (config.guess and config.sub) files. Now we have legal approval for
> updating these files to versions 2022-09-17.
>
> I have gone through all the
On Wed, 18 Jan 2023 14:26:01 GMT, Erik Joelsson wrote:
>> This fixes an issue when the MacOS codesign identity contains spaces. For
>> that case, quoted arguments are not correctly handled in current code. We
>> need to pass doublequotes literally in the argument parameter and then have
>>
On Wed, 18 Jan 2023 11:09:21 GMT, Christoph Langer wrote:
> This fixes an issue when the MacOS codesign identity contains spaces. For
> that case, quoted arguments are not correctly handled in current code. We
> need to pass doublequotes literally in the argument parameter and
This fixes an issue when the MacOS codesign identity contains spaces. For that
case, quoted arguments are not correctly handled in current code. We need to
pass doublequotes literally in the argument parameter and then have eval handle
the call to correctly construct the args to codesign.
On Thu, 12 Jan 2023 14:28:54 GMT, Julian Waters wrote:
>> MSYS2 should be more appropriately installed into the runner's temporary
>> directory rather than inside the newly checked out repository containing all
>> the JDK's source code, as doing so may interfere with the build process and
>>
On Sun, 25 Dec 2022 06:54:16 GMT, Julian Waters wrote:
>> MSYS2 should be more appropriately installed into the runner's temporary
>> directory rather than inside the newly checked out repository containing all
>> the JDK's source code, as doing so may interfere with the build process and
>>
On Sun, 11 Dec 2022 14:13:14 GMT, Christoph Langer wrote:
> `uname -m` returns `.x86_64` after the latest upgread, instead of `x86_64`.
> Not sure why.
>
> However, we can handle this in autoconf-config.guess, to unbreak the build.
This pull request has now been integrated
On Tue, 13 Dec 2022 21:38:18 GMT, Christoph Langer wrote:
>> `uname -m` returns `.x86_64` after the latest upgread, instead of `x86_64`.
>> Not sure why.
>>
>> However, we can handle this in autoconf-config.guess, to unbreak the build.
>
> Christoph Lange
1 - 100 of 145 matches
Mail list logo
