[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Iain Sandoe --- fixed on open branches
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 --- Comment #13 from GCC Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:729170a45040e96d567be79bda00604a7645a23d commit r11-11402-g729170a45040e96d567be79bda00604a7645a23d Author: Iain Sandoe Date: Mon Mar 18 10:06:44 2024 + testsuite, Darwin: Use the IOKit framework in framework-1.c [PR114049]. The intent of the test is to show that we find a framework that is installed in /System/Library/Frameworks when the user has added a '-F' option. The trick is to choose some header that is present for all the Darwin versions we support and that does not contain any content we cannot parse. We had been using the Kernel framework for this, but recent SDK versions have revealed that this is not suitable. Replacing with a use of IOKit. PR target/114049 gcc/testsuite/ChangeLog: * gcc.dg/framework-1.c: Use an IOKit header instead of a Kernel one. Signed-off-by: Iain Sandoe (cherry picked from commit 4adb1a5839e7a3310a127c1776f1f95d7edaa6ff)
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 --- Comment #12 from GCC Commits --- The releases/gcc-12 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:4c8d37badaa42e85218eb9b89aef3e4f6cf4486e commit r12-10375-g4c8d37badaa42e85218eb9b89aef3e4f6cf4486e Author: Iain Sandoe Date: Mon Mar 18 10:06:44 2024 + testsuite, Darwin: Use the IOKit framework in framework-1.c [PR114049]. The intent of the test is to show that we find a framework that is installed in /System/Library/Frameworks when the user has added a '-F' option. The trick is to choose some header that is present for all the Darwin versions we support and that does not contain any content we cannot parse. We had been using the Kernel framework for this, but recent SDK versions have revealed that this is not suitable. Replacing with a use of IOKit. PR target/114049 gcc/testsuite/ChangeLog: * gcc.dg/framework-1.c: Use an IOKit header instead of a Kernel one. Signed-off-by: Iain Sandoe (cherry picked from commit 4adb1a5839e7a3310a127c1776f1f95d7edaa6ff)
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 --- Comment #11 from GCC Commits --- The releases/gcc-13 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:b03827b261d3c8351f9c208fe2d89ca987a25bee commit r13-8584-gb03827b261d3c8351f9c208fe2d89ca987a25bee Author: Iain Sandoe Date: Mon Mar 18 10:06:44 2024 + testsuite, Darwin: Use the IOKit framework in framework-1.c [PR114049]. The intent of the test is to show that we find a framework that is installed in /System/Library/Frameworks when the user has added a '-F' option. The trick is to choose some header that is present for all the Darwin versions we support and that does not contain any content we cannot parse. We had been using the Kernel framework for this, but recent SDK versions have revealed that this is not suitable. Replacing with a use of IOKit. PR target/114049 gcc/testsuite/ChangeLog: * gcc.dg/framework-1.c: Use an IOKit header instead of a Kernel one. Signed-off-by: Iain Sandoe (cherry picked from commit 4adb1a5839e7a3310a127c1776f1f95d7edaa6ff)
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 Iain Sandoe changed: What|Removed |Added Target Milestone|14.0|11.5 --- Comment #10 from Iain Sandoe --- fixed on trunk, but this will need back porting to avoid fails when building the release branches with latest toolchains / on newest OS versions.
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 --- Comment #9 from GCC Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:4adb1a5839e7a3310a127c1776f1f95d7edaa6ff commit r14-9543-g4adb1a5839e7a3310a127c1776f1f95d7edaa6ff Author: Iain Sandoe Date: Mon Mar 18 10:06:44 2024 + testsuite, Darwin: Use the IOKit framework in framework-1.c [PR114049]. The intent of the test is to show that we find a framework that is installed in /System/Library/Frameworks when the user has added a '-F' option. The trick is to choose some header that is present for all the Darwin versions we support and that does not contain any content we cannot parse. We had been using the Kernel framework for this, but recent SDK versions have revealed that this is not suitable. Replacing with a use of IOKit. PR target/114049 gcc/testsuite/ChangeLog: * gcc.dg/framework-1.c: Use an IOKit header instead of a Kernel one. Signed-off-by: Iain Sandoe
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-16 --- Comment #8 from Iain Sandoe --- according to information from the Apple OSS folks, the Kernel.framework is/was (never) intended to be used as a regular framework. [This was news to me, FWIW, and it does seem a somewhat odd situation, since it's wrapped up in all the necessary machinery which makes it look like it should work]. anyway What we want from this test is that a suitable framework is found in /System/Library/Frameworks when the user has also given a local framework path (-F.). What we want to avoid is the test regressing because of incidental SDK changes (like unguarded Apple Black usage) - so we have picked the kernel framework and a suitable low-complexity header. At present, I am thinking that IOkit/IOReturn.h might be a suitable substitute - but that needs to be checked across the range of OS versions supported.
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #7 from Francois-Xavier Coudert --- I'd say that a SDK bug? It definitely shows with clang, so I filed it as FB13678545 with Apple.
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 --- Comment #6 from Iain Sandoe --- I'm still finding this a bit confusing. - we have not altered the code in this area (at least not the Darwin parts) during the gcc-14 cycle. - apparently, it works with previous Xcode versions/SDKs - from your comment #2 "$ clang /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c -F. -S -o framework-1.s In file included from /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c:4: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/string.h:55:10: error: 'machine/trap.h' file not found with include; use "quotes" instead #include " that seems to be an error, not a warning (even if it diagnoses better than we do). - even if it tries to fall back to the "" version, that still should not find the header according to the information in comment #5 - since we so not add any paths below Library/Frameworks .. so 'machine' is only a top level include directory in /usr/include (and it does not contain trap.h).
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 --- Comment #5 from Iain Sandoe --- The manual currently says: -I dir -iquote dir -isystem dir -idirafter dir Add the directory dir to the list of directories to be searched for header files dur- ing preprocessing. If dir begins with ‘=’ or $SYSROOT, then the ‘=’ or $SYSROOT is replaced by the sysroot prefix; see --sysroot and -isysroot. Directories specified with -iquote apply only to the quote form of the directive, #include "file". >>> Directories specified with -I, -isystem, or -idirafter apply to lookup for >>> both the #include "file" and #include directives. <<< You can specify any number or combination of these options on the command line to search for header files in several directories. The lookup order is as follows: 1. Forthequoteformoftheincludedirective,thedirectoryofthecurrentfile is searched first. 2. For the quote form of the include directive, the directories specified by -iquote options are searched in left-to-right order, as they appear on the command line. 3. Directories specified with -I options are scanned in left-to-right order. 4. Directories specified with -isystem options are scanned in left-to-right order. 5. Standard system directories are scanned. 6. Directories specified with -idirafter options are scanned in left-to-right The highlighted bit seems to say we should be searching for either "" or <> .. I wonder if something is being confused by the user framework path (-F .)
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Iain Sandoe --- > so .. if i follow your discussion correctly - neither clang nor gcc finds it > because it's incorrectly quoted (is that an SDK issue?).. or? The quoting is one part, certainly. While clang falls back from <> to "", gcc does not. However, even if I change string.h locally to use "", while this allows machine/trap.h to be found, the subsequent i386/trap.h is still not found, neither by gcc nor by clang. I have not idea what they are doing here, but the same construct is used all over Frameworks/Kernel.framework/Headers. > We do have control, IIRC, about adding the frameworks search path to "system" > rather than "user". That might be an option: I guess we should follow what clang does here.
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 --- Comment #3 from Iain Sandoe --- so .. if i follow your discussion correctly - neither clang nor gcc finds it because it's incorrectly quoted (is that an SDK issue?).. or? We do have control, IIRC, about adding the frameworks search path to "system" rather than "user".
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Iain Sandoe --- > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers > should be a symlink to > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers More or less: the symlink is to Versions/Current/Headers. > so either that's broken or we're failing to follow a symlink somehow. I've checked: the original invocation is /private/var/gcc/regression/master/14-gcc/build/gcc/xgcc -B/private/var/gcc/regression/master/14-gcc/build/gcc/ /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c -fdiagnostics-plain-output -F. -S -o framework-1.s with cc1 called like /private/var/gcc/regression/master/14-gcc/build/gcc/cc1 -quiet -v -F. -iprefix /private/var/gcc/regression/master/14-gcc/build/gcc/../lib/gcc/x86_64-apple-darwin23.3.0/14.0.1/ -isystem /private/var/gcc/regression/master/14-gcc/build/gcc/include -isystem /private/var/gcc/regression/master/14-gcc/build/gcc/include-fixed -D__DYNAMIC__ /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c -fPIC -quiet -dumpbase framework-1.c -dumpbase-ext .c -mmacosx-version-min=14.0.0 -mtune=core2 -version -fdiagnostics-color=never -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-urls=never -fdiagnostics-path-format=separate-events -fdiagnostics-text-art-charset=none -o framework-1.s After the usual messages about nonexistant directories, we get to #include <...> search starts here: . /private/var/gcc/regression/master/14-gcc/build/gcc/include /private/var/gcc/regression/master/14-gcc/build/gcc/include-fixed /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks End of search list. /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/string.h has #include which lives in /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/machine/trap.h Given the above search list, "machine/trap.h" should work, but doesn't. When using the bundled clang, I get $ clang /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c -F. -S -o framework-1.s In file included from /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c:4: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/string.h:55:10: error: 'machine/trap.h' file not found with include; use "quotes" instead #include ^ In file included from /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c:4: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/string.h:55: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/machine/trap.h:32:10: fatal error: 'i386/trap.h' file not found #include "i386/trap.h" ^ 2 errors generated.
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 --- Comment #1 from Iain Sandoe --- /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers should be a symlink to /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers so either that's broken or we're failing to follow a symlink somehow.
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 Rainer Orth changed: What|Removed |Added Target Milestone|--- |14.0
