Re: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v26]
On Thu, 16 Nov 2023 03:44:53 GMT, Phil Race wrote: >> I happened to ask around on the build-dev mailing lists about whether we >> include msvcp.dll with the JDK, here is Erik's response: >> >>> Back in JDK 8 when we used Visual Studio 2010, we used to not ship >>> msvcp*.dll. This changed when I added support for building with Visual >>> Studio 2013 [1] in JDK 9. In the patch for that bug I found this text: >>> >>>+ # If building with Visual Studio 2010, we can still use >>> _STATIC_CPPLIB to >>>+ # avoid bundling msvcpNNN.dll. Doesn't work with newer versions of >>> visual >>>+ # studio. >>> >>> So since we switched to Visual Studio 2013, we started to bundle >>> msvcp*.dll. It was only ever possible to not bundle it if you built with >>> Visual Studio 2010 (or older I suppose). It's pretty safe to say that >>> the current mainline JDK build requires msvcp.dll to be bundled. Looking >>> at the configure logic, configure will fail unless we find it and the >>> copying in open/make/modules/java.base/Copy.gmk is unconditional. >>> >>> /Erik >>> >>> [1] https://bugs.openjdk.org/browse/JDK-8042707 >> >> This may be unrelated, but I really think we should kill the std::bad_alloc >> hack in awt.dll as such > >> I happened to ask around on the build-dev mailing lists about whether we >> include msvcp.dll with the JDK, here is Erik's response: > > Yes, I saw that. It doesn't make any difference. > Although BTW the comment points out we shouldn't be doing static linking > anymore. > > >> This may be unrelated, but I really think we should kill the std::bad_alloc >> hack in awt.dll as such > > seems unrelated, yes, but I'd have to look at that, to see if there's a > reason to touch it. Itchy fingers are not a valid reason. @prrace ? - PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1893138028
[jdk22] Integrated: 8323008: filter out harmful -std* flags added by autoconf from CXX
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/68c4286026bc2c0ec0f594e0b96fe03fe5624d6d) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Matthias Baesken on 12 Jan 2024 > and was reviewed by Erik Joelsson, Christoph Langer and Magnus Ihse Bursie. > > Thanks! This pull request has now been integrated. Changeset: 8db5d865 Author:Christoph Langer URL: https://git.openjdk.org/jdk22/commit/8db5d865c1066c217c5b4e87b9e0881bfb1f5beb Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod 8323008: filter out harmful -std* flags added by autoconf from CXX Reviewed-by: mdoerr Backport-of: 68c4286026bc2c0ec0f594e0b96fe03fe5624d6d - PR: https://git.openjdk.org/jdk22/pull/70
Re: [jdk22] RFR: 8323008: filter out harmful -std* flags added by autoconf from CXX
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/68c4286026bc2c0ec0f594e0b96fe03fe5624d6d) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Matthias Baesken on 12 Jan 2024 > and was reviewed by Erik Joelsson, Christoph Langer and Magnus Ihse Bursie. > > Thanks! I think this backport makes sense to have a cleaner build when autoconf 2.72 is used. - Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk22/pull/70#pullrequestreview-1821870608
Re: RFR: 8323667: Library debug files contain non-reproducible full gcc include paths [v2]
On Mon, 15 Jan 2024 14:38:58 GMT, Andrew Leonard wrote: >> For gcc toolchains in ALLOW_ABSOLUTE_PATHS_IN_OUTPUT=False builds, this PR >> finds the location of the gcc system include paths, and adds >> -fdebug-prefix-map flags to map them to a standard location. Thus making the >> debuginfo and resulting libraries reproducible when using DevKits in >> different path locations. > > Andrew Leonard 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 the last revision: > > - 8323667: Library debug files contain non-reproducible full gcc include > paths > >Signed-off-by: Andrew Leonard > - 8323667: Library debug files contain non-reproducible full gcc include > paths > >Signed-off-by: Andrew Leonard > - Merge branch 'master' of github.com:openjdk/jdk into gcc_debug_map > - 8323667: Library debug files contain non-reproducible full gcc include > paths > >Signed-off-by: Andrew Leonard I have tested this change successfully at Eclipse Adoptium across all the various Linux gcc platforms: x64Linux, ppc64leLinux, aarch64Linux, alpineAarch64Linux, s390xLinux - PR Comment: https://git.openjdk.org/jdk/pull/17399#issuecomment-1892301655
Integrated: 8323671: DevKit build gcc libraries contain full paths to source location
On Fri, 12 Jan 2024 14:47:55 GMT, Andrew Leonard wrote: > This PR adds --with-debug-prefix-map to the building of gcc in the DevKit > make file to map the top OUTPUT_ROOT folder to a standard "devkit" path, thus > ensuring DevKit builds are reproducible regardless of the folder the DevKit > is built within. This pull request has now been integrated. Changeset: dd0694b9 Author:Andrew Leonard URL: https://git.openjdk.org/jdk/commit/dd0694b9cbbfa2defdc3b09f86f20f686688cf7b Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8323671: DevKit build gcc libraries contain full paths to source location Reviewed-by: erikj, ihse - PR: https://git.openjdk.org/jdk/pull/17400
Re: RFR: 8323667: Library debug files contain non-reproducible full gcc include paths [v2]
> For gcc toolchains in ALLOW_ABSOLUTE_PATHS_IN_OUTPUT=False builds, this PR > finds the location of the gcc system include paths, and adds > -fdebug-prefix-map flags to map them to a standard location. Thus making the > debuginfo and resulting libraries reproducible when using DevKits in > different path locations. Andrew Leonard 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 the last revision: - 8323667: Library debug files contain non-reproducible full gcc include paths Signed-off-by: Andrew Leonard - 8323667: Library debug files contain non-reproducible full gcc include paths Signed-off-by: Andrew Leonard - Merge branch 'master' of github.com:openjdk/jdk into gcc_debug_map - 8323667: Library debug files contain non-reproducible full gcc include paths Signed-off-by: Andrew Leonard - Changes: - all: https://git.openjdk.org/jdk/pull/17399/files - new: https://git.openjdk.org/jdk/pull/17399/files/7c8e81cc..587bdc41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17399=01 - incr: https://webrevs.openjdk.org/?repo=jdk=17399=00-01 Stats: 5960 lines in 105 files changed: 3733 ins; 1842 del; 385 mod Patch: https://git.openjdk.org/jdk/pull/17399.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17399/head:pull/17399 PR: https://git.openjdk.org/jdk/pull/17399
Re: RFR: 8323667: Library debug files contain non-reproducible full gcc include paths [v2]
On Fri, 12 Jan 2024 15:13:26 GMT, Erik Joelsson wrote: >> Andrew Leonard 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 the last revision: >> >> - 8323667: Library debug files contain non-reproducible full gcc include >> paths >> >>Signed-off-by: Andrew Leonard >> - 8323667: Library debug files contain non-reproducible full gcc include >> paths >> >>Signed-off-by: Andrew Leonard >> - Merge branch 'master' of github.com:openjdk/jdk into gcc_debug_map >> - 8323667: Library debug files contain non-reproducible full gcc include >> paths >> >>Signed-off-by: Andrew Leonard > > make/autoconf/flags-cflags.m4 line 193: > >> 191: >> 192: # Add gcc system include mapping => /usr/local/gcc_include >> 193: # Find location of stddef.h using build C compiler > > Why use the build compiler here? cos I made a misstake :-) Thanks for spotting @erikj79 Now fixed - PR Review Comment: https://git.openjdk.org/jdk/pull/17399#discussion_r1452452740
Re: RFR: 8323671: DevKit build gcc libraries contain full paths to source location [v2]
On Mon, 15 Jan 2024 10:17:37 GMT, Andrew Leonard wrote: >> This PR adds --with-debug-prefix-map to the building of gcc in the DevKit >> make file to map the top OUTPUT_ROOT folder to a standard "devkit" path, >> thus ensuring DevKit builds are reproducible regardless of the folder the >> DevKit is built within. > > Andrew Leonard 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 three additional > commits since the last revision: > > - Merge branch 'master' of github.com:openjdk/jdk into devkit_map > - 8323671: DevKit build gcc libraries contain full paths to source location > >Signed-off-by: Andrew Leonard > - 8323671: DevKit build gcc libraries contain full paths to source location > >Signed-off-by: Andrew Leonard Nice, thanks! I had not even thought about checking for reproducibility for the devkits. - Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17400#pullrequestreview-1821769914
Integrated: 8323637: Capture hotspot replay files in GHA
On Fri, 12 Jan 2024 10:08:57 GMT, Magnus Ihse Bursie wrote: > From the bug report: > > jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file > for erroneous and failed tests. They are also exposed under tag > `View HotSpot error log`. > > I think we can do the same thing for replay files. A replay file is > automatically generated when compiler threads encounter a fatal error. > sometimes, we can only trigger the compilation error on GHA. attached replay > file is invaluable. > > --- > > I have not figured out how to provoke a replay file on GHA, so this is > untested, but since it is based on the hs_err logic I'm pretty confident that > it works. If it turns out to be problematic, let's fix it in a follow up. This pull request has now been integrated. Changeset: c84c0ab5 Author:Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/c84c0ab52d5e08a693f7ad7d9a4772d8c1eeeaa8 Stats: 17 lines in 1 file changed: 15 ins; 1 del; 1 mod 8323637: Capture hotspot replay files in GHA Reviewed-by: shade - PR: https://git.openjdk.org/jdk/pull/17392
Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
On Mon, 8 Jan 2024 21:26:50 GMT, Jonathan Gibbons wrote:
>> Please review a patch to add support for Markdown syntax in documentation
>> comments, as described in the associated JEP.
>>
>> Notable features:
>>
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java`
>> library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons 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 seven additional
> commits since the last revision:
>
> - Merge with upstream/master
> - Merge remote-tracking branch 'upstream/master' into
> 8298405.doclet-markdown-v3
> - Address review comments
> - Fix whitespace
> - Improve handling of embedded inline taglets
> - Customize support for Markdown headings
> - JDK-8298405: Support Markdown in Documentation Comments
Here's another batch of comments. Please update `@since 22` to `@since 23`
throughout this PR.
src/jdk.compiler/share/classes/com/sun/source/doctree/DocTreeVisitor.java line
257:
> 255: *
> 256: * @implSpec Visits the provided {@code RawTextTree} node
> 257: * by calling {@code visitOther(node, p)}.
Nit: for consistency with the rest of the file, reorder `@param`-`@return`
block with the `@implSpec` tag:
Suggestion:
*
* @implSpec Visits the provided {@code RawTextTree} node
* by calling {@code visitOther(node, p)}.
*
* @param node the node being visited
* @param p a parameter value
* @return a result value
src/jdk.compiler/share/classes/com/sun/source/doctree/RawTextTree.java line 40:
> 38: * @apiNote
> 39: * This class may be used to represent tree nodes containing
> 40: * {@linkplain DocTree.Kind#MARKDOWN Markdown} text.
This means that there is one-to-many relationship between `RawTextTree` and
`DocTree.KIND`. This in turn perpetuates the pattern of checking the kind
followed by casting as opposed to more modern `instanceof` pattern matching.
There's nothing wrong with it per se, however I wonder what the rationale is
for leaving this part of the API open-ended. Is it to support other types of
raw text in the future?
src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 299:
> 297: * @param code the code
> 298: * @return a {@code RawTextTree} object
> 299: * @throws IllegalArgumentException if the kind is not a recognized
> kind for raw text
This method's implementation also throws `NullPointerException` if kind is
null, which is unusual for these methods. You can either add `@throws`, or
workaround it by using `String.valueOf(kind)` instead of `kind.toString()` down
in the implementation.
src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 303:
> 301: * @since 22
> 302: */
> 303: RawTextTree newRawTextTree(DocTree.Kind kind, String code) throws
> IllegalArgumentException;
It's unusual for a JDK method to declare a runtime exception.
src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 97:
> 95: */
> 96: public enum CommentKind {
> 97: /** The style of comments whose lines are prefixed by{@code ///}.
> */
Suggestion:
/** The style of comments whose lines are prefixed by {@code ///}. */
src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 104:
> 102:
> 103: /**
> 104: * {@return the style of the documentation comment associated with a
> tree node.}
Period is redundant:
Suggestion:
* {@return the style of the documentation comment associated with a tree
node}
src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 111:
> 109: * @since 22
> 110: */
> 111: public abstract CommentKind getDocCommentKind(TreePath path);
This method's specification says nothing about `null` that the implementation
can return.
src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 157:
> 155: * @param fileObject the content container
> 156: * @return the doc comment tree
> 157: * @throws IllegalArgumentException if the file type is not supported
It seems like this exception could've been thrown before, it's just that you
have documented it for the first time. This might be important for CSR.
src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 182:
> 180: * @return the doc comment tree
> 181: * @throws IOException if an exception occurs
> 182: * @throws IllegalArgumentException if the file type is not supported
Ditto on this newly documented exception.
src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 193:
> 191: *
> 192: * Supported file types are HTML files and Markdown
Re: RFR: 8323637: Capture hotspot replay files in GHA [v4]
On Mon, 15 Jan 2024 13:02:48 GMT, Magnus Ihse Bursie wrote: > I did not think such a run would show up in the check status in the PR..? But > maybe the bots are more intelligent than I give them credit for. 烙 I'll try > that next time, thanks! They would show up here, just not instantaneously. I do that for both initial and workflow re-runs all the time. - PR Comment: https://git.openjdk.org/jdk/pull/17392#issuecomment-1892231131
Re: RFR: 8323621: JDK build should exclude snippet class in java.lang.foreign
On Sun, 14 Jan 2024 04:07:29 GMT, Chen Liang wrote: >> make/modules/java.base/Java.gmk line 41: >> >>> 39: java/lang/classfile/snippet-files \ >>> 40: java/lang/classfile/components/snippet-files \ >>> 41: jdk/lang/foreign/snippet-files >> >> I can't find this directory in the source tree, but there is a >> `src/java.base/share/classes/java/lang/foreign/snippet-files`. Is that what >> you want to exclude? > > If possible, we should simply exclude all files in directories that have `-` > (minus sign) in their name; this is the intentional design to prevent javac > from compiling those classes as package names cannot include `-`. I agree that this piecemeal approach is not good. I think there is a JBS enhancement request to filter all "snippet-files" and "javadoc-files" everywhere. But maybe we can make it broader? Filtering on just `-` makes me a bit nervous though; it seems like it could unintentionally break at some point. But maybe filter out all `-files`? - PR Review Comment: https://git.openjdk.org/jdk/pull/17403#discussion_r1452377059
Re: RFR: 8323637: Capture hotspot replay files in GHA [v4]
On Mon, 15 Jan 2024 11:23:32 GMT, Magnus Ihse Bursie wrote: >> From the bug report: >> >> jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file >> for erroneous and failed tests. They are also exposed under tag >> `View HotSpot error log`. >> >> I think we can do the same thing for replay files. A replay file is >> automatically generated when compiler threads encounter a fatal error. >> sometimes, we can only trigger the compilation error on GHA. attached replay >> file is invaluable. >> >> --- >> >> I have not figured out how to provoke a replay file on GHA, so this is >> untested, but since it is based on the hs_err logic I'm pretty confident >> that it works. If it turns out to be problematic, let's fix it in a follow >> up. > > Magnus Ihse Bursie has updated the pull request incrementally with one > additional commit since the last revision: > > Trigger GHA with empty commit I did not think such a run would show up in the check status in the PR..? But maybe the bots are more intelligent than I give them credit for. 烙 I'll try that next time, thanks! - PR Comment: https://git.openjdk.org/jdk/pull/17392#issuecomment-1892138191
Re: RFR: 8323675: Race in jdk.javadoc-gendata
On Fri, 12 Jan 2024 17:36:09 GMT, Erik Joelsson wrote:
>> In [JDK-8318913](https://bugs.openjdk.org/browse/JDK-8318913), the
>> symbolgenerator started to look at current sources as well. This means that
>> the gensrc stage needs to be completed before this is run. A dependency was
>> added for jdk.compiler-gendata, but unfortunately the same tool is run also
>> in jdk.javadoc-gendata, where no such safeguard was created.
>>
>> The result is that the build can fail intermittently with:
>>
>> .../module-info.java:77: error: module not found on module source path
>> module java.base {
>> ^
>> error: cannot access module-info
>> cannot resolve modules
>> Exception in thread "main" java.lang.AssertionError
>> at
>> jdk.compiler.interim/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>> at
>> jdk.compiler.interim/com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
>> at
>> jdk.compiler.interim/com.sun.tools.javac.comp.Modules.allModules(Modules.java:1225)
>> at
>> jdk.compiler.interim/com.sun.tools.javac.comp.Modules.getObservableModule(Modules.java:1450)
>> at
>> jdk.compiler.interim/com.sun.tools.javac.model.JavacElements.getModuleElement(JavacElements.java:144)
>> at
>> jdk.compiler.interim/com.sun.tools.javac.model.JavacElements.getModuleElement(JavacElements.java:89)
>> at
>> build.tools.symbolgenerator.JavadocElementList.main(JavadocElementList.java:98)
>> Compiling up to 2 files for BUILD_BREAKITERATOR_BASE
>> Compiling up to 2 files for BUILD_BREAKITERATOR_LD
>> make[3]: *** [.../_element_lists.marker] Error 1
>> Gendata.gmk:74: recipe for target '.../_element_lists.marker' failed
>
> make/Main.gmk line 975:
>
>> 973: # It needs all generated java code present.
>> 974: jdk.compiler-gendata: $(JAVA_TARGETS)
>> 975: jdk.javadoc-gendata: $(JAVA_TARGETS)
>
> The comment talks about source code, but this is adding JAVA_TARGETS which is
> all compiled classes. Is the tool operating on source code or on class files?
I think it might operate on both, but I'm not sure. But my thinking was that
JAVA_TARGETS depended on GENSRC_TARGETS, which in turn would make sure that all
source code was properly generated.
Am I missing something?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17402#discussion_r1452321991
Re: RFR: 8323637: Capture hotspot replay files in GHA [v4]
On Mon, 15 Jan 2024 11:23:32 GMT, Magnus Ihse Bursie wrote: >> From the bug report: >> >> jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file >> for erroneous and failed tests. They are also exposed under tag >> `View HotSpot error log`. >> >> I think we can do the same thing for replay files. A replay file is >> automatically generated when compiler threads encounter a fatal error. >> sometimes, we can only trigger the compilation error on GHA. attached replay >> file is invaluable. >> >> --- >> >> I have not figured out how to provoke a replay file on GHA, so this is >> untested, but since it is based on the hs_err logic I'm pretty confident >> that it works. If it turns out to be problematic, let's fix it in a follow >> up. > > Magnus Ihse Bursie has updated the pull request incrementally with one > additional commit since the last revision: > > Trigger GHA with empty commit BTW, you can just go to https://github.com/magicus/jdk/actions/workflows/main.yml -- and trigger the workflow on your branch by hand, without doing any commits. Bots would pick that up. - PR Comment: https://git.openjdk.org/jdk/pull/17392#issuecomment-1892035648
Integrated: 8323700: Add fontconfig requirement to building.md for Alpine Linux
On Sun, 14 Jan 2024 03:59:59 GMT, Jan Kratochvil wrote: > Similar to JDK-8309287. This pull request has now been integrated. Changeset: 62fd26f0 Author:Jan Kratochvil Committer: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/62fd26f094133f153cab778f8afe2e9923337955 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod 8323700: Add fontconfig requirement to building.md for Alpine Linux Reviewed-by: ihse - PR: https://git.openjdk.org/jdk/pull/17415
Re: RFR: 8323637: Capture hotspot replay files in GHA [v4]
> From the bug report: > > jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file > for erroneous and failed tests. They are also exposed under tag > `View HotSpot error log`. > > I think we can do the same thing for replay files. A replay file is > automatically generated when compiler threads encounter a fatal error. > sometimes, we can only trigger the compilation error on GHA. attached replay > file is invaluable. > > --- > > I have not figured out how to provoke a replay file on GHA, so this is > untested, but since it is based on the hs_err logic I'm pretty confident that > it works. If it turns out to be problematic, let's fix it in a follow up. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Trigger GHA with empty commit - Changes: - all: https://git.openjdk.org/jdk/pull/17392/files - new: https://git.openjdk.org/jdk/pull/17392/files/a19a333d..6f242e56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17392=03 - incr: https://webrevs.openjdk.org/?repo=jdk=17392=02-03 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17392.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17392/head:pull/17392 PR: https://git.openjdk.org/jdk/pull/17392
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v2]
On Fri, 12 Jan 2024 16:15:34 GMT, Julian Waters wrote: >> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted >> autoconf flags being added to the command line, and solves the issue by >> filtering out the added flags by force. This is not optimal however, as >> doing so leaves the autoconf message that the flags were added still >> displaying during the configure process, which is confusing. Instead, >> setting a couple of fields to disable the autoconf internals responsible for >> the unwanted flag is a cleaner solution > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > make/autoconf/toolchain.m4 > > Co-authored-by: Magnus Ihse Bursie The current use of AC_PROG_CC does not fit very well with out needs. It does a lot of testing that is not needed for us (and at least on Windows, this considerably slows down configure). So it would make sense to replace it with something that only does what we need. I have thought of this before, even without the context of this bug. However, I have not pushed in this direction yet, partly because of lack of time, but also partly since I was afraid (well-grounded or not) that this was doing a lot of "autoconf black magic" that is needed elsewhere. But if you can take the time to analyze and understand what the vanilla AC_PROG_CC macro actually does, and extract just the parts that are relevant for us, and argue convincingly that the parts we're leaving out is not going to affect us, then I think it would be good. The more I've worked with autoconf, the less happy I've become with all its magic stuff, unchangable premises and bad fit for our use case. - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1891942358
Re: RFR: 8323700: Add fontconfig requirement to building.md for Alpine Linux [v2]
On Mon, 15 Jan 2024 06:18:28 GMT, Jan Kratochvil wrote: >> Similar to JDK-8309287. > > Jan Kratochvil has updated the pull request incrementally with one additional > commit since the last revision: > > Update doc/building.html Marked as reviewed by ihse (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/17415#pullrequestreview-1821464384
Re: RFR: 8323671: DevKit build gcc libraries contain full paths to source location [v2]
> This PR adds --with-debug-prefix-map to the building of gcc in the DevKit > make file to map the top OUTPUT_ROOT folder to a standard "devkit" path, thus > ensuring DevKit builds are reproducible regardless of the folder the DevKit > is built within. Andrew Leonard 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 three additional commits since the last revision: - Merge branch 'master' of github.com:openjdk/jdk into devkit_map - 8323671: DevKit build gcc libraries contain full paths to source location Signed-off-by: Andrew Leonard - 8323671: DevKit build gcc libraries contain full paths to source location Signed-off-by: Andrew Leonard - Changes: - all: https://git.openjdk.org/jdk/pull/17400/files - new: https://git.openjdk.org/jdk/pull/17400/files/35944221..c4014643 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17400=01 - incr: https://webrevs.openjdk.org/?repo=jdk=17400=00-01 Stats: 2523 lines in 71 files changed: 2012 ins; 198 del; 313 mod Patch: https://git.openjdk.org/jdk/pull/17400.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17400/head:pull/17400 PR: https://git.openjdk.org/jdk/pull/17400
