Re: building on macOS 14
> On Nov 3, 2023, at 2:51 PM, Philip Race wrote: > > So, yes, it is a bug on the Apple side and will be fixed in (I think) a macOS > 14 update. > > -phil. So, how long do you think the JDK can continue using the macOS 13 SDK? Until macOS 14 is no longer supported? As soon as the JDK starts using a macOS 14 or later SDK, it will create a JDK that crashes on macOS 14.0 and 14.1 (and maybe more). As this crash can be predicted, would it make sense for the JDK to issue a warning (dialog) to upgrade the OS? Alan
Re: building on macOS 14
> On Nov 3, 2023, at 11:54 AM, erik.joels...@oracle.com wrote: > > If you change out the toolchain through xcode-select, then you definitely > need to reconfigure after. I would expect the configuration to be quite > messed up if you don’t.. > OK, but I think it is a bug when an error message is inserted into generated code. Is the message written to stdout instead of stderr?
Re: building on macOS 14
> On Nov 3, 2023, at 12:20 PM, Philip Race wrote: > > It seems likely since it comes along with the updated SDK but did you have > any more evidence than that ? Because the (inappropriate) call is coming from JRS. It looks like one of those obsolete API checks that is escalated to a fatal error based on the SDK linkage of the program (java, in this case).
Re: building on macOS 14
> On Nov 3, 2023, at 10:42 AM, Philip Race wrote:
>
> Are you referring to some open bug, or some thread somewhere ?
>
I found several threads that refer to this issue by searching for the error
message.
Demonstrating the issue may require using the screen menu bar.
References to Carbon menus are disallowed with AppKit menu system (see
rdar://101002625). Use instances of NSMenu and NSMenuItem directly instead.
0 AppKit0x193d7e4e4
_NSCarbonMenuCrashIfNeeded + 488
1 AppKit0x193d7e294 _NSGetCarbonMenu + 24
2 JavaRuntimeSupport0x1fb31dde8 -[JRSMenu
installCarbonEventHandlers:] + 172
3 CoreFoundation0x18faae820
__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148
4 CoreFoundation0x18fb428ec
___CFXRegistrationPost_block_invoke + 88
5 CoreFoundation0x18fb42834 _CFXRegistrationPost + 440
6 CoreFoundation0x18fa7d48c _CFXNotificationPost + 764
7 Foundation0x190b6f030 -[NSNotificationCenter
postNotificationName:object:userInfo:] + 88
8 AppKit0x193288a50 -[NSMenu
insertItem:atIndex:] + 520
9 Foundation0x190bde2d8 __NSThreadPerformPerform
+ 264
> I've also built JDK 22 on macOS 14 using the macOS 13 SDK (ie Xcode 14.3.1 as
> downloaded by our internal build
> support) and had no issues. It reads to me like you may not have a clean
> build .. but in that case I'm
> not sure why configure doesn't complain. Did you just 'swap out' the Xcode in
> a way the build maybe
> can't spot ?
>
I followed the directions to use xcode-select. Was I supposed to reconfigure
after that? I don’t remember if I did that or just a make clean.
> -phil
>
> On 11/2/23 9:48 AM, Alan Snyder wrote:
>> As you may know, a JDK built on macOS 14 using the macOS 14 SDK crashes
>> during initialization of AWT.
>>
>> (The problem appears to be Apple’s bug. It is triggered by a runtime check
>> that is enabled only in programs that were linked against the macOS 14 SDK.)
>>
>> So I tried to build JDK using the macOS 13 SDK (specifically, I was building
>> jdk21u).
>>
>> I tried both suggestions in the build documentation for configuring the
>> Xcode version.
>>
>> The first suggestion was to use xcode-select to select the previous version
>> of Xcode (version 14), which contains the macOS 13 SDK.
>>
>> This suggestion is ugly because Xcode 14 does not run on macOS 14, but it
>> might have worked.
>>
>> However, the suggestion failed because I started getting warnings like this:
>>
>> "The shared archive file was created by a different version or build of
>> HotSpot”
>>
>> Even worse, however, is that these warnings *were inserted in generated Java
>> sources*, causing the build to fail.
>>
>> For example:
>>
>> package sun.awt;
>> public class AWTIcon32_security_icon_interim16_png {
>> public static int[] security_icon_interim16_png = {
>> [0.016s][warning][cds] The shared archive file was created by a different
>> version or build of HotSpot
>> ...
>>
>> I then tried the second suggestion, configuring with
>> --with-toolchain-path=/Applications/Xcode14.app/Contents/Developer/usr/bin.
>>
>> This appears to work.
>>
>
building on macOS 14
As you may know, a JDK built on macOS 14 using the macOS 14 SDK crashes during
initialization of AWT.
(The problem appears to be Apple’s bug. It is triggered by a runtime check that
is enabled only in programs that were linked against the macOS 14 SDK.)
So I tried to build JDK using the macOS 13 SDK (specifically, I was building
jdk21u).
I tried both suggestions in the build documentation for configuring the Xcode
version.
The first suggestion was to use xcode-select to select the previous version of
Xcode (version 14), which contains the macOS 13 SDK.
This suggestion is ugly because Xcode 14 does not run on macOS 14, but it might
have worked.
However, the suggestion failed because I started getting warnings like this:
"The shared archive file was created by a different version or build of HotSpot”
Even worse, however, is that these warnings *were inserted in generated Java
sources*, causing the build to fail.
For example:
package sun.awt;
public class AWTIcon32_security_icon_interim16_png {
public static int[] security_icon_interim16_png = {
[0.016s][warning][cds] The shared archive file was created by a different
version or build of HotSpot
...
I then tried the second suggestion, configuring with
--with-toolchain-path=/Applications/Xcode14.app/Contents/Developer/usr/bin.
This appears to work.
Re: Inconsistent revision control
Thanks for the information. That indeed was the problem. Carbon Copy Cloner squirrels some files away to allow undo, a feature that I don’t usually pay attention to. Removing the extra CCC directory did the trick. Alan > On Jun 26, 2023, at 6:24 PM, Sriram Narayanan wrote: > > > > On Tue, 27 Jun 2023 at 8:34 AM, Alan Snyder <mailto:javali...@cbfiddle.com>> wrote: >> Can we start over? >> >> I am trying to do a JDK build using make. >> >> It reports an error like this: Inconsistent revision control: 17-24-55/ is >> missing .git directory >> >> at which point the build is aborted. >> >> I’d like to know what this message means, so that I can fix the problem or >> avoid it in the future. >> >> What is 17-24-55? > > > It is a directory. Please check which files are within. Try removing it ( > move it outside the entire source tree) and stay the build. > > >> >> >> If there is a missing .git directory, where would it be? >> >> The top level .git directory is present. >> >> If I do “git status” it tells me things that I expect, listing untracked >> files and changes not staged for commit. >> >> It does not complain about the repo being broken in any way. >>
Re: Inconsistent revision control
Can we start over? I am trying to do a JDK build using make. It reports an error like this: Inconsistent revision control: 17-24-55/ is missing .git directory at which point the build is aborted. I’d like to know what this message means, so that I can fix the problem or avoid it in the future. What is 17-24-55? If there is a missing .git directory, where would it be? The top level .git directory is present. If I do “git status” it tells me things that I expect, listing untracked files and changes not staged for commit. It does not complain about the repo being broken in any way.
Re: Inconsistent revision control
An incremental clone is a sync, like an incremental backup. Erik responded to a different question. I’ve gotten no closer to figuring out this problem. Feel free to be helpful, if you can. I don’t think it is helpful to nitpick my words. > On Jun 26, 2023, at 2:46 PM, David Holmes wrote: > > On 27/06/2023 7:40 am, Alan Snyder wrote: >> No, I meant incremental clone. > > What is an incremental clone? > >> After updating the directory, I tried to do an incremental build and got the >> strange message. > > So you did mean "incremental build". > >> After that, I tried doing a full build, reconfiguring, etc., but nothing >> helped. >> Now that you know that a build tool is involved, can you help me figure out >> what the problem is? > > I think Erik already addressed that. > > David > > >>> On Jun 26, 2023, at 2:32 PM, David Holmes wrote: >>> >>> On 26/06/2023 10:55 pm, Alan Snyder wrote: >>>> It would be very unlikely for CCC to fail to correctly clone the directory. >>>> It would be helpful to know what the build tool is complaining about with >>>> that message. >>> >>> Wasn't apparent any build tool was involved. You stated: >>> >>>> After an incremental clone of the directory tree, I get mysterious >>>> messages like this: >>> >>> I presume you actually meant "incremental build". >>> >>> David >>> >>>>> On Jun 25, 2023, at 10:04 PM, David Holmes >>>>> wrote: >>>>> >>>>> On 24/06/2023 12:28 pm, Alan Snyder wrote: >>>>>> I have been trying to use Carbon Copy Cloner to make a copy of an active >>>>>> jdk repo on another macOS machine for the purpose of running tests. >>>>>> The initial clone is fine. >>>>>> After an incremental clone of the directory tree, I get mysterious >>>>>> messages like this: >>>>>> Inconsistent revision control: 17-24-55/ is missing .git directory >>>>>> What is this about? >>>>>> Is there an easy way to fix this problem? >>>>> >>>>> This isn't really a build issue. I can only suggest that you check that >>>>> the copy you made actually copied across all hidden directories, e.g. >>>>> .git, as well. >>>>> >>>>> Cheers, >>>>> David >>>>> >>> >
Re: Inconsistent revision control
No, I meant incremental clone. After updating the directory, I tried to do an incremental build and got the strange message. After that, I tried doing a full build, reconfiguring, etc., but nothing helped. Now that you know that a build tool is involved, can you help me figure out what the problem is? > On Jun 26, 2023, at 2:32 PM, David Holmes wrote: > > On 26/06/2023 10:55 pm, Alan Snyder wrote: >> It would be very unlikely for CCC to fail to correctly clone the directory. >> It would be helpful to know what the build tool is complaining about with >> that message. > > Wasn't apparent any build tool was involved. You stated: > > > After an incremental clone of the directory tree, I get mysterious messages > > like this: > > I presume you actually meant "incremental build". > > David > >>> On Jun 25, 2023, at 10:04 PM, David Holmes wrote: >>> >>> On 24/06/2023 12:28 pm, Alan Snyder wrote: >>>> I have been trying to use Carbon Copy Cloner to make a copy of an active >>>> jdk repo on another macOS machine for the purpose of running tests. >>>> The initial clone is fine. >>>> After an incremental clone of the directory tree, I get mysterious >>>> messages like this: >>>> Inconsistent revision control: 17-24-55/ is missing .git directory >>>> What is this about? >>>> Is there an easy way to fix this problem? >>> >>> This isn't really a build issue. I can only suggest that you check that the >>> copy you made actually copied across all hidden directories, e.g. .git, as >>> well. >>> >>> Cheers, >>> David >>> >
Re: Inconsistent revision control
That much is obvious :-) As the script appears to run git status, I am going to take a guess that it is complaining because I have modified or untracked files in the repo. Can someone confirm that? On the other hand, I don’t see why modified or untracked files should prevent building during development. The actual message makes no sense to me. What is “17-24-55”? I was not able to find any files named “.src-rev”. > On Jun 26, 2023, at 6:08 AM, Pavel Rappo wrote: > > It appears that the error is coming from make/SourceRevision.gmk > >> On 26 Jun 2023, at 13:55, Alan Snyder wrote: >> >> It would be very unlikely for CCC to fail to correctly clone the directory. >> >> It would be helpful to know what the build tool is complaining about with >> that message. >> >>> On Jun 25, 2023, at 10:04 PM, David Holmes wrote: >>> >>> On 24/06/2023 12:28 pm, Alan Snyder wrote: >>>> I have been trying to use Carbon Copy Cloner to make a copy of an active >>>> jdk repo on another macOS machine for the purpose of running tests. >>>> The initial clone is fine. >>>> After an incremental clone of the directory tree, I get mysterious >>>> messages like this: >>>> Inconsistent revision control: 17-24-55/ is missing .git directory >>>> What is this about? >>>> Is there an easy way to fix this problem? >>> >>> This isn't really a build issue. I can only suggest that you check that the >>> copy you made actually copied across all hidden directories, e.g. .git, as >>> well. >>> >>> Cheers, >>> David >>> >> >
Re: Inconsistent revision control
It would be very unlikely for CCC to fail to correctly clone the directory. It would be helpful to know what the build tool is complaining about with that message. > On Jun 25, 2023, at 10:04 PM, David Holmes wrote: > > On 24/06/2023 12:28 pm, Alan Snyder wrote: >> I have been trying to use Carbon Copy Cloner to make a copy of an active jdk >> repo on another macOS machine for the purpose of running tests. >> The initial clone is fine. >> After an incremental clone of the directory tree, I get mysterious messages >> like this: >> Inconsistent revision control: 17-24-55/ is missing .git directory >> What is this about? >> Is there an easy way to fix this problem? > > This isn't really a build issue. I can only suggest that you check that the > copy you made actually copied across all hidden directories, e.g. .git, as > well. > > Cheers, > David >
path arguments to make
This command worked: make exploded-test TEST=jdk_awt JTREG="EXTRA_PROBLEM_LISTS=../exclude.txt;OPTIONS=-l” but it was a surprise that I needed the .. because the path was evaluated relative to the make subdirectory. Is this fixable?
Inconsistent revision control
I have been trying to use Carbon Copy Cloner to make a copy of an active jdk repo on another macOS machine for the purpose of running tests. The initial clone is fine. After an incremental clone of the directory tree, I get mysterious messages like this: Inconsistent revision control: 17-24-55/ is missing .git directory What is this about? Is there an easy way to fix this problem?
