Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
Marc Poulhiès writes: > Simon Wright writes: >> gcc/ada/Changelog: >> >> 2023-11-22 Simon Wright >> >> PR ada/111909 >> >> Can we commit this one now, please? > > Hello Simon, > > Yes we can commit this one, as both Iain and Arnaud ACKed it. > > I'll create a proper commit with the change and the fixed commit log and > merge it. I've merged it as r14-5936-g396db92d3aa741. Thanks, Marc
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
Simon Wright writes: > gcc/ada/Changelog: > > 2023-11-22 Simon Wright > > PR ada/111909 > > Can we commit this one now, please? Hello Simon, Yes we can commit this one, as both Iain and Arnaud ACKed it. I'll create a proper commit with the change and the fixed commit log and merge it. Thanks, Marc
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
> On 22 Nov 2023, at 15:13, Simon Wright wrote: > > > >> On 22 Nov 2023, at 15:03, Iain Sandoe wrote: >> >> >> >>> On 22 Nov 2023, at 14:48, Iain Sandoe wrote: >>> >>> >>> On 22 Nov 2023, at 13:55, Arnaud Charlet wrote: >>> #if defined (__APPLE__) >>> -#include >> >> If removing unistd.h is intentional (i.e. you determined that it’s no >> longer >> needed for Darwin), then we should make that a separate patch. > > I thought that I’d had to include unistd.h for the first patch in this > thread; clearly not! > > What I hope will be the final version: OK here. >>> >>> also OK here, thanks >> >> I think this fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111909 ? >> if you agree then please add that to the commit. >> Iain > > git format-patch does so much, I forgot this, sorry: > > gcc/ada/Changelog: > > 2023-11-22 Simon Wright mailto:si...@pushface.org>> > > PR ada/111909 Can we commit this one now, please? —S > >> >>> Iain >>> > ——— 8< .——— > > In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current > assumption for __APPLE__ is that file names are case-insensitive > unless __arm__ or __arm64__ are defined, in which case file names are > declared case-sensitive. > > The associated comment is > "By default, we suppose filesystems aren't case sensitive on > Windows and Darwin (but they are on arm-darwin)." > > This means that on aarch64-apple-darwin, file names are treated as > case-sensitive, which is not the default case. > > The true default position is that macOS file systems are > case-insensitive, iOS file systems are case-sensitive. > > Apple provide a header file which permits a > compile-time check for the compiler target (e.g. OSX vs IOS); if > TARGET_OS_IOS is defined as 1, this is a build for iOS. > > * gcc/ada/adaint.c > (__gnat_get_file_names_case_sensitive): Split out the __APPLE__ > check and remove the checks for __arm__, __arm64__. > For Apple, file names are by default case-insensitive unless > TARGET_OS_IOS is set. > > Signed-off-by: Simon Wright >> >
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
> On 22 Nov 2023, at 15:03, Iain Sandoe wrote: > > > >> On 22 Nov 2023, at 14:48, Iain Sandoe wrote: >> >> >> >>> On 22 Nov 2023, at 13:55, Arnaud Charlet wrote: >>> >> #if defined (__APPLE__) >> -#include > > If removing unistd.h is intentional (i.e. you determined that it’s no > longer > needed for Darwin), then we should make that a separate patch. I thought that I’d had to include unistd.h for the first patch in this thread; clearly not! What I hope will be the final version: >>> >>> OK here. >> >> also OK here, thanks > > I think this fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111909 ? > if you agree then please add that to the commit. > Iain git format-patch does so much, I forgot this, sorry: gcc/ada/Changelog: 2023-11-22 Simon Wright mailto:si...@pushface.org>> PR ada/111909 > >> Iain >> >>> ——— 8< .——— In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current assumption for __APPLE__ is that file names are case-insensitive unless __arm__ or __arm64__ are defined, in which case file names are declared case-sensitive. The associated comment is "By default, we suppose filesystems aren't case sensitive on Windows and Darwin (but they are on arm-darwin)." This means that on aarch64-apple-darwin, file names are treated as case-sensitive, which is not the default case. The true default position is that macOS file systems are case-insensitive, iOS file systems are case-sensitive. Apple provide a header file which permits a compile-time check for the compiler target (e.g. OSX vs IOS); if TARGET_OS_IOS is defined as 1, this is a build for iOS. * gcc/ada/adaint.c (__gnat_get_file_names_case_sensitive): Split out the __APPLE__ check and remove the checks for __arm__, __arm64__. For Apple, file names are by default case-insensitive unless TARGET_OS_IOS is set. Signed-off-by: Simon Wright >
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
> On 22 Nov 2023, at 14:48, Iain Sandoe wrote: > > > >> On 22 Nov 2023, at 13:55, Arnaud Charlet wrote: >> > #if defined (__APPLE__) > -#include If removing unistd.h is intentional (i.e. you determined that it’s no longer needed for Darwin), then we should make that a separate patch. >>> >>> I thought that I’d had to include unistd.h for the first patch in this >>> thread; clearly not! >>> >>> What I hope will be the final version: >> >> OK here. > > also OK here, thanks I think this fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111909 ? if you agree then please add that to the commit. Iain > Iain > >> >>> ——— 8< .——— >>> >>> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current >>> assumption for __APPLE__ is that file names are case-insensitive >>> unless __arm__ or __arm64__ are defined, in which case file names are >>> declared case-sensitive. >>> >>> The associated comment is >>> "By default, we suppose filesystems aren't case sensitive on >>> Windows and Darwin (but they are on arm-darwin)." >>> >>> This means that on aarch64-apple-darwin, file names are treated as >>> case-sensitive, which is not the default case. >>> >>> The true default position is that macOS file systems are >>> case-insensitive, iOS file systems are case-sensitive. >>> >>> Apple provide a header file which permits a >>> compile-time check for the compiler target (e.g. OSX vs IOS); if >>> TARGET_OS_IOS is defined as 1, this is a build for iOS. >>> >>> * gcc/ada/adaint.c >>> (__gnat_get_file_names_case_sensitive): Split out the __APPLE__ >>> check and remove the checks for __arm__, __arm64__. >>> For Apple, file names are by default case-insensitive unless >>> TARGET_OS_IOS is set. >>> >>> Signed-off-by: Simon Wright
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
> On 22 Nov 2023, at 13:55, Arnaud Charlet wrote: > #if defined (__APPLE__) -#include >>> >>> If removing unistd.h is intentional (i.e. you determined that it’s no longer >>> needed for Darwin), then we should make that a separate patch. >> >> I thought that I’d had to include unistd.h for the first patch in this >> thread; clearly not! >> >> What I hope will be the final version: > > OK here. also OK here, thanks Iain > >> ——— 8< .——— >> >> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current >> assumption for __APPLE__ is that file names are case-insensitive >> unless __arm__ or __arm64__ are defined, in which case file names are >> declared case-sensitive. >> >> The associated comment is >> "By default, we suppose filesystems aren't case sensitive on >> Windows and Darwin (but they are on arm-darwin)." >> >> This means that on aarch64-apple-darwin, file names are treated as >> case-sensitive, which is not the default case. >> >> The true default position is that macOS file systems are >> case-insensitive, iOS file systems are case-sensitive. >> >> Apple provide a header file which permits a >> compile-time check for the compiler target (e.g. OSX vs IOS); if >> TARGET_OS_IOS is defined as 1, this is a build for iOS. >> >> * gcc/ada/adaint.c >> (__gnat_get_file_names_case_sensitive): Split out the __APPLE__ >> check and remove the checks for __arm__, __arm64__. >> For Apple, file names are by default case-insensitive unless >> TARGET_OS_IOS is set. >> >> Signed-off-by: Simon Wright
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
> On Nov 22, 2023, at 8:54 AM, Simon Wright wrote: > > On 21 Nov 2023, at 23:13, Iain Sandoe wrote: > >>> #if defined (__APPLE__) >>> -#include >> >> If removing unistd.h is intentional (i.e. you determined that it’s no longer >> needed for Darwin), then we should make that a separate patch. > > I thought that I’d had to include unistd.h for the first patch in this > thread; clearly not! > > What I hope will be the final version: > > ——— 8< .——— > > In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current > assumption for __APPLE__ is that file names are case-insensitive > unless __arm__ or __arm64__ are defined, in which case file names are > declared case-sensitive. > > The associated comment is > "By default, we suppose filesystems aren't case sensitive on > Windows and Darwin (but they are on arm-darwin)." > > This means that on aarch64-apple-darwin, file names are treated as > case-sensitive, which is not the default case. > > The true default position is that macOS file systems are > case-insensitive, iOS file systems are case-sensitive. Sort of. The most common choices for Mac OS file system type are indeed case insensitive, but it also allows case sensitive file systems. paul
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
> >> #if defined (__APPLE__) > >> -#include > > > > If removing unistd.h is intentional (i.e. you determined that it’s no longer > > needed for Darwin), then we should make that a separate patch. > > I thought that I’d had to include unistd.h for the first patch in this > thread; clearly not! > > What I hope will be the final version: OK here. > ——— 8< .——— > > In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current > assumption for __APPLE__ is that file names are case-insensitive > unless __arm__ or __arm64__ are defined, in which case file names are > declared case-sensitive. > > The associated comment is > "By default, we suppose filesystems aren't case sensitive on > Windows and Darwin (but they are on arm-darwin)." > > This means that on aarch64-apple-darwin, file names are treated as > case-sensitive, which is not the default case. > > The true default position is that macOS file systems are > case-insensitive, iOS file systems are case-sensitive. > > Apple provide a header file which permits a > compile-time check for the compiler target (e.g. OSX vs IOS); if > TARGET_OS_IOS is defined as 1, this is a build for iOS. > > * gcc/ada/adaint.c > (__gnat_get_file_names_case_sensitive): Split out the __APPLE__ > check and remove the checks for __arm__, __arm64__. > For Apple, file names are by default case-insensitive unless > TARGET_OS_IOS is set. > > Signed-off-by: Simon Wright
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
On 21 Nov 2023, at 23:13, Iain Sandoe wrote:
>> #if defined (__APPLE__)
>> -#include
>
> If removing unistd.h is intentional (i.e. you determined that it’s no longer
> needed for Darwin), then we should make that a separate patch.
I thought that I’d had to include unistd.h for the first patch in this thread;
clearly not!
What I hope will be the final version:
——— 8< .———
In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current
assumption for __APPLE__ is that file names are case-insensitive
unless __arm__ or __arm64__ are defined, in which case file names are
declared case-sensitive.
The associated comment is
"By default, we suppose filesystems aren't case sensitive on
Windows and Darwin (but they are on arm-darwin)."
This means that on aarch64-apple-darwin, file names are treated as
case-sensitive, which is not the default case.
The true default position is that macOS file systems are
case-insensitive, iOS file systems are case-sensitive.
Apple provide a header file which permits a
compile-time check for the compiler target (e.g. OSX vs IOS); if
TARGET_OS_IOS is defined as 1, this is a build for iOS.
* gcc/ada/adaint.c
(__gnat_get_file_names_case_sensitive): Split out the __APPLE__
check and remove the checks for __arm__, __arm64__.
For Apple, file names are by default case-insensitive unless
TARGET_OS_IOS is set.
Signed-off-by: Simon Wright
---
gcc/ada/adaint.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
index bb4ed2607e5..2e9c59ae958 100644
--- a/gcc/ada/adaint.c
+++ b/gcc/ada/adaint.c
@@ -85,6 +85,7 @@
#if defined (__APPLE__)
#include
+#include
#endif
#if defined (__hpux__)
@@ -613,11 +614,18 @@ __gnat_get_file_names_case_sensitive (void)
else
{
/* By default, we suppose filesystems aren't case sensitive on
-Windows and Darwin (but they are on arm-darwin). */
-#if defined (WINNT) || defined (__DJGPP__) \
- || (defined (__APPLE__) && !(defined (__arm__) || defined (__arm64__)))
+Windows or DOS. */
+#if defined (WINNT) || defined (__DJGPP__)
file_names_case_sensitive_cache = 0;
+#elif defined (__APPLE__)
+ /* By default, macOS volumes are case-insensitive, iOS
+volumes are case-sensitive. */
+#if TARGET_OS_IOS
+ file_names_case_sensitive_cache = 1;
#else
+ file_names_case_sensitive_cache = 0;
+#endif
+#else /* Neither Windows nor Apple. */
file_names_case_sensitive_cache = 1;
#endif
}
--
2.37.1 (Apple Git-137.1)
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
Hi Simon, Thanks for persevering - I will keep the original patch, pending some chance to fix the earlier OS issues. I’ll check this on OS versions with older SDKs that do not have the TARGET_OS_XX conditionals. - One small nit below, Iain > On 21 Nov 2023, at 20:25, Simon Wright wrote: > > On 21 Nov 2023, at 11:22, Iain Sandoe wrote: >> >> Hello Simon, Arno, >> >>> On 17 Nov 2023, at 13:43, Simon Wright wrote: >>> > Apple’s naming is definitely confusing in this area! > > In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS > X variant, > which covers OSX, IOS, Watch … ; to determine which kind of device, you > have to check the > specific define for that device - OSX corresponds to macOS, i.e. laptops, > desktops. > > In older SDKs (specifically Xcode 3, for macOS Leopard (darwin 9) as > mentioned by Iain) > TARGET_OS_MAC means code is being generated for "Mac OS", i.e. laptops, > desktops as > above; TARGET_OS_OSX is undefined (as are TARGET_OS_IOS etc). > > If we are compiling for macOS, using a current macOS SDK, then > TARGET_OS_MAC is > set to 1 and TARGET_OS_OSX is set to 1. > > If we were compiling for iOS, using a current iOS SDK as supplied with > current Xcode, then > TARGET_OS_MAC would be set to 1, TARGET_OS_OSX would be set to 0, and > TARGET_OS_IOS would be set to 1. OK so then the following is sufficient for our needs: #elif defined (__APPLE__) /* By default, macOS volumes are case-insensitive, iOS volumes are case-sensitive. */ #if TARGET_OS_IOS file_names_case_sensitive_cache = 1; #else file_names_case_sensitive_cache = 0; #endif #else /* Neither Windows nor Apple. */ file_names_case_sensitive_cache = 1; #endif We want the default to be 0, and we only care about setting it to 1 on iOS for recent SDKs, the case of an old SDK and iOS isn't interesting at this stage, so it's fine if we set the var to 0 in this scenario. >>> >>> I can’t speak for Darwin maintainers, so I’ll leave it to Iain to comment >>> on this suggestion. >> >> * We are far away from having support for watchOS (32b Arm64) so I think >> that is a bridge >> that can be crossed later. >> >> * It seems to me that the proposed solution is better matched to the >> defaults on macOS/iOS. >> >> * It would be better to have an automatic solution for folks (like me) who >> do use case- >> sensitive file systems on macOS, but we do not have the resources right now >> to figure >> out what is not working on the earlier systems. I looked briefly, and found >> that the libcalls >> are thin wrappers on a syscall, so that the different behaviours we are >> seeing on earlier >> OS versions reflects the kernel’s handling of the provided path, rather than >> some improvement >> in newer library functions. That suggests to me that we will need to wrap >> the call in some more >> complex logic to obtain the correct response. >> >> So, I think that (with a test across the range of supported OS versions) the >> proposed >> solution is an incremental improvement and we should take it. >> >> When there’s a final proposed patch, I can add it into my testing across the >> systems. >> >> Iain > > Herewith my proposed patch (still in thread, though the subject of the thread > isn’t still appropriate): > > In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current > assumption for __APPLE__ is that file names are case-insensitive > unless __arm__ or __arm64__ are defined, in which case file names are > declared case-sensitive. > > The associated comment is > "By default, we suppose filesystems aren't case sensitive on > Windows and Darwin (but they are on arm-darwin)." > > This means that on aarch64-apple-darwin, file names are treated as > case-sensitive, which is not the default case. > > The true default position is that macOS file systems are > case-insensitive, iOS file systems are case-sensitive. > > Apple provide a header file which permits a > compile-time check for the compiler target (e.g. OSX vs IOS); if > TARGET_OS_IOS is defined as 1, this is a build for iOS. > > gcc/ada/Changelog: > > 2023-11-21 Simon Wright > > * gcc/ada/adaint.c (__gnat_get_file_names_case_sensitive): > Split out the __APPLE__ check and remove the checks for __arm__, > __arm64__. > For Apple, file names are by default case-insensitive unless > TARGET_OS_IOS is set. > > Signed-off-by: Simon Wright > --- > gcc/ada/adaint.c | 15 +++ > 1 file changed, 11 insertions(+), 4 deletions(-) > > diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c > index bb4ed2607e5..0222791ed68 100644 > --- a/gcc/ada/adaint.c > +++ b/gcc/ada/adaint.c > @@ -84,7 +84,7 @@ > #endif /* VxWorks */ > > #if defined (__APPLE__) > -#include If
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
On 21 Nov 2023, at 11:22, Iain Sandoe wrote:
>
> Hello Simon, Arno,
>
>> On 17 Nov 2023, at 13:43, Simon Wright wrote:
>>
>>>
Apple’s naming is definitely confusing in this area!
In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS
X variant,
which covers OSX, IOS, Watch … ; to determine which kind of device, you
have to check the
specific define for that device - OSX corresponds to macOS, i.e. laptops,
desktops.
In older SDKs (specifically Xcode 3, for macOS Leopard (darwin 9) as
mentioned by Iain)
TARGET_OS_MAC means code is being generated for "Mac OS", i.e. laptops,
desktops as
above; TARGET_OS_OSX is undefined (as are TARGET_OS_IOS etc).
If we are compiling for macOS, using a current macOS SDK, then
TARGET_OS_MAC is
set to 1 and TARGET_OS_OSX is set to 1.
If we were compiling for iOS, using a current iOS SDK as supplied with
current Xcode, then
TARGET_OS_MAC would be set to 1, TARGET_OS_OSX would be set to 0, and
TARGET_OS_IOS would be set to 1.
>>>
>>> OK so then the following is sufficient for our needs:
>>>
>>> #elif defined (__APPLE__)
>>> /* By default, macOS volumes are case-insensitive, iOS
>>>volumes are case-sensitive. */
>>> #if TARGET_OS_IOS
>>> file_names_case_sensitive_cache = 1;
>>> #else
>>> file_names_case_sensitive_cache = 0;
>>> #endif
>>> #else /* Neither Windows nor Apple. */
>>> file_names_case_sensitive_cache = 1;
>>> #endif
>>>
>>> We want the default to be 0, and we only care about setting it to 1 on iOS
>>> for recent
>>> SDKs, the case of an old SDK and iOS isn't interesting at this stage, so
>>> it's fine if we set
>>> the var to 0 in this scenario.
>>
>> I can’t speak for Darwin maintainers, so I’ll leave it to Iain to comment on
>> this suggestion.
>
> * We are far away from having support for watchOS (32b Arm64) so I think that
> is a bridge
> that can be crossed later.
>
> * It seems to me that the proposed solution is better matched to the defaults
> on macOS/iOS.
>
> * It would be better to have an automatic solution for folks (like me) who do
> use case-
> sensitive file systems on macOS, but we do not have the resources right now
> to figure
> out what is not working on the earlier systems. I looked briefly, and found
> that the libcalls
> are thin wrappers on a syscall, so that the different behaviours we are
> seeing on earlier
> OS versions reflects the kernel’s handling of the provided path, rather than
> some improvement
> in newer library functions. That suggests to me that we will need to wrap
> the call in some more
> complex logic to obtain the correct response.
>
> So, I think that (with a test across the range of supported OS versions) the
> proposed
> solution is an incremental improvement and we should take it.
>
> When there’s a final proposed patch, I can add it into my testing across the
> systems.
>
> Iain
Herewith my proposed patch (still in thread, though the subject of the thread
isn’t still appropriate):
In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current
assumption for __APPLE__ is that file names are case-insensitive
unless __arm__ or __arm64__ are defined, in which case file names are
declared case-sensitive.
The associated comment is
"By default, we suppose filesystems aren't case sensitive on
Windows and Darwin (but they are on arm-darwin)."
This means that on aarch64-apple-darwin, file names are treated as
case-sensitive, which is not the default case.
The true default position is that macOS file systems are
case-insensitive, iOS file systems are case-sensitive.
Apple provide a header file which permits a
compile-time check for the compiler target (e.g. OSX vs IOS); if
TARGET_OS_IOS is defined as 1, this is a build for iOS.
gcc/ada/Changelog:
2023-11-21 Simon Wright mailto:si...@pushface.org>>
* gcc/ada/adaint.c (__gnat_get_file_names_case_sensitive):
Split out the __APPLE__ check and remove the checks for __arm__,
__arm64__.
For Apple, file names are by default case-insensitive unless
TARGET_OS_IOS is set.
Signed-off-by: Simon Wright
---
gcc/ada/adaint.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
index bb4ed2607e5..0222791ed68 100644
--- a/gcc/ada/adaint.c
+++ b/gcc/ada/adaint.c
@@ -84,7 +84,7 @@
#endif /* VxWorks */
#if defined (__APPLE__)
-#include
+#include
#endif
#if defined (__hpux__)
@@ -613,11 +613,18 @@ __gnat_get_file_names_case_sensitive (void)
else
{
/* By default, we suppose filesystems aren't case sensitive on
-Windows and Darwin (but they are on arm-darwin). */
-#if defined (WINNT) || defined (__DJGPP__) \
- || (defined (__APPLE__) && !(defined (__arm__) || defined (__arm64__)))
+Windows or DOS. */
+#if defined (WINNT) || defined
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
Hello Simon, Arno, > On 17 Nov 2023, at 13:43, Simon Wright wrote: > >> >>> Apple’s naming is definitely confusing in this area! >>> >>> In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS X >>> variant, >>> which covers OSX, IOS, Watch … ; to determine which kind of device, you >>> have to check the >>> specific define for that device - OSX corresponds to macOS, i.e. laptops, >>> desktops. >>> >>> In older SDKs (specifically Xcode 3, for macOS Leopard (darwin 9) as >>> mentioned by Iain) >>> TARGET_OS_MAC means code is being generated for "Mac OS", i.e. laptops, >>> desktops as >>> above; TARGET_OS_OSX is undefined (as are TARGET_OS_IOS etc). >>> >>> If we are compiling for macOS, using a current macOS SDK, then >>> TARGET_OS_MAC is >>> set to 1 and TARGET_OS_OSX is set to 1. >>> >>> If we were compiling for iOS, using a current iOS SDK as supplied with >>> current Xcode, then >>> TARGET_OS_MAC would be set to 1, TARGET_OS_OSX would be set to 0, and >>> TARGET_OS_IOS would be set to 1. >> >> OK so then the following is sufficient for our needs: >> >> #elif defined (__APPLE__) >> /* By default, macOS volumes are case-insensitive, iOS >> volumes are case-sensitive. */ >> #if TARGET_OS_IOS >> file_names_case_sensitive_cache = 1; >> #else >> file_names_case_sensitive_cache = 0; >> #endif >> #else /* Neither Windows nor Apple. */ >> file_names_case_sensitive_cache = 1; >> #endif >> >> We want the default to be 0, and we only care about setting it to 1 on iOS >> for recent >> SDKs, the case of an old SDK and iOS isn't interesting at this stage, so >> it's fine if we set >> the var to 0 in this scenario. > > I can’t speak for Darwin maintainers, so I’ll leave it to Iain to comment on > this suggestion. * We are far away from having support for watchOS (32b Arm64) so I think that is a bridge that can be crossed later. * It seems to me that the proposed solution is better matched to the defaults on macOS/iOS. * It would be better to have an automatic solution for folks (like me) who do use case- sensitive file systems on macOS, but we do not have the resources right now to figure out what is not working on the earlier systems. I looked briefly, and found that the libcalls are thin wrappers on a syscall, so that the different behaviours we are seeing on earlier OS versions reflects the kernel’s handling of the provided path, rather than some improvement in newer library functions. That suggests to me that we will need to wrap the call in some more complex logic to obtain the correct response. So, I think that (with a test across the range of supported OS versions) the proposed solution is an incremental improvement and we should take it. When there’s a final proposed patch, I can add it into my testing across the systems. Iain
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
> >> Apple’s naming is definitely confusing in this area! >> >> In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS X >> variant, >> which covers OSX, IOS, Watch … ; to determine which kind of device, you have >> to check the >> specific define for that device - OSX corresponds to macOS, i.e. laptops, >> desktops. >> >> In older SDKs (specifically Xcode 3, for macOS Leopard (darwin 9) as >> mentioned by Iain) >> TARGET_OS_MAC means code is being generated for "Mac OS", i.e. laptops, >> desktops as >> above; TARGET_OS_OSX is undefined (as are TARGET_OS_IOS etc). >> >> If we are compiling for macOS, using a current macOS SDK, then TARGET_OS_MAC >> is >> set to 1 and TARGET_OS_OSX is set to 1. >> >> If we were compiling for iOS, using a current iOS SDK as supplied with >> current Xcode, then >> TARGET_OS_MAC would be set to 1, TARGET_OS_OSX would be set to 0, and >> TARGET_OS_IOS would be set to 1. > > OK so then the following is sufficient for our needs: > > #elif defined (__APPLE__) > /* By default, macOS volumes are case-insensitive, iOS > volumes are case-sensitive. */ > #if TARGET_OS_IOS >file_names_case_sensitive_cache = 1; > #else >file_names_case_sensitive_cache = 0; > #endif > #else /* Neither Windows nor Apple. */ >file_names_case_sensitive_cache = 1; > #endif > > We want the default to be 0, and we only care about setting it to 1 on iOS > for recent > SDKs, the case of an old SDK and iOS isn't interesting at this stage, so it's > fine if we set > the var to 0 in this scenario. I can’t speak for Darwin maintainers, so I’ll leave it to Iain to comment on this suggestion.
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
> OK so then the following is sufficient for our needs: > > #elif defined (__APPLE__) >/* By default, macOS volumes are case-insensitive, iOS > volumes are case-sensitive. */ > #if TARGET_OS_IOS > file_names_case_sensitive_cache = 1; > #else > file_names_case_sensitive_cache = 0; > #endif > #else /* Neither Windows nor Apple. */ > file_names_case_sensitive_cache = 1; > #endif Actually you can simplify even further: #elif defined (__APPLE__) && !defined(TARGET_OS_IOS) /* By default, macOS volumes are case-insensitive, iOS volumes are case-sensitive, so fallback below. */ file_names_case_sensitive_cache = 0; #else /* Neither Windows nor macOS. */ file_names_case_sensitive_cache = 1; #endif Arno
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
> Apple’s naming is definitely confusing in this area! > > In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS X > variant, > which covers OSX, IOS, Watch … ; to determine which kind of device, you have > to check the > specific define for that device - OSX corresponds to macOS, i.e. laptops, > desktops. > > In older SDKs (specifically Xcode 3, for macOS Leopard (darwin 9) as > mentioned by Iain) > TARGET_OS_MAC means code is being generated for "Mac OS", i.e. laptops, > desktops as > above; TARGET_OS_OSX is undefined (as are TARGET_OS_IOS etc). > > If we are compiling for macOS, using a current macOS SDK, then TARGET_OS_MAC > is > set to 1 and TARGET_OS_OSX is set to 1. > > If we were compiling for iOS, using a current iOS SDK as supplied with > current Xcode, then > TARGET_OS_MAC would be set to 1, TARGET_OS_OSX would be set to 0, and > TARGET_OS_IOS would be set to 1. OK so then the following is sufficient for our needs: #elif defined (__APPLE__) /* By default, macOS volumes are case-insensitive, iOS volumes are case-sensitive. */ #if TARGET_OS_IOS file_names_case_sensitive_cache = 1; #else file_names_case_sensitive_cache = 0; #endif #else /* Neither Windows nor Apple. */ file_names_case_sensitive_cache = 1; #endif We want the default to be 0, and we only care about setting it to 1 on iOS for recent SDKs, the case of an old SDK and iOS isn't interesting at this stage, so it's fine if we set the var to 0 in this scenario. Arno
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
>>> Please simplify the above to (untested): >>> >>> #elif defined (__APPLE__) >>> /* By default, macOS volumes are case-insensitive, iOS >>> volumes are case-sensitive. */ >>> #if TARGET_OS_MAC/* macOS, in older SDK. */ >>>file_names_case_sensitive_cache = 0; >>> #elif TARGET_OS_OSX /* macOS, in recent SDK. */ >>>file_names_case_sensitive_cache = 0; >>> #else/* assume iOS. */ >>>file_names_case_sensitive_cache = 1; >>> #endif >>> #else /* Neither Windows nor Apple. */ >>> file_names_case_sensitive_cache = 1; >>> #endif >>> >>> which is simpler and more readable and should be equivalent AFAICT. >>> >>> OK with the above change. >>> >>> Arno >> >> Sorry, but that wouldn’t work. > > Then invert the two first tests, that doesn't change the gist of my > suggestion to simplify the > tests. Apple’s naming is definitely confusing in this area! In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS X variant, which covers OSX, IOS, Watch … ; to determine which kind of device, you have to check the specific define for that device - OSX corresponds to macOS, i.e. laptops, desktops. In older SDKs (specifically Xcode 3, for macOS Leopard (darwin 9) as mentioned by Iain) TARGET_OS_MAC means code is being generated for "Mac OS", i.e. laptops, desktops as above; TARGET_OS_OSX is undefined (as are TARGET_OS_IOS etc). If we are compiling for macOS, using a current macOS SDK, then TARGET_OS_MAC is set to 1 and TARGET_OS_OSX is set to 1. If we were compiling for iOS, using a current iOS SDK as supplied with current Xcode, then TARGET_OS_MAC would be set to 1, TARGET_OS_OSX would be set to 0, and TARGET_OS_IOS would be set to 1. If TARGET_OS_OSX is defined then — we’re generating code for a recent Apple device, TARGET_OS_MAC could mean — macOS, iOS, iWatch etc, so we can’t use it. if TARGET_OS_OSX is 1 then — we’re generating code for macOS, file names are case-insensitive. else — we’re trying to generate code for a device which GCC doesn’t support at — the moment, e.g. iOS; let’s assume file names are case-sensitive.. end if else if TARGET_OS_MAC is 1 then — we’re generating code for macOS, file names are case-insensitve. else — let’s assume file names are case-sensitive. end if end if What we’re doing here is providing a default behaviour; it’s certainly the case that Apple filesystems are by default case-insensitive. If a user has code on case-sensitive file systems (Apple or other, e.g. unix-over-NFS) it’s up to them to use GNAT_FILE_NAME_CASE_SENSITIVE. >> TargetConditionals.h is created by Apple as part of SDK construction, so the >> TARGET_* macros are defined directly (#define TARGET_OS_OSX 1), >> >> In a newer macOS SDK, both TARGET_OS_MAC and TARGET_OS_OSX are defined and >> set to 1, and TARGET_OS_MAC covers OSX (macOS), IOS, TV, WATCH and others. >> In an older macOS SDK, TARGET_OS_MAC is defined and set to 1, and none of >> the others are defined at all.
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
> > Please simplify the above to (untested): > > > > #elif defined (__APPLE__) > >/* By default, macOS volumes are case-insensitive, iOS > > volumes are case-sensitive. */ > > #if TARGET_OS_MAC/* macOS, in older SDK. */ > > file_names_case_sensitive_cache = 0; > > #elif TARGET_OS_OSX /* macOS, in recent SDK. */ > > file_names_case_sensitive_cache = 0; > > #else/* assume iOS. */ > > file_names_case_sensitive_cache = 1; > > #endif > > #else /* Neither Windows nor Apple. */ > > file_names_case_sensitive_cache = 1; > > #endif > > > > which is simpler and more readable and should be equivalent AFAICT. > > > > OK with the above change. > > > > Arno > > Sorry, but that wouldn’t work. Then invert the two first tests, that doesn't change the gist of my suggestion to simplify the tests. > TargetConditionals.h is created by Apple as part of SDK construction, so the > TARGET_* macros are defined directly (#define TARGET_OS_OSX 1), > > In a newer macOS SDK, both TARGET_OS_MAC and TARGET_OS_OSX are defined and > set to 1, and TARGET_OS_MAC covers OSX (macOS), IOS, TV, WATCH and others. > In an older macOS SDK, TARGET_OS_MAC is defined and set to 1, and none of the > others are defined at all.
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
On 17 Nov 2023, at 08:37, Arnaud Charlet wrote:
>
>> Also, should the test code below (between %%%) be included in the
>> testsuite?
>
> It would be good but tests shouldn't output anything, they should be self
> testing,
> and you will need to deal with making the test portable to all targets.
>
> Given that the compiler itself uses this feature, I don't think this is worth
> the trouble.
OK
>> @@ -613,12 +613,25 @@ __gnat_get_file_names_case_sensitive (void)
>> else
>> {
>>/* By default, we suppose filesystems aren't case sensitive on
>> - Windows and Darwin (but they are on arm-darwin). */
>> -#if defined (WINNT) || defined (__DJGPP__) \
>> - || (defined (__APPLE__) && !(defined (__arm__) || defined (__arm64__)))
>> + Windows or DOS. */
>> +#if defined (WINNT) || defined (__DJGPP__)
>> + file_names_case_sensitive_cache = 0;
>> +#elif defined (__APPLE__)
>> + /* By default, macOS volumes are case-insensitive, iOS
>> + volumes are case-sensitive. */
>> +#if defined (TARGET_OS_OSX) /* In recent SDK. */
>> +#if TARGET_OS_OSX/* macOS. */
>>file_names_case_sensitive_cache = 0;
>> #else
>>file_names_case_sensitive_cache = 1;
>> +#endif
>> +#elif TARGET_OS_MAC/* macOS, in older SDK. */
>> + file_names_case_sensitive_cache = 0;
>> +#else
>> + file_names_case_sensitive_cache = 1;
>> +#endif
>> +#else /* Neither Windows nor Apple. */
>> + file_names_case_sensitive_cache = 1;
>> #endif
>
> Please simplify the above to (untested):
>
> #elif defined (__APPLE__)
>/* By default, macOS volumes are case-insensitive, iOS
> volumes are case-sensitive. */
> #if TARGET_OS_MAC/* macOS, in older SDK. */
> file_names_case_sensitive_cache = 0;
> #elif TARGET_OS_OSX /* macOS, in recent SDK. */
> file_names_case_sensitive_cache = 0;
> #else/* assume iOS. */
> file_names_case_sensitive_cache = 1;
> #endif
> #else /* Neither Windows nor Apple. */
>file_names_case_sensitive_cache = 1;
> #endif
>
> which is simpler and more readable and should be equivalent AFAICT.
>
> OK with the above change.
>
> Arno
Sorry, but that wouldn’t work.
TargetConditionals.h is created by Apple as part of SDK construction, so the
TARGET_* macros are defined directly (#define TARGET_OS_OSX 1),
In a newer macOS SDK, both TARGET_OS_MAC and TARGET_OS_OSX are defined and set
to 1, and TARGET_OS_MAC covers OSX (macOS), IOS, TV, WATCH and others.
In an older macOS SDK, TARGET_OS_MAC is defined and set to 1, and none of the
others are defined at all.
This is from the current TargetConditionals.h:
*
+---+
*| TARGET_OS_MAC
|
*| +-+ +-+
+---+ |
*| | | | TARGET_OS_IPHONE | |
| |
*| | | | +-+ ++ +---+ ++ | |
| |
*| | | | | IOS | || | | || | |
| |
*| | OSX | | | +-+ | | TV | | WATCH | | BRIDGE | | | DRIVERKIT
| |
*| | | | | | MACCATALYST | | || | | || | |
| |
*| | | | | +-+ | || | | || | |
| |
*| | | | +-+ ++ +---+ ++ | |
| |
*| +-+ +-+
+---+ |
*
+---+
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
> Also, should the test code below (between %%%) be included in the
> testsuite?
It would be good but tests shouldn't output anything, they should be self
testing,
and you will need to deal with making the test portable to all targets.
Given that the compiler itself uses this feature, I don't think this is worth
the trouble.
> @@ -613,12 +613,25 @@ __gnat_get_file_names_case_sensitive (void)
>else
> {
> /* By default, we suppose filesystems aren't case sensitive on
> - Windows and Darwin (but they are on arm-darwin). */
> -#if defined (WINNT) || defined (__DJGPP__) \
> - || (defined (__APPLE__) && !(defined (__arm__) || defined (__arm64__)))
> + Windows or DOS. */
> +#if defined (WINNT) || defined (__DJGPP__)
> + file_names_case_sensitive_cache = 0;
> +#elif defined (__APPLE__)
> + /* By default, macOS volumes are case-insensitive, iOS
> + volumes are case-sensitive. */
> +#if defined (TARGET_OS_OSX) /* In recent SDK. */
> +#if TARGET_OS_OSX/* macOS. */
> file_names_case_sensitive_cache = 0;
> #else
> file_names_case_sensitive_cache = 1;
> +#endif
> +#elif TARGET_OS_MAC/* macOS, in older SDK. */
> + file_names_case_sensitive_cache = 0;
> +#else
> + file_names_case_sensitive_cache = 1;
> +#endif
> +#else /* Neither Windows nor Apple. */
> + file_names_case_sensitive_cache = 1;
> #endif
Please simplify the above to (untested):
#elif defined (__APPLE__)
/* By default, macOS volumes are case-insensitive, iOS
volumes are case-sensitive. */
#if TARGET_OS_MAC/* macOS, in older SDK. */
file_names_case_sensitive_cache = 0;
#elif TARGET_OS_OSX /* macOS, in recent SDK. */
file_names_case_sensitive_cache = 0;
#else/* assume iOS. */
file_names_case_sensitive_cache = 1;
#endif
#else /* Neither Windows nor Apple. */
file_names_case_sensitive_cache = 1;
#endif
which is simpler and more readable and should be equivalent AFAICT.
OK with the above change.
Arno
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
On 13 Nov 2023, at 16:18, Arnaud Charlet wrote:
>
> OK, I thought there would be some defines that we could use for that, too
> bad if there isn't
> and indeed we might need to perform another runtime check then as
> suggested by Iain.
I can see a possible interface, operatingSystemVersion in NSProcessInfo.h
- Objective C
needed, I think
>>>
>>> Some of the NS interfaces are available to regular C (e.g. stuff in
>>> CoreFoundation), and I am
>>> fairly/very sure that we will be able to find a machanism that does not
>>> involve introducing an
>>> ObjC dep. [I am obvioulsy not in any way against ObjC - since i’m the
>>> maintainer ;) .. but it
>>> seems heavyweight for solving this issue].
>>
>> It certainly would be heavyweight, since TargetConditionals.h includes
>> TARGET_OS_OSX,
>> which is 1 if we’re compiling for macOS and 0 otherwise (there’s a useful
>> chart at :83 in the
>> MacOSX13.1 SDK).
>>
>> Two ways ahead here:
>> (1) just replace the current __arm__, __arm64__ test with this
>
> That would be fine here (replace refs to *arm* by TARGET_OS_OSX), since this
> was my original
> suggestion (copied at the top of this email).
>
>> (2) as 1, but implement the runtime test for case sensitivity only for macOS
>>
>> Whether (2) is acceptable depends, I suppose, on what issues Iain
>> encountered on Darwin 9
>> & Darwin 17. I’ll be content to go with (1).
I'm not sure whether this should have been a new [PATCH V2] thread?
Also, should the test code below (between %%%) be included in the
testsuite?
--8<--
In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the
current assumption for __APPLE__ is that file names are
case-insensitive unless __arm__ or __arm64__ are defined, in which
case file names are declared case-sensitive.
The associated comment is
"By default, we suppose filesystems aren't case sensitive on
Windows and Darwin (but they are on arm-darwin)."
This means that on aarch64-apple-darwin, file names are treated as
case-sensitive, which is not the default case.
Apple provide a header file which permits a
compile-time check for the compiler target (e.g. OSX vs IOS). At Darwin
10.5 (Xcode 3) iOS wasn't supported, so it was adequate to check
TARGET_OS_MAC; nowadays, that covers many variants including macOS
and iOS, so one needs to check whether TARGET_OS_OSX is defined, and
if so whether it's set.
Bootstrapped on x86_64-apple-darwin with languages c,c++,ada and regression
tested (check-ada).
Likewise bootstrapped on aarch64-apple-darwin from the Github sources
corresponding to GCC 2023-11-05.
__gnat_get_file_names_case_sensitive() isn't exported to user code, so
implemented check code as below: each compiler (x86_64-apple-darwin and
aarch64-apple-darwin) reported that file names were not case sensitive.
%%%
with Ada.Text_IO;
with Interfaces.C;
procedure Check_Case_Sensitivity is
type C_Boolean is (False, True)
with Convention => C;
function Get_File_Names_Case_Sensitive return C_Boolean
with
Import,
Convention => C,
External_Name => "__gnat_get_file_names_case_sensitive";
begin
Ada.Text_IO.Put_Line ("GNAT thinks file names are " &
(case Get_File_Names_Case_Sensitive is
when False => "not case sensitive",
when True => "case sensitive"));
end Check_Case_Sensitivity;
%%%
gcc/ada/Changelog:
2023-11-16 Simon Wright
* gcc/ada/adaint.c
(__gnat_get_file_names_case_sensitive): Split out the __APPLE__
check and remove the checks for __arm__, __arm64__.
File names are by default case sensitive unless TARGET_OS_OSX
(or if this is an older OS release, in which case TARGET_OS_OSX
is undefined, TARGET_OS_MAC) is set.
Signed-off-by: Simon Wright
---
gcc/ada/adaint.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
index bb4ed2607e5..1ef529ec20b 100644
--- a/gcc/ada/adaint.c
+++ b/gcc/ada/adaint.c
@@ -84,7 +84,7 @@
#endif /* VxWorks */
#if defined (__APPLE__)
-#include
+#include
#endif
#if defined (__hpux__)
@@ -613,12 +613,25 @@ __gnat_get_file_names_case_sensitive (void)
else
{
/* By default, we suppose filesystems aren't case sensitive on
-Windows and Darwin (but they are on arm-darwin). */
-#if defined (WINNT) || defined (__DJGPP__) \
- || (defined (__APPLE__) && !(defined (__arm__) || defined (__arm64__)))
+Windows or DOS. */
+#if defined (WINNT) || defined (__DJGPP__)
+ file_names_case_sensitive_cache = 0;
+#elif defined (__APPLE__)
+ /* By default, macOS volumes are case-insensitive, iOS
+volumes are case-sensitive. */
+#if defined (TARGET_OS_OSX) /* In recent SDK. */
+#if TARGET_OS_OSX/* macOS. */
file_names_case_sensitive_cache = 0;
#else
file_names_case_sensitive_cache =
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
> >>> OK, I thought there would be some defines that we could use for that, too > >>> bad if there isn't > >>> and indeed we might need to perform another runtime check then as > >>> suggested by Iain. > >> > >> I can see a possible interface, operatingSystemVersion in NSProcessInfo.h > >> - Objective C > >> needed, I think > > > > Some of the NS interfaces are available to regular C (e.g. stuff in > > CoreFoundation), and I am > > fairly/very sure that we will be able to find a machanism that does not > > involve introducing an > > ObjC dep. [I am obvioulsy not in any way against ObjC - since i’m the > > maintainer ;) .. but it > > seems heavyweight for solving this issue]. > > It certainly would be heavyweight, since TargetConditionals.h includes > TARGET_OS_OSX, > which is 1 if we’re compiling for macOS and 0 otherwise (there’s a useful > chart at :83 in the > MacOSX13.1 SDK). > > Two ways ahead here: > (1) just replace the current __arm__, __arm64__ test with this That would be fine here (replace refs to *arm* by TARGET_OS_OSX), since this was my original suggestion (copied at the top of this email). > (2) as 1, but implement the runtime test for case sensitivity only for macOS > > Whether (2) is acceptable depends, I suppose, on what issues Iain encountered > on Darwin 9 > & Darwin 17. I’ll be content to go with (1).
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
On 11 Nov 2023, at 18:10, Iain Sandoe wrote: > >> On 11 Nov 2023, at 07:47, Simon Wright wrote: >> >> On 6 Nov 2023, at 08:36, Arnaud Charlet wrote: >>> > So without changing fundamentally the model, you can't decide dynamically > for the whole > system. Making the choice based on the current directory is pretty > random, since the current > directory isn't well defined at program's start up and could be pretty > much any filesystem. I’d imagine that projects spread over more than one differently-case-sensitive filesystem would be rare. As to the current directory at compiler startup, with GPRbuild it’s the object directory, so likely to be somewhere near the project’s source tree. >>> >>> I am not talking about the current directory when the compiler runs, I am >>> talking about the >>> current directory where the target program runs, which can be pretty much >>> anywhere. >>> >>> In other words, you are modifying a runtime file (adaint.c) which is used >>> both by the host compiler >>> and by the target applications. My comment worries about the target >>> applications while yours >>> applies to the host compiler only. >> >> I don’t understand? >> >> The change works out whether the filesystem of the current working directory >> is CS, whether >> it’s the compiler or some user program that’s running it (it looks like that >> would have to be via >> some higher-level compiler package, I found only GNAT.Command_Line and >> GNAT.Directory_Operations). >> >> I can see that might not be what the user program wants, but if they >> actually care the current >> situation isn’t great anyway; the compiler definitely makes the wrong choice >> for new Macs. >> > Note that the current setting on arm is actually for iOS, which we did > support at AdaCore > at some point (and could revive in the future, who knows). Wouldn’t it be more natural to go via LLVM? I understand from Iain that iOS isn’t currently supported by GCC. >>> >>> That's another option. We'd like to keep both options on the table, since >>> both options have >>> pros and cons. >>> > So it would be fine to refine the test to differentiate between macOS and > embedded iOS and co, > that would be a better change here. There didn’t seem to be a way to do that. >>> >>> OK, I thought there would be some defines that we could use for that, too >>> bad if there isn't >>> and indeed we might need to perform another runtime check then as suggested >>> by Iain. >> >> I can see a possible interface, operatingSystemVersion in NSProcessInfo.h - >> Objective C >> needed, I think > > Some of the NS interfaces are available to regular C (e.g. stuff in > CoreFoundation), and I am > fairly/very sure that we will be able to find a machanism that does not > involve introducing an > ObjC dep. [I am obvioulsy not in any way against ObjC - since i’m the > maintainer ;) .. but it > seems heavyweight for solving this issue]. It certainly would be heavyweight, since TargetConditionals.h includes TARGET_OS_OSX, which is 1 if we’re compiling for macOS and 0 otherwise (there’s a useful chart at :83 in the MacOSX13.1 SDK). Two ways ahead here: (1) just replace the current __arm__, __arm64__ test with this (2) as 1, but implement the runtime test for case sensitivity only for macOS Whether (2) is acceptable depends, I suppose, on what issues Iain encountered on Darwin 9 & Darwin 17. I’ll be content to go with (1).
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
> On 11 Nov 2023, at 07:47, Simon Wright wrote: > > On 6 Nov 2023, at 08:36, Arnaud Charlet wrote: >> So without changing fundamentally the model, you can't decide dynamically for the whole system. Making the choice based on the current directory is pretty random, since the current directory isn't well defined at program's start up and could be pretty much any filesystem. >>> >>> I’d imagine that projects spread over more than one >>> differently-case-sensitive filesystem would >>> be rare. As to the current directory at compiler startup, with GPRbuild >>> it’s the object directory, so >>> likely to be somewhere near the project’s source tree. >> >> I am not talking about the current directory when the compiler runs, I am >> talking about the >> current directory where the target program runs, which can be pretty much >> anywhere. >> >> In other words, you are modifying a runtime file (adaint.c) which is used >> both by the host compiler >> and by the target applications. My comment worries about the target >> applications while yours >> applies to the host compiler only. > > I don’t understand? > > The change works out whether the filesystem of the current working directory > is CS, whether > it’s the compiler or some user program that’s running it (it looks like that > would have to be via > some higher-level compiler package, I found only GNAT.Command_Line and > GNAT.Directory_Operations). > > I can see that might not be what the user program wants, but if they actually > care the current > situation isn’t great anyway; the compiler definitely makes the wrong choice > for new Macs. > Note that the current setting on arm is actually for iOS, which we did support at AdaCore at some point (and could revive in the future, who knows). >>> >>> Wouldn’t it be more natural to go via LLVM? I understand from Iain that iOS >>> isn’t currently >>> supported by GCC. >> >> That's another option. We'd like to keep both options on the table, since >> both options have >> pros and cons. >> So it would be fine to refine the test to differentiate between macOS and embedded iOS and co, that would be a better change here. >>> >>> There didn’t seem to be a way to do that. >> >> OK, I thought there would be some defines that we could use for that, too >> bad if there isn't >> and indeed we might need to perform another runtime check then as suggested >> by Iain. > > I can see a possible interface, operatingSystemVersion in NSProcessInfo.h - > Objective C > needed, I think Some of the NS interfaces are available to regular C (e.g. stuff in CoreFoundation), and I am fairly/very sure that we will be able to find a machanism that does not involve introducing an ObjC dep. [I am obvioulsy not in any way against ObjC - since i’m the maintainer ;) .. but it seems heavyweight for solving this issue]. Iain
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
On 6 Nov 2023, at 08:36, Arnaud Charlet wrote: > >>> So without changing fundamentally the model, you can't decide dynamically >>> for the whole >>> system. Making the choice based on the current directory is pretty random, >>> since the current >>> directory isn't well defined at program's start up and could be pretty much >>> any filesystem. >> >> I’d imagine that projects spread over more than one >> differently-case-sensitive filesystem would >> be rare. As to the current directory at compiler startup, with GPRbuild it’s >> the object directory, so >> likely to be somewhere near the project’s source tree. > > I am not talking about the current directory when the compiler runs, I am > talking about the > current directory where the target program runs, which can be pretty much > anywhere. > > In other words, you are modifying a runtime file (adaint.c) which is used > both by the host compiler > and by the target applications. My comment worries about the target > applications while yours > applies to the host compiler only. I don’t understand? The change works out whether the filesystem of the current working directory is CS, whether it’s the compiler or some user program that’s running it (it looks like that would have to be via some higher-level compiler package, I found only GNAT.Command_Line and GNAT.Directory_Operations). I can see that might not be what the user program wants, but if they actually care the current situation isn’t great anyway; the compiler definitely makes the wrong choice for new Macs. >>> Note that the current setting on arm is actually for iOS, which we did >>> support at AdaCore >>> at some point (and could revive in the future, who knows). >> >> Wouldn’t it be more natural to go via LLVM? I understand from Iain that iOS >> isn’t currently >> supported by GCC. > > That's another option. We'd like to keep both options on the table, since > both options have > pros and cons. > >>> So it would be fine to refine the test to differentiate between macOS and >>> embedded iOS and co, >>> that would be a better change here. >> >> There didn’t seem to be a way to do that. > > OK, I thought there would be some defines that we could use for that, too bad > if there isn't > and indeed we might need to perform another runtime check then as suggested > by Iain. I can see a possible interface, operatingSystemVersion in NSProcessInfo.h - Objective C needed, I think > Arno
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
> > So without changing fundamentally the model, you can't decide dynamically > > for the whole > > system. Making the choice based on the current directory is pretty random, > > since the current > > directory isn't well defined at program's start up and could be pretty much > > any filesystem. > > I’d imagine that projects spread over more than one > differently-case-sensitive filesystem would > be rare. As to the current directory at compiler startup, with GPRbuild it’s > the object directory, so > likely to be somewhere near the project’s source tree. I am not talking about the current directory when the compiler runs, I am talking about the current directory where the target program runs, which can be pretty much anywhere. In other words, you are modifying a runtime file (adaint.c) which is used both by the host compiler and by the target applications. My comment worries about the target applications while yours applies to the host compiler only. > > Note that the current setting on arm is actually for iOS, which we did > > support at AdaCore > > at some point (and could revive in the future, who knows). > > Wouldn’t it be more natural to go via LLVM? I understand from Iain that iOS > isn’t currently > supported by GCC. That's another option. We'd like to keep both options on the table, since both options have pros and cons. > > So it would be fine to refine the test to differentiate between macOS and > > embedded iOS and co, > > that would be a better change here. > > There didn’t seem to be a way to do that. OK, I thought there would be some defines that we could use for that, too bad if there isn't and indeed we might need to perform another runtime check then as suggested by Iain. Arno
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
Hi Folks > On 4 Nov 2023, at 17:02, Simon Wright wrote: > > On 3 Nov 2023, at 08:39, Arnaud Charlet wrote: >> So without changing fundamentally the model, you can't decide dynamically >> for the whole >> system. Making the choice based on the current directory is pretty random, >> since the current >> directory isn't well defined at program's start up and could be pretty much >> any filesystem. > > I’d imagine that projects spread over more than one > differently-case-sensitive filesystem would > be rare. As to the current directory at compiler startup, with GPRbuild it’s > the object directory, so > likely to be somewhere near the project’s source tree. It’s likely much less rare to find a CS external disk or an NFS mount, or secondary FS with a non-CS system partition, (since the default for the system install is that way). I am suspicious of second-guessing any of this; my opinion is that if we have an automated recognition of CS, then it needs to work in the general circumstance (that would certainly be in the spirit of macOS “it just works”). If we cannot achieve that, the advantage of the current scenario (GNAT_FILE_NAME_CASE_SENSITIVE=..) is that it is explicit on the part of the user, and therefore puts the onus on the user to get it right. >> Note that the current setting on arm is actually for iOS, which we did >> support at AdaCore >> at some point (and could revive in the future, who knows). > > Wouldn’t it be more natural to go via LLVM? I understand from Iain that iOS > isn’t currently > supported by GCC. Historically, we had no support for Arm or AArch64, so the missing support of iOS as a concept was not important - now we have an AArch64 port, it is feasible and potentially relevant to update this. Having said that, I’m not sure how a a GCC-developed iOS app would be distributed - but of course libraries are a different story. > >> So it would be fine to refine the test to differentiate between macOS and >> embedded iOS and co, >> that would be a better change here. > > There didn’t seem to be a way to do that. We should be able to do that at runtime (sysctl calls for example) > So, Iain, do we want to pursue this? Right now, I have no spare resources to tackle this, (I suspect that the issues I see on earlier systems are due to the syscall not finding the right root FS from paths like /foo/bar so it remains to be see how to deal with it). I have no objection from a Darwin perspective to folks finding a mutually agreeable solution that works without the user specifying the env. var - but I’m not going to be able to contribute much to the work in the near future. thanks Iain
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
On 3 Nov 2023, at 08:39, Arnaud Charlet wrote: > In addition to the non portable issues already mentioned, this change isn't > OK also > for other reasons. > > Basically this function is global and decides once for all on the case > sensitivity, while > the case sensitiviy is on a per filsystem basis as you noted. Well, the current code does exactly what you describe, with less relationship to the actual environment than this proposal. > So without changing fundamentally the model, you can't decide dynamically for > the whole > system. Making the choice based on the current directory is pretty random, > since the current > directory isn't well defined at program's start up and could be pretty much > any filesystem. I’d imagine that projects spread over more than one differently-case-sensitive filesystem would be rare. As to the current directory at compiler startup, with GPRbuild it’s the object directory, so likely to be somewhere near the project’s source tree. > Note that the current setting on arm is actually for iOS, which we did > support at AdaCore > at some point (and could revive in the future, who knows). Wouldn’t it be more natural to go via LLVM? I understand from Iain that iOS isn’t currently supported by GCC. > So it would be fine to refine the test to differentiate between macOS and > embedded iOS and co, > that would be a better change here. There didn’t seem to be a way to do that. But anyway, I find myself puzzled by the casing issue. It seems to me that on a CS filesystem users would be well advised to stick to lower-case filenames, or the compiler won’t be able to resolve 'with' statements; whereas on a non-CS system, there’d be no such constraint. Indeed, when compiling a file with a mixed-case name in a CS environment, the compiler warns: $ GNAT_FILE_NAME_CASE_SENSITIVE=1 gcc -c -u -f WTF.adb WTF.adb:1:11: warning: file name does not match unit name, should be "wtf.adb" [enabled by default] Also, there’ve been about 80 downloads of GCC 13.1.0 for aarch64-apple-darwin, and no case-sensitivity issues have been reported. So, Iain, do we want to pursue this? > >> This change affects only Ada. >> >> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the >> assumption for __APPLE__ is that file names are case-insensitive >> unless __arm__ or __arm64__ are defined, in which case file names >> are declared case-sensitive. >> >> The associated comment is >> "By default, we suppose filesystems aren't case sensitive on >> Windows and Darwin (but they are on arm-darwin)." >> >> This means that on aarch64-apple-darwin, file names are declared >> case-sensitive, which is not normally the case (but users can set >> up case-sensitive volumes). >> >> It's understood that GCC does not currently support iOS/tvOS/watchOS, >> so we assume macOS. >> >> Bootstrapped on x86_64-apple-darwin with languages c,c++,ada and regression >> tested (check-gnat). >> Also, tested with the example from PR ada/81114, extracted into 4 volumes >> (APFS, APFS-case-sensitive, >> HFS, HFS-case-sensitive; the example code built successfully on the >> case-sensitive volumes. >> Setting GNAT_FILE_NAME_CASE_SENSITIVE successfully overrode the choices made >> by the >> new code. >> >> gcc/ada/Changelog: >> >> 2023-10-29 Simon Wright >> >> PR ada/111909 >> >> * gcc/ada/adaint.c >> (__gnat_get_file_names_case_sensitive): Remove the checks for >> __arm__, __arm64__. >> Split out the check for __APPLE__; remove the checks for __arm__, >> __arm64__, and use getattrlist(2) to determine whether the current >> working directory is on a case-sensitive filesystem. >> >> Signed-off-by: Simon Wright
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
Hi Simon, In addition to the non portable issues already mentioned, this change isn't OK also for other reasons. Basically this function is global and decides once for all on the case sensitivity, while the case sensitiviy is on a per filsystem basis as you noted. So without changing fundamentally the model, you can't decide dynamically for the whole system. Making the choice based on the current directory is pretty random, since the current directory isn't well defined at program's start up and could be pretty much any filesystem. Note that the current setting on arm is actually for iOS, which we did support at AdaCore at some point (and could revive in the future, who knows). So it would be fine to refine the test to differentiate between macOS and embedded iOS and co, that would be a better change here. > This change affects only Ada. > > In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the > assumption for __APPLE__ is that file names are case-insensitive > unless __arm__ or __arm64__ are defined, in which case file names > are declared case-sensitive. > > The associated comment is > "By default, we suppose filesystems aren't case sensitive on > Windows and Darwin (but they are on arm-darwin)." > > This means that on aarch64-apple-darwin, file names are declared > case-sensitive, which is not normally the case (but users can set > up case-sensitive volumes). > > It's understood that GCC does not currently support iOS/tvOS/watchOS, > so we assume macOS. > > Bootstrapped on x86_64-apple-darwin with languages c,c++,ada and regression > tested (check-gnat). > Also, tested with the example from PR ada/81114, extracted into 4 volumes > (APFS, APFS-case-sensitive, > HFS, HFS-case-sensitive; the example code built successfully on the > case-sensitive volumes. > Setting GNAT_FILE_NAME_CASE_SENSITIVE successfully overrode the choices made > by the > new code. > > gcc/ada/Changelog: > > 2023-10-29 Simon Wright > > PR ada/111909 > > * gcc/ada/adaint.c > (__gnat_get_file_names_case_sensitive): Remove the checks for > __arm__, __arm64__. > Split out the check for __APPLE__; remove the checks for __arm__, > __arm64__, and use getattrlist(2) to determine whether the current > working directory is on a case-sensitive filesystem. > > Signed-off-by: Simon Wright
Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
Hi Simon,
(please cc me on Darwin-related patches)
> On 29 Oct 2023, at 11:51, Simon Wright wrote:
>
> This change affects only Ada.
>
> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the
> assumption for __APPLE__ is that file names are case-insensitive
> unless __arm__ or __arm64__ are defined, in which case file names
> are declared case-sensitive.
>
> The associated comment is
> "By default, we suppose filesystems aren't case sensitive on
> Windows and Darwin (but they are on arm-darwin)."
>
> This means that on aarch64-apple-darwin, file names are declared
> case-sensitive, which is not normally the case (but users can set
> up case-sensitive volumes).
>
> It's understood that GCC does not currently support iOS/tvOS/watchOS,
> so we assume macOS.
>
> Bootstrapped on x86_64-apple-darwin with languages c,c++,ada and regression
> tested (check-gnat).
> Also, tested with the example from PR ada/81114, extracted into 4 volumes
> (APFS, APFS-case-sensitive,
> HFS, HFS-case-sensitive; the example code built successfully on the
> case-sensitive volumes.
> Setting GNAT_FILE_NAME_CASE_SENSITIVE successfully overrode the choices made
> by the
> new code.
This does not yet work on at least Darwin17 and Darwin9, even though the
‘getattrlist()` call
and the `VOL_CAP_FMT_CASE_SENSITIVE` should exist on both. So we need to figure
out why the current code is not working (so, not yet OK from a Darwin
perspective).
thanks
Iain
>
> gcc/ada/Changelog:
>
> 2023-10-29 Simon Wright
>
> PR ada/111909
>
> * gcc/ada/adaint.c
> (__gnat_get_file_names_case_sensitive): Remove the checks for
> __arm__, __arm64__.
> Split out the check for __APPLE__; remove the checks for __arm__,
> __arm64__, and use getattrlist(2) to determine whether the current
> working directory is on a case-sensitive filesystem.
>
> Signed-off-by: Simon Wright
> ---
> gcc/ada/adaint.c | 46 ++
> 1 file changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
> index 2a193efc002..43d166824b0 100644
> --- a/gcc/ada/adaint.c
> +++ b/gcc/ada/adaint.c
> @@ -85,6 +85,7 @@
>
> #if defined (__APPLE__)
> #include
> +#include
> #endif
>
> #if defined (__hpux__)
> @@ -613,11 +614,48 @@ __gnat_get_file_names_case_sensitive (void)
> else
> {
> /* By default, we suppose filesystems aren't case sensitive on
> - Windows and Darwin (but they are on arm-darwin). */
> -#if defined (WINNT) || defined (__DJGPP__) \
> - || (defined (__APPLE__) && !(defined (__arm__) || defined (__arm64__)))
> + Windows or DOS. */
> +#if defined (WINNT) || defined (__DJGPP__)
> file_names_case_sensitive_cache = 0;
> -#else
> +#elif defined (__APPLE__)
> + /* Determine whether the current volume is case-sensitive. */
> + {
> + /* Formulate a query for the volume capabilities. */
> + struct attrlist attrList
> + = {ATTR_BIT_MAP_COUNT,
> + 0, /* reserved. */
> + 0, /* commonattr. */
> + ATTR_VOL_INFO | ATTR_VOL_CAPABILITIES, /* volattr. */
> + 0, /* dirattr. */
> + 0, /* fileattr. */
> + 0/* forkattr. */
> + };
> +
> + /* A buffer to contain just the volume capabilities. */
> + struct returnBuf {
> + u_int32_t length;
> + vol_capabilities_attr_t caps;
> + } __attribute__ ((aligned (4), packed)) retBuf;
> +
> + /* Default to case-insensitive. */
> + file_names_case_sensitive_cache = 0;
> +
> + /* Query the current working directory. */
> + if (getattrlist (".",
> + ,
> + ,
> + sizeof (retBuf),
> + 0) == 0)
> + /* The call succeeded. */
> + if ((retBuf.caps.valid[VOL_CAPABILITIES_FORMAT]
> +& VOL_CAP_FMT_CASE_SENSITIVE))
> + /* The volume could be case-sensitive. */
> + if (retBuf.caps.capabilities[VOL_CAPABILITIES_FORMAT]
> + & VOL_CAP_FMT_CASE_SENSITIVE)
> + /* The volume is case-sensitive. */
> + file_names_case_sensitive_cache = 1;
> + }
> +#else /* Neither Windows nor Apple. */
> file_names_case_sensitive_cache = 1;
> #endif
> }
> --
> 2.39.3 (Apple Git-145)
>
